CVE-2025-6011

What it actually does

A timing side channel in HashiCorp Vault and Vault Enterprise’s userpass authentication method causes measurable differences in response time between login attempts for existing versus non-existing usernames. An unauthenticated remote attacker who can submit userpass login requests can statistically distinguish valid accounts from invalid ones and enumerate usernames registered to that auth method. The flaw does not by itself bypass authentication, disclose passwords, or grant token or secret access; it is an information-disclosure issue that weakens username confidentiality for userpass. It is fixed in Vault Community Edition 1.20.1 and Vault Enterprise 1.20.1, 1.19.7, 1.18.12, and 1.16.23.

Why it matters to the business

Vault commonly stores production secrets, cloud credentials, certificates, and encryption keys, so even a low-severity username leak can shrink the work required for later password spraying or credential stuffing against a high-value control plane. CVSS 3.7, EPSS about 0.0034 with a flat 30-day trend, no KEV listing, and no known exploit maturity indicate limited mass-exploitation pressure today, but unpatched userpass endpoints still expand the reconnaissance surface of any internet- or network-reachable Vault. Organizations that rely on userpass (rather than SSO or certificate auth) face the greatest residual risk until they upgrade.

How an attack unfolds

An attacker who can reach the Vault API submits many userpass login attempts using guessed or harvested usernames and a dummy password, then compares response latency (and, at scale, timing distributions) to infer which names correspond to real users. With a list of confirmed usernames, the attacker can focus subsequent password guessing, phishing, or credential-stuffing against those accounts rather than blindly attacking a larger name space. There are no named threat actors or ransomware campaigns associated with this CVE, and public exploit maturity is none; abuse would typically appear as noisy, high-volume failed logins rather than a single-shot remote takeover.

How to fix it

Upgrade Vault Community Edition to 1.20.1 or later, or Vault Enterprise to 1.20.1, 1.19.7, 1.18.12, or 1.16.23 (or later on the supported branch). Source builds of hashicorp/vault should include the fix commit b403b1a27c8db6038ffefb296d7be0962e08039d. Prefer migrating off userpass to SSO, OIDC, or certificate-based auth where practical; restrict network access to the Vault API; and enforce lockout, rate limiting, and MFA on remaining userpass mounts. Do not rely on obscuring the login path as a substitute for patching.

How to confirm the fix worked

Confirm the running Vault version is Community 1.20.1+ or Enterprise 1.20.1 / 1.19.7 / 1.18.12 / 1.16.23+ (vault status / version APIs or package inventory). Verify userpass mounts still function for legitimate users after upgrade. On unpatched systems, exposure is present wherever userpass is enabled and the API is reachable; inventory auth methods and network exposure rather than attempting timing tests in production. After patching, failed logins for unknown and known users should no longer be distinguishable by response-time class.

Typical attack path

1. Identify a reachable Vault API that has the userpass auth method enabled.
2. Submit repeated login attempts for candidate usernames with incorrect passwords.
3. Measure and compare response times (or aggregate timing) to classify usernames as existing or not.
4. Compile a list of confirmed userpass usernames.
5. Use that list in follow-on password spraying, credential stuffing, or social engineering against Vault.

How to detect it

Hunt historically in Vault audit logs and reverse-proxy/WAF logs for bursts of failed userpass logins (path /v1/auth/userpass/login/<username>) from the same source, especially many distinct usernames with uniformly wrong passwords and no successful token issuance. Timing-based enumeration may not leave a unique payload, so look for volume, username cardinality, and low success rate rather than a signature string. Correlate with auth method userpass, HTTP 400/403 on login, and absence of subsequent token use. There is no public exploit kit or named actor TTPs; treat pre-patch reconnaissance as failed-auth noise, not confirmed compromise of secrets.

• POST /v1/auth/userpass/login/
• auth_method=userpass
• path=auth/userpass/login
• "type":"userpass"
• vault login -method=userpass
• error":"invalid username or password

What your security team should do

• Patch Vault to Community 1.20.1 or Enterprise 1.20.1, 1.19.7, 1.18.12, or 1.16.23 on a standard maintenance cycle; this is not a KEV/emergency RCE.
• Inventory every cluster that has userpass enabled and treat internet-facing userpass as higher priority.
• Enable MFA, lockout, and API rate limits on userpass; prefer SSO/OIDC over long-lived userpass passwords.
• Alert on high-volume failed userpass logins and username-enumeration-like patterns even after patching.
• Reduce Vault API exposure with network allowlists, private connectivity, and identity-aware proxies.