CVE-2026-115363: 
Wolfi vulnerability analysis and mitigation

CVE-2026-115363 is an information disclosure vulnerability in OpenBao that exposes the tls_acme_eab_mac_key value through the sys/config/state/sanitized endpoint. When an operator uses External Account Bindings (EAB) with ACME (RFC 8555) for TLS listener certificate acquisition, the sensitive MAC key is inadvertently returned to callers of the sanitized configuration endpoint. Affected versions are OpenBao 2.2.0 through 2.6.3 and 2.7.0, with fixes available in 2.6.4 and 2.7.1. It carries a CVSS v4 base score of 2.1 (Low) (GitHub Advisory, Feedly).

The root cause is classified as CWE-212 (Improper Removal of Sensitive Information Before Storage or Transfer): the sys/config/state/sanitized endpoint, which is intended to return a redacted view of the OpenBao configuration, fails to scrub the tls_acme_eab_mac_key field before returning it to the caller. Exploitation requires network access and high privileges (an authenticated, privileged API caller), and the attack also requires specific deployment conditions — namely, that the operator has configured ACME EAB for TLS listeners. No public proof-of-concept code has been identified (GitHub Advisory, VulnCheck).

A high-privileged attacker who can call the sys/config/state/sanitized endpoint can retrieve the ACME External Account Binding MAC key, which is used to authenticate certificate requests to the operator's ACME CA account. With this key, an attacker could bind to the operator's ACME account and potentially issue or manage TLS certificates on its behalf, representing a limited but meaningful integrity and confidentiality impact. Availability is not affected, and there is no direct path to broader system compromise or lateral movement from this vulnerability alone (GitHub Advisory, Feedly).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported for CVE-2026-115363. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation is constrained by the requirement for high privileges and the specific deployment condition of ACME EAB being configured, significantly limiting the attacker pool (Feedly, VulnCheck).

1. Prerequisite: Obtain high-privileged credentials (e.g., a root or admin token) for an OpenBao instance running version 2.2.0–2.6.3 or 2.7.0 that has ACME EAB configured for TLS listeners.
2. Query the sanitized endpoint: Send an authenticated HTTP GET request to GET /v1/sys/config/state/sanitized using the privileged token.
3. Extract the MAC key: Parse the JSON response and locate the tls_acme_eab_mac_key field, which is incorrectly included in the response instead of being redacted.
4. Abuse the EAB MAC key: Use the retrieved MAC key to construct a valid ACME EAB credential and bind to the operator's ACME CA account, enabling unauthorized certificate issuance or management (GitHub Advisory).

• Logs: Audit log entries showing authenticated requests to GET /v1/sys/config/state/sanitized from unexpected or unauthorized principals, particularly outside of normal administrative activity.
• Network: Unexpected ACME protocol traffic (e.g., to Let's Encrypt or other ACME CAs) originating from sources other than the OpenBao server itself, which may indicate unauthorized use of the EAB MAC key.
• ACME CA Account: New or unexpected account bindings or certificate orders appearing in the operator's ACME CA account dashboard that were not initiated by the operator.

Operators should upgrade OpenBao to version 2.6.4 (for the 2.x stable branch) or 2.7.1 (for the 2.7.x branch), which patch this vulnerability by properly redacting the tls_acme_eab_mac_key from the sanitized configuration endpoint. After upgrading, operators who used ACME EAB on affected versions should consider rotating their EAB MAC key with their ACME CA provider, as the previously configured key may have been exposed. Restricting access to the sys/config/state/sanitized endpoint to only trusted administrative principals is a recommended defense-in-depth measure (GitHub Advisory, VulnCheck).

The vulnerability was published by the OpenBao project maintainer (cipherboy) via a GitHub Security Advisory on October 1, 2026, and credited to researchers Luiggi33, Remediation developer, and opensec-intelligence. No significant broader media coverage or notable community commentary beyond the advisory itself has been identified at this time (GitHub Advisory).