Introduction
A header sanitization flaw in HashiCorp Vault can silently forward valid Vault tokens to auth plugin backends. That leaks credentials across a trust boundary operators reasonably expect Vault to enforce. The vulnerability is tracked as CVE-2026-4525 and HCSEC-2026-07. For any organization that relies on Vault's auth plugins with custom header passthrough configurations, it means tokens intended solely for Vault authentication may have been exposed to downstream plugins for a long stretch of releases, from version 0.11.2 through 1.21.4.
Technical Information
Root Cause: Incomplete Header Sanitization
Vault's auth methods support an operator-configurable setting called passthrough_request_headers, which forwards specific HTTP headers from the client request to the auth plugin backend. It is a legitimate feature, used to pass plugins the contextual information they need for their authentication logic.
The flaw is in Vault's request processing pipeline. When the Authorization header is included in the passthrough_request_headers list for an auth mount, and a client uses that same Authorization header to authenticate to Vault (carrying a Vault token), Vault fails to sanitize the token from the header before forwarding the request to the plugin. The Vault token travels with the request to the auth plugin backend, across a trust boundary it was never meant to cross.
The weakness is classified under CWE-201: Insertion of Sensitive Information Into Sent Data. The label fits, because Vault embeds a sensitive credential in an outbound request to a downstream component.
Preconditions for Exploitation
The vulnerability triggers only when both of these conditions hold at the same time:
- A Vault auth mount has its
passthrough_request_headerssetting configured to include theAuthorizationheader. - The client authenticates to Vault with the
Authorizationheader, so the Vault token is carried in that header.
With both in place, Vault forwards the request to the auth plugin backend without stripping the Vault token.
Attack Flow
An attacker who controls or has compromised an auth plugin backend (or who can observe traffic between Vault and the plugin) could capture the Vault token from the forwarded Authorization header. With a valid Vault token, the attacker could then authenticate directly to Vault and inherit whatever permissions and policies are attached to that token. The CVSS vector CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H reflects this. Attack complexity is high because the specific configuration must be in place, but the impact on confidentiality, integrity, and availability is rated high across the board.
The High attack complexity rating comes from the configuration preconditions, not from any sophisticated exploitation technique. Once the preconditions are met, the token leaks automatically on every qualifying request.
Trust Boundary Violation
Vault is expected to act as the trust boundary between clients and auth plugin backends. Operators configure header passthrough expecting Vault to handle its own authentication credentials separately from the data it forwards. This vulnerability breaks that assumption and, under specific configurations, turns the passthrough_request_headers feature into a vector for credential leakage.
Affected Systems and Versions
The vulnerability affects a broad range of HashiCorp Vault releases in both the Community and Enterprise editions.
| Product Edition | Affected Versions | Fixed Versions |
|---|---|---|
| Vault Community Edition | 0.11.2 up to 1.21.4 | 2.0.0 |
| Vault Enterprise | 0.11.2 up to 1.21.4, 1.20.9, and 1.19.15 | 2.0.0, 1.21.5, 1.20.10, and 1.19.16 |
The vulnerable configuration requires the passthrough_request_headers setting on an auth mount to include the Authorization header. Organizations that do not use this configuration are not affected, whatever their Vault version.
The exposure window is long, reaching back to version 0.11.2. Any environment that has used Authorization header passthrough on auth mounts in the past should consider that tokens may have been exposed, and review its logs accordingly.
Vendor Security History
HashiCorp, which IBM acquired in February 2025, is the CVE Numbering Authority for this vulnerability. The advisory was published on April 16, 2026, and patches shipped at the same time across multiple supported branches of both the Community and Enterprise editions. Oleh Konko of 1seal found and reported the vulnerability, and HashiCorp acknowledged the contribution publicly. HashiCorp's bulletin expresses appreciation for coordinated disclosure, which indicates a mature vulnerability disclosure program. The coordinated multi-branch patch release shows operational readiness in HashiCorp's security response process.
