Live › vulnerability › CVE-2026-115363
Go to dashboardOpenBao's sys/config/state/sanitized endpoint exposes the tls_acme_eab_mac_key value used for ACME external account binding. A caller of that endpoint can read the key and bind to the operator's ACME account.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Only deployments of OpenBao 2.2.0 up to 2.6.4 and 2.7.0 that use ACME for TLS listener certificates with an external account binding key are exposed. Callers need access to the sanitized configuration endpoint, so teams that restrict sys/ paths or do not use ACME can skip it.
No product ranges from the sources yet.
bao version and compare against the fixed versions listed in fix.tls_acme_eab_mac_key or uses ACME TLS listeners, since the key only matters in that setup.2.6.4 on the 2.6 line, or to 2.7.1 on the 2.7 line.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-115363")
NVD data is provided by NIST and is public domain · EPSS scores by FIRST, used with attribution. Posts quoted belong to their authors.