Zero-day flaws in authentication, identity, authorization in HashiCorp Vault | Hacker News Reader

Zero-day flaws in authentication, identity, authorization in HashiCorp Vault

cyata.ai

289 pointsnihsy93 comments

Hey all — authors of Vault Fault here (I’m Shahar, CEO at Cyata), really appreciate all the thoughtful comments.

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

Your writeup was excellent. There's no more ubiquitous or lower signal comment here these days than "I think this was written by AI." There is no piece of English writing one can link to on HN without someone spamming us with a sentence or that form.

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.

I disagree, the write up is overly verbose. If AI helped inflate it, that's worthy of conversation.

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.

"Does it deserve a logo and a microsite" is one of those debates that happens on message boards that is otherwise pretty alien to the practice of vulnerability research.

If these are the problems (or, your problems), then it seems that it doesn't matter if AI wrote it or not -- just that the writing isn't "good".

Ideally all the comments about presentation rather than content would be grouped into their own category, so the ones with more substance stand out. But I don't know how you'd do that other with an LLM :-)

Impressive. It's worth reading despite the slight AI sheen to the writing, as it's unusually informative relative to most security articles. The primary takeaway from my POV is to watch out for "helpful" string normalization calls in security sensitive software. Strings should be bags of bytes as much as possible. A lot of the exploits boil down to trying to treat security identifiers as text instead of fixed numeric sequences. Also, even things that look trivial like file paths in error messages can be deadly.

My take on the normalization is that it happens in the wrong place - you should not do it adhoc.

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.

Its ridiculous that we haven't been aggressively boxing login credentials for decades at this point. This kind of issue was well discussed when I did my degree well over a decade ago.

It’s the same discussion as “don’t use floating point for money” and yet I’ve seen it done at every startup I’ve joined with all the same mistakes.

And if it turns out to be wrong for whatever reason, you can be confident your fixes will propagate anywhere the types are defined. If the situation is extremely bad, especially the sort of thing where all the users must still do something that you can't offload entirely on to the type (such as an entirely new set of methods and flow for correct usage), you can define a brand new type and the compiler will guide you as to how to force the entire system to be fixed as you push the new type in and remove the old one.

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.

Yeah, I tolerated the AI tint in this article only because it was very informative otherwise.

    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

I agree that this is an issue, but if an attacker has access to the private key of a pinned certificate, you might have some bigger issues...

when I first read your comment, I agreed, but it’s actually a little bit deeper than that.

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.

You're not wrong that there is indeed a significant issue, but the parent isn't wrong either. If the attacker already has a private key you've probably already lost the war. Yes there's a real issue there but by the time an attacker reaches it they're already in the castle's keep.

> the parent isn't wrong either... if the attacker already has a private key you've probably already lost the war.

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).

This is authz bypass, not authn, right? You're an unprivileged user and can assume privileged roles.

Yes and https://discuss.hashicorp.com/t/hcsec-2024-05-vault-cert-aut... was an earlier authN+authZ bypass in the same code block.

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.

On behalf of the OpenBao project, I welcome collaboration with future researchers. We were not informed of these vulnerabilities before HashiCorp posted their usual CVE bulletins, which is disappointing. (Especially as HashiCorp's Vault no longer has an Open Source edition ;-)

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!)

As someone who is actively migrating from HCP Vault Dedicated to self-hosted OpenBao, thanks for this update. Any CVE issues worth tracking / linking here?

Since HashiCorp and OP did not opt to disclose to OpenBao, the most authoritative source right now is HashiCorp's security tracker, linked down-thread: https://news.ycombinator.com/item?id=44821779

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.

Somebody has to say this so I guess I'll take the hit: part of the cost of an unsanctioned fork of a large project is that you're not going to be in the embargo list. Even with a large base of developers and users, the mechanics of a community-driven open source project can make people gun-shy about pre-disclosing.

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.

I'll bite ;-) Appreciate your replies as always tptacek!

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.

These are all points well taken. I'd just say, don't look for any kind of coherent fairness in vulnerability embargo lists. Certainly, if you're a fork that the upstream doesn't want to exist, I don't think there's any norm that you'll automatically be included. I'm irritated about a number of embargo lists myself, but if the vulnerability researchers wanted to include me, they could, regardless of what IBM thought.

The post covers 9 CVEs May-June 2025 (Full chain from default user > admin > root > RCE):

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...

For anyone interested in CVE-2025-6010: https://discuss.hashicorp.com/t/hcsec-2025-21-vault-user-enu...

