Live › vulnerability › CVE-2026-115362
Go to dashboardOpenBao does not check Secret ID expiration when a client logs in through the AppRole auth method, so an expired Secret ID keeps working until the periodic tidy job deletes it. An attacker holding such an expired, not-yet-tidied Secret ID can obtain a token and access beyond its intended lifetime.
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.
Teams that run OpenBao with the AppRole auth method and issue Secret IDs with expiration times, particularly those that hand Secret IDs to automated systems. Deployments that do not use AppRole, or that issue no expiring Secret IDs, are not affected by this flaw.
No product ranges from the sources yet.
bao version and compare against the fixed releases.bao auth list and whether Secret IDs use short TTLs with bao read auth/approle/role/<role>.bao read auth/approle/config or the tidy settings in the server configuration.2.6.4 or later on the 2.6 line, or 2.7.1 or later on the 2.7 line.bao write -f auth/approle/role/<role>/secret-id/destroy and rotate them on a shorter schedule.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
OpenBao before 2.6.4 and 2.7.x before 2.7.1 does not check Secret ID expiration at use in the AppRole auth method, leaving expired Secret IDs valid until the periodic tidy removes them. An attacker holding an expired, untidied Secret ID can log in and gain access beyond its TTL.
This page as .md · .json · in your agent: get_signal("CVE-2026-115362")
NVD data is provided by NIST and is public domain · EPSS scores by FIRST, used with attribution. Posts quoted belong to their authors.