HashiCorp Vault Hacked at Black Hat 2025: MFA Bypassed With a Space Character

If you are an engineering student, a fresher, or someone who works in DevOps, cloud infrastructure, or backend development, this is exactly the kind of real-world security research you need to understand. Not because you need to defend Vault right now, but because the thinking behind these attacks applies to almost every system you will ever build or work with.

What is HashiCorp Vault?

Before we get into the vulnerabilities, it helps to understand what Vault is and why it is such a high-value target.

HashiCorp Vault is an open-source secrets management tool. It was first released in 2015, is written in Go, and is used by thousands of companies around the world. Its job is to store sensitive credentials in one secure place, things like database passwords, API keys, cloud access tokens, TLS certificates, and encryption keys.

In a modern software company, hundreds of services need to talk to each other. Each of those connections requires credentials. Without something like Vault, those credentials end up hardcoded in config files, environment variables, or worse, in code repositories. Vault centralizes all of that and provides controlled, audited, time-limited access to secrets.

Here is why it matters from a security perspective. If an attacker gets into Vault, they do not get one password. They potentially get every password, every API key, every database credential stored in it. It is the master key to an organization’s entire infrastructure. Security teams call this a “keys to the kingdom” scenario.

Who Did This Research and When

The research was done by Shahar Tal and Yarden Porat from a company called Cyata Security, an identity security firm. Their Black Hat USA 2025 talk was titled “Vaulted Severance: Your Secrets Are Now Outies.”

They spent several weeks doing a deep manual review of Vault’s source code, focusing specifically on how Vault handles authentication, identity resolution, and policy enforcement. They were not using automated scanners or fuzzers. They were reading the code, thinking about edge cases, and writing targeted test cases based on what they found.

The result was nine previously unknown zero-day vulnerabilities, each assigned its own CVE. They followed responsible disclosure and worked with HashiCorp to get everything patched before going public. HashiCorp published official security bulletins (HCSEC-2025-13 through HCSEC-2025-22) in August 2025 acknowledging all the findings.

This was also the 10th anniversary of HashiCorp Vault. A decade of production use, trusted by enterprises globally, and these logic flaws had been sitting quietly in the codebase for most of that time.

The Full Attack Chain: How They Broke In

The attack was not one single trick. It was a chain of smaller findings stacked on top of each other. Let us go through each one in order.

Step 1: Finding Valid Usernames Without Guessing Passwords

The first challenge for any attacker is figuring out which usernames actually exist. Vault made this unintentionally easy in two different ways.

CVE-2025-6010: Error Message Mismatch

When you fail to log in with a username that exists, Vault gives you one specific error message. When you use a username that does not exist, especially after the lockout threshold is hit, Vault gives a slightly different message. An attacker can just try a list of common usernames and sort the responses. Real usernames reveal themselves through the error text. This is called username enumeration.

CVE-2025-6011: Timing Side Channel

Even if the error messages were identical, there is a second method. When Vault processes a login attempt for a real user, it has to run a bcrypt password comparison, which is intentionally slow and takes measurable time. For a fake username, Vault skips that step and returns early. The response arrives slightly faster. By timing the responses, an attacker can tell which usernames are real and which are not, without looking at any error message text at all.

Step 2: Brute-Forcing Passwords Without Ever Getting Locked Out

Vault has a lockout policy. After 5 failed login attempts, the account gets locked. This is supposed to stop brute-force attacks completely. The researchers found a way around it.

CVE-2025-6004: Lockout Bypass via Case Permutation (Userpass)

Vault tracks failed login attempts by the exact string of the username. So admin, Admin, ADMIN, and aDmIn are all treated as different users, each getting their own independent 5-attempt lockout counter.

For an 11-character username, the number of possible uppercase and lowercase combinations is 2 raised to the power of 11, which equals 2,048. With 5 attempts per combination, an attacker gets over 10,000 password guesses against a single account with no lockout ever triggered.

CVE-2025-6004: Lockout Bypass in LDAP (With Space Variations)

In LDAP-based authentication (used in most enterprise setups with Active Directory), the same bug exists but gets much worse because of spaces.

LDAP servers normalize usernames. They trim leading and trailing spaces, and they ignore case differences. So alice, Alice, alice , and alice are all treated as the same user by the LDAP server.

Vault, however, stores the lockout counter against the exact string as typed. So all four of those are different counters in Vault’s mind.

Combine space variations with case permutations and the math becomes staggering:

1,000 (leading space variants)
x 1,000 (trailing space variants)
x 2,048 (case combinations for 11-char username)
x 5 (attempts per window)
= approximately 10 BILLION password guesses
with zero lockouts triggered

The LDAP server happily checks the same account each time because it normalizes the input. Vault’s lockout never fires because it thinks it is seeing billions of different users.

Step 3: Bypassing MFA With One Space Character

This is the finding that got the most attention, and rightfully so. It is technically simple, surprisingly hard to catch in a code review, and devastating in impact.

