CVE-2024-8365 - How HashiCorp Vault Leaked Your Tokens in Plaintext Audit Logs

On June 12, 2024, a critical vulnerability was disclosed that put sensitive secrets at risk for many organizations using HashiCorp Vault. Known as CVE-2024-8365, this security issue affected both the Community and Enterprise editions of Vault. If your infrastructure used Vault audit logs to track access, you might have exposed *plaintext tokens* or *token accessors*—the very keys that let attackers claim your secret data.

In this post, we’ll break down how this happened, who’s at risk, what exploiters could do with this bug, show you sample log entries, and help you secure your setup. All in clear terms, so you don’t need to be a security specialist to understand.

What Happened?

Vault uses audit devices to log every access and operation—for accountability and attack tracing. Since these logs could fall into the wrong hands, Vault normally replaces client tokens and their accessors (identify and access-proof strings) with encrypted hashes called HMACs. This way, even if you see them in the log, you can’t directly use them to access Vault.

But in releases prior to Vault 1.17.5 (and Enterprise 1.16.9), this masking was broken. Instead of HMAC-hiding, Vault stored *raw* client tokens and accessors in plaintext in every audit entry.

> Official Announcement:
> - HashiCorp Security Advisory: CVE-2024-8365

Using audit logs (file, syslog, etc.) on any supported platform

- Especially dangerous if your audit logs are forwarded, monitored, or backed up in shared or insecure locations

What’s the Impact?

If an attacker (external or internal!) viewed your audit logs, they could find valid Vault client tokens or token accessors exposed in plain text. Here’s what that means:

Immediate Vault Access:

Anyone who grabs a raw token from the log can use it to access secrets, impersonate users, or escalate privileges—depending on the token’s capabilities.

Take a look at this sample (redacted) Vault audit log entry before the fix

{
  "time": "2024-06-11T10:15:00.123Z",
  "type": "request",
  "auth": {
    "client_token": "s.odkaw3QmqkzZN50qTpwQzp",
    "accessor":   "u5CAW4YkDcZv5eLaVZwE9XZq"
  },
  "request": { ... }
}

See the client_token? Anyone reading this log now possesses a fully functional access token, which can be immediately used (with the right API call) to read, write, or delete secrets in your Vault—depending on the token’s original policy.

Compare that with a properly HMAC-masked entry (after the fix)

{
  "time": "2024-06-12T04:20:00.456Z",
  "type": "request",
  "auth": {
    "client_token": "hmac-sha256:f5fb6e5c6b1da183...",
    "accessor":   "hmac-sha256:90a5b6cce1a157e1..."
  },
  "request": { ... }
}

Extract a valid token and use it with any Vault client

export VAULT_TOKEN=s.odkaw3QmqkzZN50qTpwQzp
vault kv get secret/my-secrets    # This will succeed if permissions allow

Or, programmatically

import hvac
client = hvac.Client(url="http://VAULT_ADDR";, token="s.odkaw3QmqkzZN50qTpwQzp")
print(client.secrets.kv.v2.read_secret_version(path="my-secrets"))

Immediately update Vault:

- Vault 1.17.5 download
- Vault Enterprise 1.16.9 download

Rotate affected tokens.

- You can use Vault’s /sys/leases/revoke and /auth/token/revoke endpoints.

References and Further Reading

- Vault Security Advisory: CVE-2024-8365
- Vault Changelog
- Vault Audit Devices Docs

Conclusion

CVE-2024-8365 is a classic “regression” bug that shows how even established security features can slip through the cracks with an update—a reminder to always monitor your logs for things that should *never* appear in plain text. Patch your Vault, clean up your logs, and rotate any potentially exposed tokens.

Timeline

Published on: 09/02/2024 05:15:17 UTC
Last modified on: 09/04/2024 17:18:36 UTC