CVE-2025-6013

What it actually does

HashiCorp Vault’s LDAP auth method can fail to enforce configured MFA when username_as_alias is enabled and a directory user has multiple CNs that are identical except for leading or trailing whitespace. Alias normalization treats those CNs as the same identity, so an LDAP login can complete and a Vault token can be issued without the MFA challenge that should have been required.

Why it matters to the business

Vault often holds production secrets, cloud credentials, and encryption keys; an MFA skip on LDAP login can turn a stolen or reused directory password into full secret-store access. Risk is confined to LDAP auth mounts with username_as_alias=true and users whose CNs differ only by padding spaces. Likelihood is currently low: CVSS 6.5, EPSS about 0.5% and flat over 30 days, not on CISA KEV, no known ransomware use, and no public exploit. Residual exposure remains in unpatched Vault Community/Enterprise and in downstream images (including Chainguard/Wolfi kaniko variants) until they are upgraded.

How an attack unfolds

An adversary who already holds valid LDAP credentials for an affected identity authenticates to a Vault LDAP auth mount that has username_as_alias enabled. Because Vault may map whitespace-padded CNs to the same alias, the login can be associated with an identity that does not trigger the MFA requirement. Vault then returns a client token as if MFA succeeded. The attacker uses that token to read secrets, generate dynamic credentials, or change policies within the token’s scope. No in-the-wild campaigns or named threat actors are associated with this issue.

How to fix it

Upgrade Vault Community Edition to 1.20.2 or later, or Vault Enterprise to 1.20.2, 1.19.8, 1.18.13, or 1.16.24 (Git fix 824d12909d5b596ddd3f34d9c8f169b4f9701a0c). Rebuild or pull patched container images: Chainguard/Wolfi kaniko, kaniko-compat, kaniko-warmer, and kaniko-warmer-compat at 1.25.1-r2 or newer. Until patched, disable username_as_alias on LDAP auth mounts or require MFA at a layer that does not depend on CN alias matching, and clean directory CNs so identities are not distinguished only by whitespace. Rotate tokens issued via LDAP auth after the upgrade.

How to confirm the fix worked

Confirm the running Vault version is at or above the fixed releases (CE 1.20.2; Enterprise 1.20.2 / 1.19.8 / 1.18.13 / 1.16.24). Inspect each LDAP auth mount and verify username_as_alias is false unless required, and that MFA enforcement still applies after login. In directory data, search for users with duplicate CNs that differ only by spaces. For image-based deployments, confirm kaniko-family packages are 1.25.1-r2 or later. After upgrade, perform a legitimate LDAP login for a previously affected identity and verify the MFA challenge is presented and a token is not issued until MFA succeeds.

Typical attack path

1. Locate a Vault cluster that uses the LDAP auth method with username_as_alias enabled and MFA policies attached.
2. Obtain valid LDAP credentials for a user whose directory entry has multiple CNs that differ only by leading or trailing spaces.
3. Submit an LDAP login to Vault using the alias mapping that does not enforce MFA.
4. Receive a Vault token without completing the MFA challenge.
5. Use the token to access secrets, leases, or other Vault APIs allowed by the identity’s policies.

How to detect it

There is no public exploit and no named actor activity, so hunting is configuration- and audit-log based rather than signature-based. Review Vault audit logs around LDAP logins (typically paths under auth/<mount>/login for ldap mounts) for successful token issuance where MFA was configured but no MFA satisfaction is recorded. Look for identity aliases or usernames with leading or trailing whitespace, repeated logins for the same user under slightly different CN strings, and auth mounts with username_as_alias enabled. Correlate those events with subsequent secret reads (sys/wrapping, cubbyhole, kv, database, aws, etc.) from the issued token. On hosts, confirm Vault binary/package version and LDAP auth config in Vault’s storage/config rather than relying on network IOCs.

• username_as_alias
• auth/ldap/login
• "type":"ldap"
• leading or trailing space in LDAP CN/alias (e.g. " cn" or "cn ")
• Vault versions prior to 1.20.2 (CE) or 1.19.8 / 1.18.13 / 1.16.24 (Enterprise)

What your security team should do

• Patch all Vault Community and Enterprise clusters to the listed fixed versions as a priority, even though this CVE is not in KEV.
• Inventory LDAP auth mounts for username_as_alias=true and MFA assignments; treat those mounts as exposed until upgraded.
• Upgrade Chainguard/Wolfi kaniko, kaniko-compat, kaniko-warmer, and kaniko-warmer-compat images to 1.25.1-r2+ where Vault is bundled.
• After patching, revoke and rotate LDAP-issued Vault tokens and review policies granted to LDAP aliases.
• Normalize LDAP CNs to remove leading/trailing whitespace duplicates so alias collisions cannot recur.
• Enable and retain Vault audit logs covering auth/ldap login paths for retrospective review.