Vault Token Forwarding Flaw Exposes Auth Backends

The National Vulnerability Database has disclosed CVE-2026-4525, a high-severity vulnerability (CVSS 7.5) in HashiCorp Vault. This isn’t just a misconfiguration; it’s a critical design flaw where Vault, under specific conditions, inadvertently forwards its own authentication token to backend authentication plugins.

The core issue, labeled CWE-201 (Information Exposure Through Sent Data), arises when a Vault authentication mount is configured to pass through the Authorization header, and that same header is simultaneously used to authenticate to Vault itself. In this scenario, Vault’s token, intended for its own internal operations or client authentication, gets blindly relayed to the downstream authentication plugin. This is a significant lapse in trust boundaries.

From an attacker’s perspective, this is a goldmine. Imagine compromising a misconfigured authentication backend. Suddenly, you’re not just dealing with the credentials for that specific plugin; you’ve potentially got a Vault token in hand. This token could grant broader access within the Vault instance, allowing an attacker to enumerate secrets, modify policies, or even exfiltrate sensitive data. It’s an immediate privilege escalation vector.

Defenders need to understand the implications here. This isn’t a vulnerability that requires complex exploits. It’s a logic error that, if conditions are met, hands over the keys. The attacker’s calculus is simple: find a vulnerable Vault instance, identify a misconfigured auth mount, and then compromise the backend of that auth mount. The exposure of the Vault token significantly lowers the bar for lateral movement and deeper compromise.

HashiCorp has addressed this in Vault versions 2.0.0, 1.21.5, 1.20.10, and 1.19.16. Organizations running older versions must prioritize patching immediately. This isn’t a ‘monitor for exploitation’ scenario; it’s a ‘fix it now’ directive. Beyond patching, a thorough audit of all Vault authentication mount configurations, particularly those passing through Authorization headers, is non-negotiable. Ensure that the Authorization header is not redundantly used for both Vault authentication and backend plugin communication in a way that creates this exposure.