CVE-2025-6000

What it actually does

A privileged Vault operator in the root namespace who can write to sys/audit can cause the Vault process to execute attacker-controlled code on the host when plugin_directory is set. This is a breakout from Vault administrative control to OS-level execution as the Vault service account, with access to process memory, local configuration, unseal/auto-unseal material if present on disk, and all secrets the node can reach. It is not unauthenticated remote code execution; it requires an already-powerful operator token and a specific configuration.

Why it matters to the business

If a Vault administrator account is malicious or stolen, the attacker can leave the secrets platform and take over the underlying server, threatening the confidentiality of production credentials, certificates, and encryption keys and enabling persistence or ransomware against systems that depend on Vault. The issue is high-severity (CVSS 9.1) but currently low likelihood of mass exploitation: it is not in CISA KEV, EPSS is about 0.009 with no 30-day rise, exploit maturity is none, and no named campaigns are associated. Residual risk is mainly insider abuse and post-compromise token reuse. Instances still unpatched more than a year after the 2025-08-01 fix remain exposed wherever plugin_directory is enabled.

How an attack unfolds

An attacker first obtains a highly privileged Vault identity in the root namespace with write permission on sys/audit (stolen token, compromised IdP mapping, or a malicious operator). They confirm the server is configured with a plugin directory. They then misuse audit-device configuration so Vault loads and runs code from that directory in the Vault process, yielding a host shell or implant as the Vault user. From there they harvest tokens, secrets, and host credentials. No public exploit or ransomware use is reported; treat this as a privileged breakout, not an internet worm.

How to fix it

Upgrade to a fixed release: Vault Community Edition 1.20.1 or Vault Enterprise 1.20.1, 1.19.7, 1.18.12, or 1.16.23 (upstream fix commit b403b1a27c8db6038ffefb296d7be0962e08039d). Until patched, do not set plugin_directory unless required; restrict write to sys/audit to the smallest set of break-glass identities; avoid sharing root-namespace operator tokens; run Vault as a non-root user with a tight filesystem policy on the plugin path; and treat operator tokens as production-privileged credentials (short TTL, MFA, tight audit).

How to confirm the fix worked

Confirm every Vault cluster reports a fixed version (CE 1.20.1 or Enterprise 1.20.1 / 1.19.7 / 1.18.12 / 1.16.23). Inventory HCL/JSON config and runtime for plugin_directory; if present, justify it and lock down directory permissions. Review policies so non-break-glass identities cannot write sys/audit. After upgrade, verify the service starts cleanly, existing audit devices still function, and a non-privileged token cannot enable or update audit devices.

Typical attack path

1. Compromise or abuse a root-namespace operator identity with write access to sys/audit
2. Confirm Vault is running with plugin_directory configured
3. Misuse audit-device configuration to induce host code execution in the Vault process
4. Run follow-on activity as the Vault OS user (credential and secret theft, persistence, lateral movement)

How to detect it

There is no public exploit, KEV listing, or named actor activity, so hunt for abuse of the privileged path rather than a known payload. Review Vault audit logs for enable, disable, or tune of audit devices (writes under sys/audit) by human or unexpected identities, especially in the root namespace. On the host, look for new or modified files in the configured plugin directory, unexpected child processes of the vault process (shells, interpreters, reverse-connection tools), and outbound connections from the Vault service account that do not match normal storage, KMS, or telemetry destinations. Correlate with IAM/IdP logs for theft or elevation of operator tokens around the same time. Prioritize clusters that had plugin_directory set before they were patched.

• path:*sys/audit*
• operation:update AND path:sys/audit*
• plugin_directory
• process_name:vault AND child:(sh OR bash OR dash OR ksh OR zsh OR python OR python3 OR perl OR ruby OR nc OR ncat OR socat)

What your security team should do

• Patch all Vault Community and Enterprise clusters to 1.20.1 (or Enterprise 1.19.7 / 1.18.12 / 1.16.23) as a privileged-breakout fix, even though this CVE is not in KEV
• Disable plugin_directory where custom plugins are not required; if required, restrict ownership, mode, and who can write that path
• Remove write capability on sys/audit from standing operator policies; use short-lived, MFA-backed, break-glass roles only
• Hunt historical audit logs for unexpected sys/audit writes and unexpected binaries in the plugin directory, then rotate tokens and secrets if abuse is found
• Harden the Vault host (non-root service user, no extra sudo, isolated disk for plugins) so a future operator breakout has less blast radius