OpenBao's Inline Auth Incorrectly Redacted Headers
Description
Impact
OpenBao's inline auth functionality incorrectly redacted audit log entries, resulting in non-auth headers being removed and auth-related headers being retained in cleartext. This requires an attacker to compromise access to the audit device. Operators should review leaked source authentication material and rotate it as appropriate.
Patches
This is fixed in OpenBao v2.5.4.
Resources
https://github.com/openbao/openbao/issues/3074
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
OpenBao's inline auth incorrectly redacts audit log headers, leaking auth secrets and omitting non-auth headers.
Vulnerability
OpenBao versions prior to 2.5.4 contain a flaw in the inline authentication functionality where the audit log header redaction logic is inverted. Non-auth request headers are stripped from audit entries while auth-related headers (such as X-Vault-Inline-Auth-Parameter-password) are retained in cleartext. This affects all deployments using inline auth with audit logging enabled. [1][2][3]
Exploitation
An attacker must first compromise access to the OpenBao audit device or audit log storage. No additional authentication or special privileges are required beyond that access. The attacker can then read audit log entries that contain cleartext inline auth credentials, such as passwords sent in custom headers. The bug is triggered whenever a request is made using inline authentication (i.e., headers like X-Vault-Inline-Auth-Path and associated parameters). [3]
Impact
Successful exploitation results in disclosure of sensitive authentication material (e.g., passwords) embedded in the inline auth headers. This can lead to unauthorized access to the OpenBao instance using the leaked credentials. The confidentiality of audit logs is compromised, and operators may need to rotate affected credentials. [1]
Mitigation
The vulnerability is fixed in OpenBao version 2.5.4, released on the same date as this advisory. Users should upgrade to v2.5.4 immediately. There is no known workaround. Operators should also rotate any credentials that may have been logged in audit records prior to upgrading. [1][4]
AI Insight generated on May 28, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
2Patches
1131c6966af4dFix audit logs dropping custom headers when using inline auth (#3076)
2 files changed · +4 −1
changelog/3076.txt+3 −0 added@@ -0,0 +1,3 @@ +```release-note:bug +core/auth: fix audit logs dropping custom headers when using inline auth +```
vault/request_handling.go+1 −1 modified@@ -457,7 +457,7 @@ func (c *Core) CheckToken(ctx context.Context, req *logical.Request, unauth bool delete(req.Headers, consts.InlineAuthPathHeaderName) delete(req.Headers, consts.InlineAuthOperationHeaderName) for header := range req.Headers { - if !strings.HasPrefix(header, consts.InlineAuthParameterHeaderPrefix) { + if strings.HasPrefix(header, consts.InlineAuthParameterHeaderPrefix) { delete(req.Headers, header) } }
Vulnerability mechanics
Root cause
"Inverted conditional in header-filtering loop causes all non-auth headers to be deleted and auth-related headers to be retained in audit logs."
Attack vector
An attacker who has already compromised access to the audit device can observe audit logs that incorrectly retain auth-related headers (e.g., `x-vault-inline-auth-parameter-password`) in cleartext while stripping non-auth custom headers (e.g., `x-custom-header`) [ref_id=1]. The bug is triggered on any authenticated endpoint when inline auth is used — the attacker does not need to send a specially crafted payload; the flawed redaction logic in `CheckToken` [patch_id=2967734] does the opposite of what was intended.
Affected code
The bug is in `vault/request_handling.go` in the `CheckToken` function [patch_id=2967734]. The code iterates over `req.Headers` and deletes headers that do **not** have the `consts.InlineAuthParameterHeaderPrefix` prefix, which is the inverse of the intended logic — it should delete headers that **do** have that prefix.
What the fix does
The patch [patch_id=2967734] changes the condition from `!strings.HasPrefix(header, consts.InlineAuthParameterHeaderPrefix)` to `strings.HasPrefix(header, consts.InlineAuthParameterHeaderPrefix)`. This flips the logic so that only headers with the inline auth parameter prefix are deleted, instead of deleting every header that does **not** have that prefix. The commit message confirms the fix: "we should be checking and removing all headers with the inline auth prefix instead of removing all headers without the inline auth prefix" [patch_id=2967734].
Preconditions
- authAttacker must have compromised access to the audit device/log storage
- inputInline auth must be used on the request (headers like X-Vault-Inline-Auth-Path and X-Vault-Inline-Auth-Parameter-* present)
- configAudit logging must be enabled and configured
Reproduction
1. Start an OpenBao dev server with file audit logging enabled and configure a custom header for audit logging (e.g., `x-custom-header`). 2. Enable `userpass` auth and create a user. 3. Send a request to an authenticated endpoint (e.g., `sys/audit`) with both an inline auth header (e.g., `X-Vault-Inline-Auth-Parameter-password`) and a custom header (e.g., `X-Custom-Header: test`). 4. Inspect the audit log — the custom header is missing from the response entry, while the auth parameter header is present in cleartext [ref_id=1].
Generated on May 28, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
6- github.com/advisories/GHSA-q8cj-789h-vg24ghsaADVISORY
- github.com/openbao/openbao/commit/131c6966af4dfb4e1906703436eecdb8f2a3e9dfghsa
- github.com/openbao/openbao/issues/3074ghsa
- github.com/openbao/openbao/pull/3076ghsa
- github.com/openbao/openbao/releases/tag/v2.5.4ghsa
- github.com/openbao/openbao/security/advisories/GHSA-q8cj-789h-vg24ghsa
News mentions
0No linked articles in our index yet.