OpenBao EUVD-2026-108426

Exploitation requires the attacker to already possess a renewable OpenBao token that was originally issued through the Kubernetes Auth method (PR:L authenticated). The flaw is specific to the Kubernetes Auth method's token-renewal path, which fails to re-verify that the service account token used for the original login is still valid. The practical precondition - and the attack's whole point - is that the backing Kubernetes service account has since been deleted or revoked, yet the attacker continues renewing the OpenBao token. Limiting factors: no new unauthenticated access is granted; it only prolongs access that was already obtained, it applies only to tokens from the Kubernetes Auth method, and it is confined to OpenBao versions before 2.6.4 and 2.7.x before 2.7.1. Remediation is upgrading to 2.6.4 or 2.7.1 as the advisory states; no alternative mitigation is given.

This is a genuine but moderate-priority issue, not a critical emergency. The assigned CVSS 4.0 score is 5.3 (medium) with vector AV:N/AC:L/AT:N/PR:L/UI:N and low confidentiality/integrity impact (VC:L/VI:L), no availability impact - consistent with CWE-613 (insufficient session expiration), where the harm is persistence of already-granted access rather than fresh compromise. The vuln.today decision label is 'this_month', signaling a planned-remediation rather than act_now/emergency urgency. Critically, exploitation requires the attacker to already hold a valid token previously issued via the Kubernetes Auth method (PR:L), so this is a post-authentication persistence flaw, not a path to initial access. No EPSS score, SSVC automatable/technical-impact decision, or KEV listing is present in the input, so widespread or automated exploitation cannot be asserted - exploitation status is 'no public exploit identified at time of analysis' (the two references are vendor/coordinator advisories, not PoC or working exploit code). No signals conflict here; rather, several priority signals (EPSS, KEV, SSVC) are simply absent, and the available ones (medium CVSS, PR:L requirement, this_month label) all point to a contained, moderate risk whose main concern is defeating service-account revocation as a security control.

An attacker who has already authenticated to OpenBao through the Kubernetes Auth method - for example using a compromised or legitimately-held service account token - is later supposed to lose access when that service account is deleted or revoked. Instead, because OpenBao does not re-validate the originating service account token at renewal time, the attacker simply keeps renewing their OpenBao token to retain access indefinitely. No public exploit code is identified; the only published artifacts are the OpenBao GHSA advisory and the VulnCheck advisory.