Edit: even if the TLD they use is .ai and they heavily promote themselves as revolutionary AI security firm yadda yadda yadda
I would be curious what AI tools assisted in this and also what tools/models could re-discover them on the unpatched code base now that we know they exist.
Give me one reason why they would do it by hand if they can automate is as much as possible. Vulnerability research is an area without any guarantees, you can spend months looking for bugs and find nothing. These guys are not stupid, they used LLMs trying to find whatever they could, they probably explored more blind alleys than we will know, and then got very good results. Many other companies are doing the same.
Edit: replaced link with link to HN post, not the article in that post.
One of the vault backends has a size limit and so secret keys larger than 2048 bits would not fit. Amazing tool.
But I'm neither a security person nor have I done much with authentication since my 2000's PHP hobbying. I suspect an LDAP server has to deal with or try and manage a lot of garbage input because of the sheer number of integrations they often have.
I'm very disappointed to hear that the researchers did not disclose these findings to the OpenBao project before publishing them, so you now have to rush a release like this
Will you reach out to the researchers for an explanation after you've fixed the issues?
explanation ≠ excuse
My impression is that there is an information gap about forked projects that lead to this issue
I'm on vacation right now, but when I'm back I'll try to setup a small site that lists forks of popular projects and maybe some information on when in time the project was forked
Hopefully something like that can make it more likely that these things are responsibly disclosed to all relevant projects
It also doesn't sound like the researchers made an effort to safely disclose these findings to the OpenBao project before publishing them, which I think would have been the right thing to do
Wait, why would I care this is "daka" in Hebrew? Is this a hallucination or did they edit poorly?
It may become an English writing style we all have to get used to from non-native English speakers and an actual valid use case for current AI. I know I’d use AI this way when writing something important in a language I’m semi-fluent in. I already use search engines to confirm the proper use and spelling of fashionably popular foreign phrases, instead of an online dictionary.
That said, I think it's weird; the vulnerabilities seem to have been found by doing a thorough code review and comprehension, why then cut corners by passing the writeup through AI?
I like humans. I've even loved a few. I like what humans do; warts, typos and awkward phrasing included.
CVE-2025-6010 - [REDACTED]
CVE-2025-6004 - Lockout Bypass https://feedly.com/cve/CVE-2025-6004
Via case permutation in userpass auth Via input normalization mismatch in LDAP auth
CVE-2025-6011 - Timing-Based Username Enumeration https://feedly.com/cve/CVE-2025-6011
Identify valid usernames
CVE-2025-6003 - MFA Enforcement Bypass https://feedly.com/cve/CVE-2025-6003
Via username_as_alias configuration in LDAP
CVE-2025-6013 - Multiple EntityID Generation https://feedly.com/cve/CVE-2025-6013
Allows LDAP users to generate multiple EntityIDs for the same identity
CVE-2025-6016 - TOTP MFA Weaknesses https://feedly.com/cve/CVE-2025-6016
Aggregated logic flaws in TOTP implementation
CVE-2025-6037 - Certificate Entity Impersonation https://feedly.com/cve/CVE-2025-6037
Existed for 8+ years in Vault
CVE-2025-5999 - Root Privilege Escalation https://feedly.com/cve/CVE-2025-5999
Admin to root escalation via policy normalization
CVE-2025-6000 - Remote Code Execution https://feedly.com/cve/CVE-2025-6000
First public RCE in Vault (existed for 9 years) Via plugin catalog abuse > https://discuss.hashicorp.com/t/hcsec-2025-14-privileged-vau...
In non-CA mode, an attacker who has access to the private key of a pinned certificate can:
Present a certificate with the correct public key
Modify the CN in the client certificate to any arbitrary value
Cause Vault to assign the resulting alias.Name to that CN
If your input from user is a string, define a newtype like UserName and do all validation and normalization once to convert it. All subsequent code should be using that type and not raw strings, so it will be consistent everywhere.
Just to clarify - all the vulnerabilities were found manually by a very real human, Yarden Porat.
The writeup was mostly human-written as well, just aimed at a broader audience - which explains the verbosity. We did work with a content writer to help shape the structure and flow, and I totally get that some parts read a bit “sheeny.” Feedback noted and appreciated - and yep, there’s more coming :)
btw likely missed with the direct link - we also found pre-auth RCE in CyberArk Conjur - cyata.ai/vault-fault
And as it's now August, is it redacted as not fixed yet? Why not
CVE-2025-6010 - [REDACTED]
OpenBao is reasonably confident in our fix: https://github.com/openbao/openbao/pull/1628
We had earlier pulled support for pre-Vault-1.0 userpass pre-bcrypt hashing (so there's no longer a timing difference there that could be used for enumeration) and using cache busting on lookup should also ensure consistency across storage layers. Plus, normalizing the remaining error messages through when the user's credential is fully validated as correct.
There's no more ubiquitous or lower signal class of comment here these days than "I think this was written by an AI." Eventually, hopefully, dang will declare that not a productive topic for comments, but until then we all have to suffer through it on every post.
Its nearly always possible to get usernames elsewhere, they are basically public and the private part is the key and any mfa token. Usernames can get locked out, but the workaround of having user enumeration sprays always burn CPU hashing time delaying passwords doesn't seem like a step forward.
Like, of course a language that sucks for writing parsers will end up with a ton of bugs that would have been fixed by parsing and normalizing all input asap, but no, in go and javascript the average type is a string so you can "ToLower" deep in the code instead of just during parsing after which it should have no longer been a string type
The second paragraph seems more like design issues than a language issue. That said, I’d certainly rather write a parser in Golang than JavaScript, especially once one brings up type safety.
Unlike real software, written by real men, in Assembly, on paper, bare chested during a full moon, right?
> The point of go is to make is it so that below average programmers can write roughly average code
You either have no clue about Go, or are mistaking it with something else.
Go was created at Google to have a performant language with static types that was easy to read (because code is read much more often than it is written, while improving it, fixing it, reviewing it, etc). Lots of extremely solid, good, widely used software is written in it, and for good reasons.
Comparing Go with JavaScript also doesn't leave us with the impression you've even heard of Go before this comment.
We've triaged as being affected by 8 of the 9 CVEs (in fixing an earlier Cert Auth vulnerability, we correctly remediated this one) and have merged patches for most of them.
Happily, the community has done some great work on remediating these and I'm very appreciative of them.
I'm most excited about the audit changes: this was the impetus needed to make them be configuration driven in the next release series. Leaving audit device (which, as a reminder, have a socket mode which can make arbitrary TCP calls!) open to API callers is rather unsafe, even with prefix being limited.
(Edit: And of course it goes without saying, but we're more than happy to accept contributions to the community -- code, docs, technical, or otherwise!)
The code base is an absolute mess.
The number of bugs and weird edge cases I've found with my quickcheck property testing of their API is shocking, and makes me think their test suites are woefully inadequate.
This is an understatement, and honestly when I saw it the first time it was enough to make me wonder about all things Hashicorp.
The RCE reported here is the product of an admin->root (Vault root, not Unix root) privilege escalation that already required a privileged account. It's a good bug! They got audit logs to get parsed as an executable plugin. The privilege escalation bug they used to allow admin accounts to set up plugins is also clever (they noticed that the sanity check for assuming the "root" token hardcoded "root", but the code that actually selected the token sanitized the token name, so you could use " ROOT").
v5v3•6h ago