Cracking the Vault: How we found zero-day flaws in HashiCorp Vault

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

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

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

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.

    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

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

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.

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

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

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.

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.

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