CVE-2026-46358

This vulnerability in OpenBao's audit logging does the opposite of what it should: it strips metadata like source IP, User-Agent, and timestamps while preserving the actual authentication credentials in cleartext. The redaction logic is inverted—headers that identify the client get removed, while the tokens, AppRole IDs, and LDAP/Kubernetes credentials that authenticate that client are retained. This isn't a simple coding error; it's a fundamental inversion of the security control's intent that suggests the selection criteria for what constitutes 'sensitive' was written backwards at the design level. If an attacker gains access to the audit device—whether through a compromised node, a permissions misconfiguration on shared storage (S3, GCS, Azure Blob), SIEM pipeline access, or log aggregation infrastructure—they obtain cleartext credentials for every authentication event in the retention window. These aren't just OpenBao secrets; they're the credentials used to authenticate TO OpenBao in the first place. That distinction is critical: AppRole role IDs and secret IDs, LDAP service account tokens, and Kubernetes tokens frequently authenticate to systems beyond OpenBao. The CVE ends at OpenBao, but the blast radius extends to whatever those credentials can reach. The CVSS 5.4 assumes audit device compromise is a meaningful prerequisite, but audit storage is systematically under-protected compared to the vault itself—it's often treated as 'just logs,' forwarded to shared SIEM infrastructure, or stored on cheaper object storage with broader IAM permissions. The prerequisite barrier is weaker than the score implies. Additionally, credentials in audit logs may have established standing access or service-to-service trust relationships that survive rotation attempts. Immediate actions: First, enumerate which auth methods (token, AppRole, LDAP, Kubernetes) your OpenBao deployment uses and assume all credentials authenticated during the audit retention window are exposed. Second, audit downstream systems and services that consume those auth paths—they may be reachable with the leaked credentials. Third, rotate all credentials that appeared in audit logs during the exposure window. Fourth, review audit storage permissions: check for shared object storage ACLs, SIEM forwarder access, and any pods or processes that can read the audit volume beyond the OpenBao node itself. The vulnerability is labeled medium-severity, but the downstream credential reuse ecosystem makes the actual impact potentially far larger than the CVE score suggests.

Reviewed through automated stages and approved by a human before publication.