OpenBao CVE-2026-115363

Two concrete preconditions must both hold: (1) the OpenBao operator must have configured External Account Binding (EAB) with ACME (RFC 8555) for certificate acquisition on TLS-enabled listeners, so that tls_acme_eab_mac_key exists in configuration - this is not a default setup; and (2) the caller must have sufficient privilege (PR:H) to invoke the sys/config/state/sanitized endpoint, which is a privileged administrative interface. Exploitation is limited to affected versions 2.2.0 through <2.6.4 and 2.7.0 through <2.7.1. The high-privilege access requirement and the non-default ACME-EAB configuration are the primary factors limiting real-world exposure; no user interaction is required (UI:N).

This is a genuinely low-priority issue, and the signals are consistent rather than conflicting. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:H/UI:N/VC:L/VI:L/VA:N) scores only 2.1, and the vuln.today decision label is 'monitor' - both pointing to low urgency. The PR:H requirement is the dominant limiting factor: the sys/config/state/sanitized endpoint is a privileged administrative interface, so a caller must already hold a high-privilege OpenBao token to reach the disclosed value. AT:P reflects a real deployment precondition - the operator must actually be using ACME EAB for TLS listener certificates - without which the sensitive value is not present to leak. No EPSS score is provided and the CVE is not in CISA KEV, so there is no evidence of active exploitation; the only public artifacts are the GHSA and VulnCheck advisories (no public exploit identified at time of analysis). The impact is narrow: disclosure of a single secret (the ACME EAB MAC key) enabling an already-privileged caller to bind to the operator's ACME account. Net assessment: a correctly-rated low-severity information-disclosure bug with a high access barrier and a non-default configuration precondition - patch during normal maintenance, not an emergency.

An operator has configured OpenBao TLS listeners to obtain certificates via ACME with External Account Binding. An actor who already holds a high-privilege token queries sys/config/state/sanitized, which should redact secrets but instead returns the tls_acme_eab_mac_key; the actor then uses that key to bind to and act against the operator's ACME account. No public exploit is identified, and exploitation requires both the EAB configuration and privileged endpoint access.