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
Well written? AI. Poorly written? AI. Has a non-sequitor? AI. No non-sequitors? AI. Includes an em-dash (added automatically by Word for almost two decades)? AI. No em-dashes? AI.
Eventually, hopefully, dang will declare "I think this was written by AI" to not be a productive topic for comments, just like commenters are already encouraged to engage with the strongest and best form of the ideas presented instead of attacking the most easily taken down strawman interpretation of them, but until then we all have to scroll through it on every post, no matter how well written it is, as yours is.
Rhetorical faults are consistently discussed when security disclosures and notifications come up. How egotistical are the finders? Does it deserve a microsite? Does it deserve a logo? Similarly, why is the vendor response so vague? Why does it seem so weasel-like? Did they lie in this one place...?
The problem with AI writing is that it doesn't have a voice, is not typically good, and interferes with the ethos and pathos the author is trying to develop. It's verbose, and typically telegraphs a lack of editing or real review.
That humans still care about these things isn't a problem for dang to sort out. It's something that authors should continue to think about carefully before putting out automatically-generated content under their name.
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.
I've done all these things in fairly high-security contexts where I had a very critical username normalization step. It's a very valuable tool.
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!)
Over the long term, increasing prominence of your project will probably get you most disclosures directly, because vulnerability researchers are incentivized to confirm big targets for findings. But in the short term, I don't think this complaint about HashiCorp is based in any real norm of vulnerability disclosure.
It is a fair criticism. But I think two things give us an advantage here:
1. IBM started this fork and later bought HashiCorp, with the acquisition having fully completed. I've broached the subject with both sides post-acquisition but got only a negative response from the HashiCorp side and no response from IBM. We are very much a known entity to the teams that matter inside IBM. And I'd posit within HashiCorp as well given I came out of their Vault Crypto team. ;-)
Whether IBM wishes to cooperate is a different matter. Mentioning again, publicly, doesn't hurt and hopefully raises awareness to researchers (such as yourself!).
2. The Linux Foundation's OpenSSF (our umbrella foundation) has a reputation which we try our best to uphold. Obviously they'd be rightfully upset if we shared pre-disclosure vulnerabilities widely. So we won't and don't. Certainly the broader Linux distribution security list is a positive model in this regard.
If this were J. Doe's pet fork of $CRITICAL_SOFTWARE, 100% agree. But the fork is neither new nor lacking in reputation of its component/parent entities, so I'd hope researchers give us the same consideration they would any other of LF's forks (Valkey, OpenSearch, OpenTofu, ...).
But that said, I've personally disclosed vulnerabilities post-fork to HashiCorp and have mentioned to them that I have stopped future disclosures without a further agreement. This just leads to a two-party zero-day vulnerability race, which is not in anyone's best interest.
https://discuss.hashicorp.com/tag/security-vault is the aggregate link, with HCSEC-2025-[13..22] being the relevant topics.
I will be working shortly to acquire additional CVE numbers for OpenBao for the 8 affected issues.
HCSEC-2025-18 / CVE-2025-6037 (core user confusion bug) does not affect OpenBao.
In general, our release notes detail fixed security issues: https://openbao.org/docs/release-notes/2-3-0/ per policy https://github.com/openbao/.github/blob/main/SECURITY.md. This also has contact information if anyone wishes to discuss additional new security issues.
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
So maybe one step down in severity, though I do not know the details of what HCSEC-2024-05 was fixed with as that was after the fork point. OpenBao moved to full cert pinning (constant-time cert.Raw comparisons) when remediating that one, which meant we were not affected by this variant.
You have access to the private key of the public key in a certificate. The certificate is making an attestation that the signer has verified that this canonical name belongs to this public key.
You as the holder of the private key that matches the public key in the certificate should not allow you to change what the signer has attested about you.
When you lose your private key, you have lost the war to protect your identity - anyone else can now be you. But in a properly designed system, that should not also compromise the signer.
If I steal your license I can pretend to be you, but I can't make the government say you are 7 feet tall.
You may be making the point that a compromised keystore holding all users public keys may leak the signers private key at the same time it has leaked the victim's private key, but there are many ways the victim's private key can be leaked in most cryptosystems (eg, the victim's private key on their device may be stolen).
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...
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.
It's all Go anyway, it all looks pretty similar. I think if anything it looks/feels this way because it's a security-first project. By that I mean the way the code is written tends to care more about security over anything else.
Also the Hashicorp projects in general tend to use a lot of their own libraries/code so it's just a little different than other stuff. Code quality isn't too important so long as the code is maintainable (clearly it is, it's had a lot of versions) and works (again, clearly it does. a lot of folks use vault just fine, including me).
All previous CVEs are handled in a very straightforward manner with reasonable notifications as well, just like this one. This just has a big fancy article attached to it because it's Blackhat week and folks want to get a big fancy release. If you need further proof of the Blackhat effect go look up the 'death of http/1.1' article.
This is an understatement, and honestly when I saw it the first time it was enough to make me wonder about all things Hashicorp.
As a bystander, can you give any examples? Is it just poorly structured, full of spaghetti, or something else?
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.
(Your comment is at least more charitable than the first couple in this thread, but still factually shaky at best.)
pars minuta prima (first small part) -> minute (1/60th of a circle, or of an hour)
secunda minuta -> second (1/60 of a minute)
minutus -> minute (adj), "very small in size or degree, diminutive or limited, petty"
source: etymonline
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").
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.
Edit: replaced link with link to HN post, not the article in that post.
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.
why does this phrase not fill me with confidence?
The OpenBao community call is in 10 minutes if you want to talk more about it live: https://calendar.google.com/calendar/embed?src=s63voefhp5i9p... (OpenSSF community calendar link).
But, the short answer why I say _reasonably_ sure is because HashiCorp and the OP haven't released a lot of details about exactly what case(s) are affected, so there's only so much we can do except look at our own code and infer what we can and make an educated guess.
So, barring some structural problem I'm not immediately aware of, I have reasonably high confidence based on discussions amongst the community members.
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
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?
(No llm were used for the research)
Why would you think someone would hide the use of AI? I'm not familiar with a timeline with that behavior.
I like humans. I've even loved a few. I like what humans do; warts, typos and awkward phrasing included.
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.
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.
One of the vault backends has a size limit and so secret keys larger than 2048 bits would not fit. Amazing tool.