CVE-2025-6013 and CVE-2025-6003: MFA Enforcement Bypass

Vault’s LDAP authentication has an optional configuration setting called username_as_alias. When this is set to true, the username you type becomes your identity record in Vault’s identity system. Multi-factor authentication is then tied to that identity record.

Here is how the bypass works, step by step:

1. Admin configures MFA enforcement for the user alice. This creates an identity entity in Vault tied to the alias alice.
2. Attacker (who already has alice’s password from the brute-force step) logs in as alice (with a trailing space).
3. The LDAP server receives alice , trims the space, authenticates it as alice successfully. Login is valid.
4. Vault receives the success response from LDAP. It now needs to create an identity alias. But instead of using the normalized DN from LDAP’s response, it uses the raw input string that the attacker provided, which is alice with the space.
5. Vault creates a new identity alias for alice . This is a completely separate entity from alice.
6. The MFA enforcement rule is attached to alice not alice , so Vault never triggers the MFA challenge.
7. The attacker is fully logged in with no second factor asked.

The root cause is an input normalization mismatch. Two systems (Vault and LDAP) receive the same input and interpret it differently. The gap between their interpretations is where the security check disappears.

HashiCorp confirmed this in their official bulletin HCSEC-2025-20: “When setting the alias name on successful login, the ldap auth method would set the entity alias name to the value provided by the user rather than using the normalized user DN information returned by the ldap directory.”

Step 4: Bypassing TOTP MFA Separately

Even if you are not using LDAP, Vault’s TOTP-based MFA (the rotating 6-digit code kind, like Google Authenticator) was also broken.

CVE-2025-6015 and CVE-2025-6016

TOTP codes are supposed to be single use. Once you use a code, it should be invalidated immediately so nobody can reuse it within its 30-second validity window. Vault had a bug where a TOTP code could be reused. The space padding trick also applied here: submitting the same code with different spacing created different cache keys, allowing the same code to be validated multiple times. On top of that, rate limiting on MFA attempts could be bypassed by switching between entity IDs or skewing the time window.

Step 5: The First Ever Remote Code Execution in HashiCorp Vault

Once the researchers had authentication access, they went further. Much further.

CVE-2025-6000: RCE via Audit Logging and Plugin Abuse

Vault has a plugin system that allows operators to extend its functionality with custom plugins. To prevent malicious plugins from being loaded, Vault requires each plugin to be registered with a cryptographic hash (SHA-256). Only plugins whose hash matches the registration are allowed to load. The plugin must also be in an approved plugin directory.

The researchers found a way to satisfy both requirements without ever having direct write access to the plugin directory.

Vault’s audit logging feature writes logs to a file path that administrators configure. The researchers pointed that audit log path directly to Vault’s plugin directory. Now every log entry Vault wrote landed as a file in the plugin directory.

