CVE-2025-5999

What it actually does

An authenticated Vault operator who already has write access to the identity API in the root namespace can bind Vault’s unrestricted root policy to their own or another principal’s entity, group, or alias. Tokens associated with that identity then inherit full cluster superuser capabilities (all paths, all operations), converting a scoped administrative identity into equivalent-to-root access. This is vertical privilege escalation in identity-to-policy binding, not unauthenticated remote code execution.

Why it matters to the business

Abuse yields unrestricted access to every secret, encryption key, certificate, lease, and auth configuration the cluster holds, enabling mass secret theft, backdoored authentication, forged tokens, and outages for applications that depend on Vault. Exploit likelihood is low (EPSS about 0.5%, not in CISA KEV, no public exploit maturity, no ransomware association), but impact is catastrophic for any organization that treats Vault as the secrets source of truth. The issue has been public for well over a year, so remaining unpatched clusters are avoidable residual risk rather than an emerging campaign.

How an attack unfolds

An already-privileged operator authenticates to Vault and uses write permission on the root-namespace identity endpoint to attach the built-in root policy to an entity, group, or alias tied to a target token (their own or another user’s). Subsequent use of that token inherits unrestricted root capabilities. The attacker can then read or rewrite mounts, mint durable admin tokens, alter policies and auth methods, and optionally weaken audit settings. Exploitation requires an existing high-privilege operator identity with identity-write in the root namespace; it is not a network-facing unauthenticated attack, and no named threat actors or KEV activity are associated with this CVE.

How to fix it

Upgrade HashiCorp Vault Community Edition to 1.20.0 or later, or Vault Enterprise to 1.20.0, 1.19.6, 1.18.11, or 1.16.22 (or any later supported release on those trains). The upstream fix is commit 6fdd6b59e97d97a9e19b0fb5304bf879c190295e. After upgrade, review and tighten ACLs so identity write in the root namespace is limited to a break-glass subset of operators, revoke and reissue tokens that may have been bound to the root policy via identity, and rotate secrets that those identities could have read. Do not rely on configuration workarounds as a substitute for the version upgrade.

How to confirm the fix worked

Confirm running Vault version is Community 1.20.0+ or Enterprise 1.20.0 / 1.19.6 / 1.18.11 / 1.16.22+. Inventory policies granting create/update on identity/* (and related entity/group/alias paths) in the root namespace and verify they match an approved operator set. List entities, groups, and aliases for unexpected attachment of the root policy. After patching, verify a non-root identity-write principal can no longer cause a token to inherit the root policy, and that audit logging remains enabled for identity writes.

Typical attack path

1. Obtain or abuse an operator identity that already has write on the root-namespace identity API
2. Authenticate to Vault and identify the entity, group, or alias bound to the target token
3. Update that identity object so the built-in root policy is attached
4. Reuse the elevated token to enumerate mounts, read secrets, and mint additional admin tokens
5. Optionally change audit, auth, or policy configuration to retain access after the original operator credential is rotated

How to detect it

Review Vault audit logs (file, syslog, or socket device) from before the upgrade for write/update operations on identity entity, group, and alias paths in the root namespace that add the root policy, followed by use of the affected token against privileged paths such as secret mounts, sys/auth, sys/policy, or token creation. Correlate operator authentication events with subsequent identity mutations and unexpected root-equivalent requests. On disk, inspect audit log destinations and Vault server logs around identity API activity. Because no public exploit tooling or named actors are associated with this CVE, look for insider or compromised-operator patterns rather than commodity malware artifacts.

• request.path containing identity/entity
• request.path containing identity/entity/id/
• request.path containing identity/entity/name/
• request.path containing identity/group
• request.path containing identity/group/id/
• request.path containing identity/group-alias
• request.path containing identity/entity-alias
• /v1/identity/entity
• /v1/identity/group
• audit operation update or create on identity paths with policies including root
• "root" policy attached via identity entity or group update
• sys/auth writes shortly after identity policy changes
• auth/token/create following an identity entity or group update

What your security team should do

• Patch all Vault Community and Enterprise clusters to a fixed version on a priority commensurate with secrets-platform criticality, even though EPSS and KEV risk are low
• Immediately inventory who can write identity in the root namespace and remove standing identity-write from day-to-day operator roles
• Hunt historical audit logs for identity updates that attached the root policy and revoke/reissue any implicated tokens
• Rotate secrets, AppRole credentials, and encryption keys reachable by identities that held identity-write or unexpected root policy bindings
• Enforce break-glass procedures and dual control for root-namespace identity and policy changes going forward