EUVD-2026-30298
GHSA-vv66-6rp4-wr4f
Severity by source
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
3DescriptionGitHub Advisory
Impact
When OpenBao's initial namespace deletion fails, subsequent retries fail to properly remove all data before marking the namespace as deleted. This can affect any outstanding leases as well as potentially leaving unrelated storage entries around.
Patches
This will be patched in OpenBao v2.5.3.
Workarounds
Users may manually remove mounts prior to deleting the namespace.
Audit logs may be used to identify repeated deletion attempts against the same namespace; sys/raw can be used to see what leases were not correctly deleted.
AnalysisAI
OpenBao namespace deletion fails to properly clean up data and revoke leases when the initial deletion attempt is interrupted, potentially leaving orphaned storage entries and outstanding leases in the system. Subsequent retry attempts to delete the same namespace do not trigger proper cleanup, creating information disclosure and data integrity risks. This affects OpenBao versions prior to v2.5.3, with a vendor-released patch available.
Technical ContextAI
OpenBao is a secrets management and data protection platform written in Go. The vulnerability exists in the namespace deletion workflow within the core vault logic. When a namespace deletion operation fails (for example, due to server stepdown during the deletion process), the namespace is marked as 'tainted' but the underlying cleanup routines that revoke associated leases and remove storage entries are not re-executed on subsequent deletion attempts. This is rooted in CWE-212 (Improper Cross-boundary Removal of Sensitive Data), where data expected to be deleted persists beyond its intended lifecycle. The issue specifically affects the lease revocation mechanism in the namespace deletion code path, as evidenced by the patch commit that adds explicit lease revocation logic during namespace re-deletion.
RemediationAI
Upgrade OpenBao to version v2.5.3 or later, which includes the lease revocation fix in the namespace deletion code path. The patch ensures that when a namespace deletion is retried, all associated leases are properly revoked and storage entries are cleaned up before the namespace is marked as deleted. Organizations unable to immediately patch should implement the following workaround: prior to deleting a namespace, manually remove all credential backend and secret engine mounts within that namespace using the sys/mounts API, which reduces the quantity of leases requiring revocation. Additionally, enable and monitor audit logs for repeated deletion attempts against the same namespace (indicated by 'tainted' status in namespace read responses), and use the sys/raw endpoint to inspect and manually clean up any orphaned leases or storage entries in the namespace storage path (sys/raw/namespaces/{namespace-id}). Note that manual cleanup via sys/raw requires direct storage access and carries risk of data corruption if performed incorrectly; it should be treated as a last-resort validation step only. See GitHub advisory GHSA-vv66-6rp4-wr4f for additional details.
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today