Vault’s audit logger also supports a prefix setting. The researchers used this to inject a shebang line (#!/bin/sh) as the first line of every log file. On Unix systems, a shebang line tells the OS to treat the file as an executable script.

To get the correct hash registered without physically accessing the file, they used two audit backends simultaneously (file and socket). By synchronizing the two backends, they could deterministically calculate what the final file content would look like, compute the SHA-256 hash of that content in advance, and register it in Vault before the file was even written.

With the hash registered and the file in the plugin directory, they loaded the “plugin.” Vault accepted it as legitimate. Their code executed on the host machine.

No memory corruption. No buffer overflow. Pure logic abuse of three legitimate features that individually do exactly what they are supposed to do.

This chain had existed in Vault’s codebase for nearly a decade.

The CyberArk Conjur Attack: Pre-Auth RCE

The Cyata team also presented a completely separate attack at the same session, this time targeting CyberArk Conjur, another widely used secrets management system popular in CI/CD pipelines and machine identity management.

This one was even more alarming because it required zero authentication. No username, no password, no credentials of any kind.

The Regex Flaw That Gave Attackers a Server-Side Redirect

CyberArk Conjur supports AWS IAM authentication, where it contacts AWS’s Security Token Service (STS) to verify identity. The URL of the STS endpoint is configurable per region, something like sts.us-east-1.amazonaws.com.

Conjur validates this URL using a regular expression to make sure it is a legitimate AWS endpoint. But the regex was written too loosely. An attacker could submit a URL like sts.attacker.com?us-east-1.amazonaws.com. The regex would see us-east-1.amazonaws.com in the string and pass validation, not noticing that the actual domain being contacted was attacker.com.

Conjur would then send its authentication requests to the attacker’s server instead of AWS. The attacker’s server could return whatever response it wanted.

Type Confusion Leading to Code Execution

After redirecting the authentication request to their server, the researchers were able to authenticate as a “policy” identity inside Conjur. They then exploited a type confusion vulnerability across multiple Conjur API endpoints, the host factory, secret endpoint, and policy factory, to inject embedded Ruby code. Conjur evaluated it and executed it.

Full control of the Conjur node. No valid credentials required at any point.

The Bigger Lesson: Memory Safety Is Not Enough

This is the part that every computer science student and software engineer needs to sit with.

HashiCorp Vault is written in Go. Go is a memory-safe language. CyberArk Conjur is written in Ruby. The security industry has spent years saying “use memory-safe languages and you will avoid most vulnerabilities.” Buffer overflows, use-after-free bugs, dangling pointers: all gone when you use Go or Rust or Python instead of C.

But not a single vulnerability in this research had anything to do with memory. Every one of them was a logic bug. A wrong assumption about how two components would interpret the same data. A mismatch between what one system normalizes and what another system stores.

The specific pattern here is called input normalization mismatch. It works like this:

• System A receives input and normalizes it before use (strips spaces, lowercases, trims)
• System B receives the same input and stores it raw
• Security checks in System B are indexed against the raw input
• System A authenticates the normalized version
• The two systems disagree on identity
• Security checks fall through the gap

This class of bug is incredibly common across distributed systems, microservices, and any architecture where two components handle the same piece of data independently. It does not show up in memory scanners, fuzzers, or automated static analysis tools. It only appears when a human reads the code carefully and asks “what happens if System A and System B process this differently?”

That is why these bugs survived for nearly a decade in a high-profile, actively maintained, open-source codebase that thousands of engineers contribute to.

Affected Versions and Patches

If you or your organization runs HashiCorp Vault, here is what you need to know:

The vulnerabilities were reported to HashiCorp in May 2025 and patched by August 2025. All findings were disclosed responsibly before going public.

What Organizations Should Do Right Now

Whether you are a developer, a DevOps engineer, or a security professional, here is what this research translates into as practical action:

1. Patch Immediately

If you are running Vault Community Edition below 1.20.2 or any of the Enterprise versions listed above, upgrade now. HashiCorp’s official upgrade guide is at developer.hashicorp.com/vault/docs/upgrading.

2. Check Your LDAP Configuration

If you use LDAP authentication with username_as_alias=true and MFA enforced at the EntityID or IdentityGroup level, you had the exact configuration required for the space-based MFA bypass. Even after patching, review your recent authentication logs for entries with unusual whitespace in usernames or unexpected alias creation events.

3. Audit Your Plugin Directory and Audit Log Configuration

Check what path your audit logs are being written to. They should never point to or overlap with your plugin directory. Review who has permission to modify audit backend configuration.

4. Do Not Treat MFA as a Final Safety Net

This research showed that MFA can be bypassed through logic flaws that have nothing to do with cryptography or brute force. MFA is important, but it is one layer, not the entire defense. Combine it with network access controls, proper vault segmentation, anomaly-based alerting, and regular credential rotation.

5. Review Your Audit Logs Proactively

Cyata released an open-source tool called Audit Finder specifically to help detect suspicious patterns in Vault audit logs. Audit logs that nobody reads are just disk space. If your team is not actively monitoring them, now is the time to start. Unusual patterns like repeated authentication attempts with slight username variations are exactly the kind of signal that catches attacks like this.

6. Run a Vault Breach Drill

Most incident response plans assume that the secrets manager is safe and focus on containing damage in other systems. This research proves that assumption is no longer valid. Add a “Vault is compromised” scenario to your incident response drills and think through what the blast radius would look like in your environment.

What This Means for Engineers and Students

If you are learning software development or security, the key takeaway from this research is not “HashiCorp Vault was insecure.” It is much more transferable than that.

Every time you build a system where two components handle the same input, ask yourself: do they both normalize it the same way? What happens if one trims spaces and the other does not? What happens if one is case-sensitive and the other is not? What happens at the boundary between your authentication layer and your authorization layer?

Security checks that live at component boundaries are only as strong as the agreement between those components on what the identity actually is. When that agreement breaks, the check disappears silently. No error, no crash, no alert. Just an open door.

This is the kind of thinking that separates engineers who write code that works from engineers who write code that is hard to break.

Complete List of CVEs From This Research

References

• Black Hat USA 2025 Session: “Vaulted Severance: Your Secrets Are Now Outies” by Shahar Tal and Yarden Porat, Cyata Security
• Cyata Security Research Blog: cyata.ai/blog/cracking-the-vault
• HashiCorp Official Security Bulletin: HCSEC-2025-22 (covers all eight bulletins)
• HashiCorp Upgrade Guide: developer.hashicorp.com/vault/docs/upgrading
• Official CVE disclosures: CVE-2025-6000 through CVE-2025-6037
• Source: Black Hat USA 2025
• Researchers: Shahar Tal & Yarden Porat, Cyata Security
• CVEs: CVE-2025-6000, CVE-2025-6003, CVE-2025-6004, CVE-2025-6010, CVE-2025-6011, CVE-2025-6013, CVE-2025-6015, CVE-2025-6037