OpenBao EUVD-2026-108287

Exploitation requires that (1) the target deployment uses the AppRole auth method, (2) the attacker already possesses a specific Secret ID that was legitimately issued and has since passed its TTL, and (3) that expired Secret ID has not yet been removed by the periodic tidy process, which the advisory states runs once every minute. These factors sharply limit realistic exploitation: the attacker must already hold a valid-but-expired credential (reflected as PR:H), and there is only a narrow timing window between TTL expiry and the next tidy sweep (contributing to AC:H). Deployments not using AppRole, or where Secret IDs are promptly tidied, are not meaningfully exposed; versions at or above 2.6.4 and 2.7.1 are fixed.

All decision signals converge on low real-world priority. The vendor's CVSS 4.0 base score is 2.1 (Low): although the vector is network-reachable (AV:N) with no user interaction (UI:N), it carries high attack complexity (AC:H), requires high privileges (PR:H - the attacker must already possess a legitimately-issued Secret ID), and the only impact is low integrity to the vulnerable system (VI:L) with no confidentiality or availability impact (VC:N/VA:N) and no scope change. The vuln.today/SSVC-style Decision label is 'monitor', which is consistent with this profile. There is no CISA KEV listing and no indication of active exploitation, so exploitation status is 'no public exploit identified at time of analysis' - the two references are the GHSA and VulnCheck advisories, not working exploit code. Note two data gaps: no EPSS score was provided in the input (so widespread-exploitation probability cannot be quantified here), and the vendor supplied only a CVSS 4.0 vector, not a 3.1 vector. The practical risk is bounded by the design: an expired Secret ID is only usable in the narrow window after its TTL lapses but before the once-per-minute tidy ticker removes it, and only against deployments that actually use the AppRole auth method.

A departed contractor, decommissioned service, or compromised process retains an AppRole Secret ID whose TTL has already expired. Because OpenBao does not re-check expiration at login time, the holder authenticates successfully before the periodic tidy ticker (which runs roughly once per minute) purges the stale Secret ID, thereby regaining access past the intended credential lifetime. No public exploit code was identified; only vendor/VulnCheck advisories exist.