I've run Vault for a long time, and none of this surprises me. I've even reported some of these to Hashicorp in the past, along with other equally shocking bugs.

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.

OpenBao, under the Linux Foundation's OpenSSF, is making meaningful improvements to the code. I'd love to have high-quality reports, if you're willing to re-visit these. :-)

> The code base is an absolute mess.

This is an understatement, and honestly when I saw it the first time it was enough to make me wonder about all things Hashicorp.

Where were all these people when Vault was released in 2015? I remember being told we were switching to Vault in 2018 and nada. It was like the economists before the 2008 mortgage salad. Did Vault not hire security people? This reminds me of when HeartBleed occurred in 2014. It was after that when someone looked at the code and bugs everywhere. The guy that created Heartbleed got a Phd and the guy that discovered it got a t-shirt. "And then it was acquired by IBM".

I don't think the code is a mess (I've had to work with it before) and I don't think these vulnerabilities are shocking. This is an unusually thorough research project and if you look at any project you're going to find these kinds of logic vulnerabilities; the TOCTTOU parse differential thing is a classic insidious finding, because there's no pattern to match it to.

I'll +1 this. I've personally committed code to Vault and the OpenBao changes go hand-in-hand with the style of the Vault codebase. I enjoy both projects and appreciate that they both exist.

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.

> The code base is an absolute mess.

As a bystander, can you give any examples? Is it just poorly structured, full of spaghetti, or something else?

> This default is 30 seconds, matching the default TOTP period. But due to skew, passcodes may remain valid for up to 60 seconds (“daka” in Hebrew), spanning two time windows.

Wait, why would I care this is "daka" in Hebrew? Is this a hallucination or did they edit poorly?

Maybe just being cute. Author is Yarden Porat from Cyata, an Israeli cybersecurity company.

So perhaps using AI writing tools for English to polish his writing, since English may not be his first language and he doesn’t want stumbling around English syntax to get in the way of his message.

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.

What would including a reference to a Hebrew word in their English article have to do with polishing his writing? You seem to have gotten off the track of the original "evidence" while still fixating on the AI hypothesis.

(Your comment is at least more charitable than the first couple in this thread, but still factually shaky at best.)

Also... what is "daka" ? 60 seconds? passcodes that remain valid for two time windows? I've been checking the dictionary and "daka" might mean "minute".

https://s3.amazonaws.com/LCG/40kconquest/ffg_WHK03_34.jpg

Fun language fact: "daka" is hebrew for "minute" but it's literal meaning is "thin one" figurative being "the thin (shorter) time measure" in contradiction with an hour ("sha'aa")

Fascinating, "dakika" is "minute" in Swahili...probably similar in Arabic as well...yup, Google AI says "daqiqa" for the Latin alphabet version of minute in Arabic.

"minute" is also "small"

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

Lolllllllll "Daka" is an Easter egg I added. Because I have a friend named Daniel. And this is an inside joke

Please don't pick the most provocative thing in an article or post to complain about in the thread. Find something interesting to respond to instead.

https://news.ycombinator.com/newsguidelines.html

It's a good writeup, and I understand that it's Black Hat week and so the intensity meter is dialed up to 11 on these things. Some of these vulnerabilities are pretty clever. But these are mostly situational, things that would typically get sev:med or lower on an assessment.

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").

I generally dont like seeing these "blind username enumeration" type issues.

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.

Always? How many do it this way? The standard solution is to set a timer.

This feels like a dupe of https://news.ycombinator.com/item?id=44821250.

Edit: replaced link with link to HN post, not the article in that post.

There's no way a general security aggregator website qualifies as a better submission than the actual folks who actually discovered the vulns. They deserve all the recognition and to tell the story in their own words

Going by the naming, this was reported to Hashicorp prior to 10th June?

And as it's now August, is it redacted as not fixed yet? Why not

CVE-2025-6010 - [REDACTED]

I do not speak for HashiCorp, but they have published information on this CVE here: https://discuss.hashicorp.com/t/hcsec-2025-21-vault-user-enu...

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.

> reasonably confident

why does this phrase not fill me with confidence?

To quote a movie, only a Sith deals in absolutes ;-)

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.

Why do you care? This is not a very meaningful vulnerability --- it's a side channel user enumeration. Even direct user enumeration is a sev:info finding.

Anybody else just wrapping SOPS in a rest api call and using that? Feel like that is just as good from my experience. While I think Vault is useful for large companies, I just need something to encrypt and decrypt and not rely on pgycrypto

