CVE-2025-4166

What it actually does

HashiCorp Vault Community and Enterprise Key/Value (kv) Version 2 mishandles malformed create/update request bodies on the REST API such that secret material that should stay inside encrypted storage can be written in recoverable form to Vault server logs and audit logs. The defect is information disclosure in logging/error handling, not remote code execution, authentication bypass, or unauthorized secret read through the Vault data API.

Why it matters to the business

Secrets (credentials, tokens, certificates, and similar values) may appear in operational logs that are typically retained longer than secret policy allows and are readable by a broader set of operators, SIEM users, and log-pipeline identities than Vault ACLs intend. That creates insider-risk, downstream credential-reuse, and audit/compliance exposure around a core secrets manager. Exploit likelihood is low: CVSS 4.5, EPSS about 0.45% with only a small 30-day rise, not on CISA KEV, no known ransomware use, and no public exploit maturity. Residual risk is mainly unpatched clusters and historical log copies still holding leaked values more than a year after publication.

How an attack unfolds

An actor who already holds a Vault token (or an application identity) with write access to a kv v2 mount submits a malformed payload on a secret create or update via the REST API. Vault records the failed or malformed request without fully omitting or redacting sensitive fields, so secret values land in server and/or audit logs. Anyone who can read those logs—locally, via syslog, object-storage sinks, backups, or a SIEM—recovers the material without a successful Vault read and without breaking encryption at rest. Accidental malformed writes by legitimate clients can produce the same leakage. No named threat actors or in-the-wild campaigns are associated with this CVE.

How to fix it

Upgrade Vault Community Edition to 1.19.3 or later, and Vault Enterprise to 1.19.3, 1.18.9, 1.17.16, or 1.16.20 (or a later patch on the same train). The upstream fix is commit a2de3bb7bcf4a073cbb8724863a5a88d3c2f83da. After patching, rotate secrets that were created or updated on kv v2 while vulnerable versions were running if those writes could have been logged. Restrict filesystem, syslog, object-storage, and SIEM access to Vault server and audit logs; enable audit HMAC/redaction so request data is not stored in cleartext; and do not log raw request bodies at the reverse-proxy or WAF layer in front of Vault. If upgrade is delayed, reduce who can write to kv v2 mounts and treat all Vault logs as secret-equivalent data.

How to confirm the fix worked

Confirm running builds are Community 1.19.3+ or Enterprise 1.19.3 / 1.18.9 / 1.17.16 / 1.16.20+ via Vault version/build metadata. In a non-production cluster, perform kv v2 create/update attempts that previously produced log leakage and verify secret values no longer appear in server or audit logs. Inventory kv v2 mounts and write activity on any cluster that was unpatched. Review log sinks to ensure audit devices are configured for HMAC/redaction and that proxies are not capturing Vault request bodies.

Typical attack path

1. Obtain or abuse a Vault token or app role that can write to a kv v2 secrets path.
2. Send a create or update to the Vault REST API kv v2 data endpoint with a malformed request body.
3. Trigger server and/or audit logging of the request or error context without proper redaction of secret fields.
4. Access Vault log files, syslog/forwarded logs, log-object storage, or SIEM indexes that ingest Vault output.
5. Extract leaked secret values from those logs.
6. Reuse recovered secrets against downstream systems and, if needed, persist by writing new secrets or tokens.
7. Optionally target log infrastructure itself if Vault ACLs are strong but log access is weak.

How to detect it

There is no public exploit code or named-actor activity; look for evidence of leakage in logs rather than a distinct implant. Review Vault server logs and audit logs from before the patch for kv v2 create/update operations (REST writes under secret data paths) whose request or error context includes unredacted fields or high-entropy secret-like strings. Correlate with identities that performed writes. Inspect log pipelines (local files, syslog, cloud logging, SIEM) for audit entries where request data was stored in cleartext instead of HMAC form. Because the issue is log disclosure, the primary artifacts are historical log lines and retained SIEM events—not new processes, registry keys, or network beacons. After rotation, watch for use of previously logged credentials on downstream systems.

• "mount_type":"kv"
• "path":" with kv v2 "/data/" write paths in Vault audit JSON
• POST or PUT to /v1/*/data/ on Vault listeners around malformed-body errors
• Vault audit "request" objects containing "data" maps without "hmac-sha256:" redaction
• vault audit log entries with operation create or update on kv mounts and plaintext secret-shaped values
• vault.log or systemd journal lines for kv v2 write/decode/unmarshal errors that include request body fragments

What your security team should do

• Patch all Vault Community and Enterprise clusters to 1.19.3 (Community/Enterprise) or Enterprise 1.18.9 / 1.17.16 / 1.16.20 as planned maintenance; this is not a CISA KEV emergency but should not remain open on a secrets platform.
• Treat Vault server and audit logs as sensitive: lock down file, syslog, object-storage, backup, and SIEM ACLs.
• Hunt historical logs for kv v2 write/error events that may contain secret material and rotate anything recovered.
• Enforce least privilege on kv v2 write capabilities and application tokens.
• Enable and verify audit-device HMAC/redaction and disable raw request-body logging on front-end proxies.
• Pin supported Vault versions in secrets-management standards and include this class of log-disclosure in post-upgrade verification.