CVE-2024-9180

What it actually does

A privileged Vault operator who already has write access to the root namespace identity endpoint can associate Vault’s root policy with an identity they control, converting limited operator rights into unrestricted root-equivalent authorization over secrets engines, auth methods, policies, leases, and audit configuration.

Why it matters to the business

Compromise of the secrets-management plane lets an insider or stolen operator credential steal or alter cloud keys, database passwords, certificates, and application secrets, with potential for broad downstream outage and data exposure. The issue is not in CISA KEV, has no public exploit, and a low, flat EPSS (~0.5%), but Vault is a crown-jewel system and the flaw has been public for a long time, so unpatched clusters remain an unacceptable residual risk.

How an attack unfolds

An attacker who already holds (or steals) a Vault operator identity with write permission on the root namespace identity API uses that access to change identity entities, aliases, or groups so the built-in root policy is attached. Later authentications or tokens bound to that identity inherit root-level rights, which the attacker then uses to read secrets, change policies, disable auditing, or persist access. There is no unauthenticated or pre-auth path; exploitation requires valid privileged credentials and identity-write in the root namespace.

How to fix it

Upgrade HashiCorp Vault Community Edition to 1.18.0 or later, or Vault Enterprise to 1.18.0, 1.17.7, 1.16.11, or 1.15.16 (or a later patch on those trains). Until upgraded, strip write capabilities on root-namespace identity paths from all non-root operators, review entities and groups for unexpected root policy associations, and rotate operator tokens. If abuse is suspected, rotate affected secrets and re-enable or verify audit devices.

How to confirm the fix worked

Confirm the running Vault version is Community 1.18.0+ or Enterprise 1.18.0 / 1.17.7 / 1.16.11 / 1.15.16 or later via the version or sys/health API. Re-read ACL policies to ensure non-root operators lack write on identity endpoints in the root namespace. Enumerate identity entities and groups for unexpected root policy attachments and sample-test that a previously privileged non-root operator can no longer obtain root.

Typical attack path

1. Obtain or abuse a Vault operator token with write on the root namespace identity endpoint
2. Modify a root-namespace identity entity, alias, or group so the root policy is associated with an identity the attacker can assume
3. Authenticate or mint a token bound to the modified identity
4. Use the elevated token to read secrets, alter policies and auth methods, and establish persistence
5. Optionally weaken or disable audit devices and clean identity records to hinder investigation

How to detect it

Search Vault audit logs (file, syslog, or socket devices) for write/update/create operations on identity entity, entity-alias, and group paths in the root namespace, especially where the root policy is added to policies or member_entity_ids. Correlate those events with subsequent tokens that list root among auth.policies, unexpected sys/policy or sys/auth changes, and audit-device disable or tune operations. Review identity storage and policy assignments for entities or groups that currently carry root. There are no named threat actors or public exploit signatures for this CVE; detection is audit- and configuration-based.

• "path":"identity/entity"
• "path":"identity/entity/id/
• "path":"identity/entity-alias"
• "path":"identity/group"
• "path":"identity/group/id/
• "operation":"update"
• "operation":"create"
• "policies":["root"]
• "policy":"root"
• request path containing identity/entity with root policy assignment
• sys/audit disable or tune shortly after identity writes

What your security team should do

• Patch all Vault Community and Enterprise clusters to a fixed release immediately, treating remaining unpatched nodes as overdue given how long the advisory has been public
• Remove identity-write in the root namespace from every non-root policy and break-glass the remaining root tokens
• Hunt historical audit logs for identity entity/group writes that assigned the root policy, then rotate secrets and tokens if any are found
• Verify audit devices are still enabled and that identity and policy changes are logged
• Constrain operator roles with namespace isolation and least-privilege policies going forward