But does it affect Bao? Could test there since they are so closely related.

OpenBao maintainer here - The majority of these does affect us, more or less. Unfortunately it seems that we did not receive any prior outreach regarding these vulnerabilities before publication... make of that what you will. We've been hard at work the past days trying to get a security release out, which will likely land today.

Thanks for the great work and swift communication

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?

I can explain* researchers (and myself, though have nothing to do with it): We both learned about OpenBao today.

explanation ≠ excuse

Thank you for the explanation. It's obviously not great that this was missed, but finger-pointing now doesn't really help anyone, so I'll focus on what seems to me like the root issue

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 sounds like these issues are from before the fork, in which case they will be

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

Something feels odd reading the article. It's so verbose like it's trying to explain things like the reader is 5yo.

AI written, or edited.

I'd say edited, I did wonder if they used AI to find the issues in the first place but they would brag about that front and center and pivot to an AI-first security company within seconds. Then again, maybe they used AI to help them map out what happens in the code, even though it's Go code and should be pretty readable / obvious what happens.

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 don't think they would brag about it if they were found by AI, but based on their description I suspect most of this work was definitely done by LLMs, and then checked by humans.

I am not sure you are correct here :) As the one who found the 9 cves. I am pretty sure I a not an LLM. But these days, it is hard to know.

(No llm were used for the research)

Why do you have that belief? If some researcher used AI, they'd be singing the praises of AI from the rooftops. There'd be Show HN on how cool AI is that it can find CVEs. VCs would be flooding the dev with offers, for what reason who knows, but that's VCs.

Why would you think someone would hide the use of AI? I'm not familiar with a timeline with that behavior.

Infosec is a bit different - this industry is all about (1) expert knowledge and (2) secret sauce. You disclose a part of your secrets, like the security findings, and in exchange your reputation for expert knowledge increases. Telling the world "I automated the boring parts with LLMs" will not only get you "duh, everybody does it now" but will cast doubt on your expertise. That's why these repeated disclaimers at the beginning "we didn't use fuzzers etc., it was all manual process because we knew what to look for" etc.

It was definitely edited by AI or written on the basis of initial information. Which is a pity because I'd love to see the original, it has more value for me.

This sentiment sums up why i dislike the broad use of LLMs and generative words/art/music. Genuine Human work has more value to me than anything generated by a computer.

I like humans. I've even loved a few. I like what humans do; warts, typos and awkward phrasing included.

https://youtu.be/SbeNRICgzTA?si=YdLrozOEtCBTclW2

Mmm AI writing gotta love it… /s

it really does have that AI writing style, and these are the sorts of bugs I imagine an AI could have found...I wonder if that's what they did (though they claim it was all manual source code inspection).

Having the blog post explaining the findings written - or aided - by an AI doesn't necessarily mean that the findings themselves were found using AI.

Edit: even if the TLD they use is .ai and they heavily promote themselves as revolutionary AI security firm yadda yadda yadda

From reading it and mostly from the introduction, it felt like they rolled up their sleeves and really dug into the code. This was refreshing versus the vibe-coding zeitgeist.

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.

I can imagine they could have used AI to analyze, describe and map out what exactly happens in the code. Then again, it's Go, following the flow of code and what exactly is being checked is pretty straightforward (see e.g. https://github.com/hashicorp/vault/blob/main/vault/request_h... which was mentioned in the article)

> .I wonder if that's what they did (though they claim it was all manual source code inspection).

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.

TLDR: string parsing is hard and most of us are vulnerable to assumptions and/or never get around to do those fuzzy tests properly when checking that input is handled correctly.

I don't see any parsing going on here. They failed to normalize the input values the way that the LDAP server does before applying rate limiting resulting in an effectively higher than expected login attempt rate limit.

A lot of these are on the pattern of normalising input as late as possible, which is an odd choice for a security product.

I mean… it's hashicorp… did you expect sanity?

One of the vault backends has a size limit and so secret keys larger than 2048 bits would not fit. Amazing tool.

I'd argue it's odd that they (or LDAP) normalise input in the first place. I can sort-of understand username normalization to avoid having both "admin" and "Admin" accounts, but that check only needs to be done when creating an account, when logging in it should not accept "Admin" as valid for account "admin".

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.

It’s enterprise product, a ton of money can be made by trying to parse complete garbage being tossed at you and delivering it.

Security products are just products like everything else. They're not written differently than normal infrastructure products.

Website link is broken?

Try https://cyata.ai

Fantastic work guys. Thank you.

Reply on news.ycombinator.com