OpenBao EUVD-2026-108282

Exploitation requires that the instance has explicitly set disable_unauthed_generate_root_endpoints=false and/or disable_unauthed_rekey_endpoints=false - these endpoints (sys/generate-root/attempt and /update, sys/rekey/init, /update, /verify, and sys/rekey-recovery-key/init, /update, /verify) are disabled by default since OpenBao 2.5.3. In addition, the audit backend must succeed in writing the request entry but fail in writing the response entry for the gap to occur. Limiting factors: the vulnerable endpoints are off by default, so standard deployments are unaffected; the request audit entry is still written, so only the response record is missing; and the only impact is reduced forensic visibility, not disclosure or modification of secrets.

This is a low-priority issue across every available signal. The vendor-supplied CVSS 4.0 score is 2.1 with vulnerable-system impact limited to VI:L (loss of a response audit record); confidentiality and availability impact are N. The vuln.today decision label is 'monitor', not act_now or emergency. No KEV listing is present, no EPSS score was provided in the input, and no PoC or exploit reference appears anywhere in the data, so exploitation status is 'no public exploit identified at time of analysis.' The 4.0 vector uses AT:P, reflecting that the flaw only manifests when request audit logging succeeds but response audit logging fails - a condition the attacker does not reliably control. One notable tension: the affected endpoints are described as 'unauthenticated,' yet the vendor vector sets PR:H; this reflects that the endpoints are disabled by default since OpenBao 2.5.3 and must be explicitly re-enabled in configuration, a deployment precondition rather than an attacker-held privilege - verify this interpretation against the GHSA advisory. The practical impact is a forensic/detection gap, not direct compromise, so this is a genuinely low-severity hardening fix rather than an urgent threat.

An attacker reaches an OpenBao instance that has explicitly enabled the unauthenticated generate-root or rekey endpoints (non-default), and completes a root-token-generation or rekey operation at a moment when the request audit log succeeds but the response audit log write fails. The completed operation then leaves no response audit record, hindering later forensic detection of the privileged action. No public exploit code or PoC reference is present in the supplied data.