CVE-2026-115363 in OpenBao
Summary
by MITRE • 10/22/2026
OpenBao 2.2.0 before 2.6.4 and 2.7.0 before 2.7.1 contains an information disclosure vulnerability that exposes the tls_acme_eab_mac_key value through the sys/config/state/sanitized endpoint. Callers of the sanitized configuration endpoint can retrieve the ACME External Account Binding MAC key used for TLS listener certificates, letting them bind to the operator's ACME account.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified in OpenBao versions prior to 2.6.4 and 2.7.1 represents a critical information disclosure flaw within the system's configuration management interface. Specifically, this issue resides in the sys/config/state/sanitized endpoint, which is designed to return configuration data while attempting to redact sensitive secrets such as passwords or private keys. However, due to an oversight in the sanitization logic applied during the serialization of the TLS ACME (Automatic Certificate Management Environment) configuration state, the tls_acme_eab_mac_key value remains exposed in plaintext within the API response. This key is essential for establishing External Account Bindings with Let's Encrypt or other ACME-compatible certificate authorities, serving as a cryptographic proof that binds the OpenBao instance to a specific operator account on the CA side.
From a technical perspective, this flaw allows any authenticated user who possesses access to the sys/config/state/sanitized endpoint to retrieve credentials that should be strictly confidential. The tls_acme_eab_mac_key is not merely a static password but a critical component of the ACME protocol's authentication mechanism for external account bindings. By obtaining this MAC key, an attacker can impersonate the OpenBao operator at the certificate authority level. This capability enables the unauthorized generation of TLS certificates under the organization's domain names without needing access to private keys or other traditional PKI controls. The vulnerability effectively bypasses the intended security boundary between internal configuration management and external identity verification mechanisms.
The operational impact of this disclosure is severe, as it compromises the integrity and authenticity of the organization's public-facing infrastructure. An attacker leveraging this stolen key can request valid TLS certificates for any domain managed by the ACME account associated with that MAC key. This facilitates man-in-the-middle attacks against internal services or external customer-facing applications if those domains are included in the certificate scope. Furthermore, it undermines trust in the PKI ecosystem maintained by OpenBao, as attackers could issue rogue certificates that appear legitimate to clients and browsers. The exposure of this credential also poses a risk for lateral movement within cloud environments where ACME accounts might be linked to broader IAM permissions or billing details associated with the certificate authority provider.
This vulnerability aligns closely with CWE-200: Information Exposure, as it involves the unintended leakage of sensitive data through an API endpoint that is supposed to filter such information. In terms of offensive security frameworks, this flaw facilitates actions categorized under MITRE ATT&CK technique T1558.003: Steal or Forge Kerberos Tickets using Golden Ticket, although in this context, it maps more directly to credential theft and abuse for certificate forgery rather than traditional ticket forging. It also relates to CWE-798: Use of Hard-coded Credentials if the key was improperly stored, but primarily reflects a failure in data sanitization logic during API response generation.
To mitigate this risk, organizations running OpenBao must immediately upgrade to version 2.6.4 or later for the 2.x stable branch, or version 2.7.1 and above for the newer release line where this sanitization bug has been corrected. In addition to upgrading, it is imperative that administrators rotate all ACME External Account Binding MAC keys associated with their certificate authority accounts immediately after patching, as any previously exposed key remains valid until revoked by the CA. Security teams should also audit access logs to identify if the sys/config/state/sanitized endpoint was accessed during the window of vulnerability and assess whether any unauthorized certificates were issued using the compromised credentials. Implementing strict RBAC policies that limit who can query configuration states further reduces the attack surface for this type of information disclosure.