Introduction
A header sanitization flaw in HashiCorp Vault can silently forward valid Vault tokens to auth plugin backends, effectively leaking credentials across a trust boundary that operators reasonably expect Vault to enforce. For any organization relying on Vault's auth plugin ecosystem with custom header passthrough configurations, this vulnerability (tracked as CVE-2026-4525 and HCSEC-2026-07) means that tokens intended solely for Vault authentication may have been exposed to downstream plugins for an extended window spanning versions 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 allows specific HTTP headers to be forwarded from the client request to the auth plugin backend. This is a legitimate feature used to pass contextual information that plugins need to perform their authentication logic.
The flaw lies 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 is sent along with the request to the auth plugin backend, crossing a trust boundary it was never intended to cross.
This is classified under CWE-201: Insertion of Sensitive Information Into Sent Data, which accurately describes the behavior of embedding a sensitive credential into an outbound request to a downstream component.
Preconditions for Exploitation
Two conditions must be met simultaneously for this vulnerability to be triggered:
- Auth mount configuration: A Vault auth mount must have its
passthrough_request_headerssetting configured to include theAuthorizationheader. - Authentication method: The
Authorizationheader must be the mechanism used to authenticate to Vault (i.e., the Vault token is carried in this header).
When both conditions are satisfied, the Vault token is included in the forwarded request to the auth plugin backend without being stripped.
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 in hand, the attacker could then authenticate directly to Vault, inheriting whatever permissions and policies are associated with 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: while attack complexity is high (the specific configuration must be in place), the impact on confidentiality, integrity, and availability is rated high across the board.
It is worth noting that the attack complexity rating of High reflects the configuration preconditions rather than any sophisticated exploitation technique. If the preconditions are met, the token leakage happens automatically on every qualifying request.
Trust Boundary Violation
The core security issue is that Vault is expected to act as the trust boundary between clients and auth plugin backends. Operators configure header passthrough with the expectation that Vault will handle its own authentication credentials separately from the data it forwards. This vulnerability breaks that assumption, making the passthrough_request_headers feature a vector for credential leakage under specific configurations.
Affected Systems and Versions
The vulnerability impacts a broad range of HashiCorp Vault releases across both 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 not using this specific configuration are not affected, regardless of their Vault version.
The exposure window is notably long, stretching back to version 0.11.2. Any environment that has historically used Authorization header passthrough on auth mounts should consider the possibility of past token exposure and conduct appropriate log review.
Vendor Security History
HashiCorp, which was acquired by IBM in February 2025, serves as the CVE Numbering Authority for this vulnerability. The advisory was published on April 16, 2026, with patches released simultaneously across multiple supported branches for both Community and Enterprise editions. The vulnerability was identified and reported by Oleh Konko of 1seal, and HashiCorp publicly acknowledged this contribution. HashiCorp's bulletin noted their appreciation for coordinated disclosure efforts, indicating a mature vulnerability disclosure program. The coordinated multi-branch patch release demonstrates operational readiness in their security response process.
