Vault Vulnerability: Authenticated Users Can Trigger DoS via Path Glob Policy

The National Vulnerability Database has disclosed CVE-2026-3605, a high-severity vulnerability (CVSS 8.1) impacting HashiCorp Vault Community and Enterprise editions. This isn’t a remote code execution or data exfiltration flaw, but it’s a critical denial-of-service vector that demands immediate attention from anyone running Vault.

Specifically, an authenticated user with access to a kvv2 path, governed by a policy containing a glob (*), can delete secrets they were not explicitly authorized to read or write. This is a classic authorization bypass, even if it’s limited in scope. While it doesn’t allow cross-namespace deletion or secret data exfiltration, the ability to arbitrarily delete secrets within an authorized path is disastrous for operational integrity.

Think about the attacker’s calculus here. They don’t need to exfiltrate data to cause chaos. A well-placed deletion of critical secrets – API keys, database credentials, certificates – can bring down entire applications, services, or even infrastructure. This isn’t about data theft; it’s about operational disruption and integrity compromise.

For CISOs and security architects, this highlights the perennial challenge of managing granular permissions, especially with dynamic secrets and infrastructure-as-code. Glob policies are convenient, but they introduce complexity that can easily lead to unintended authorization boundaries. This vulnerability is a stark reminder that convenience often comes with a security cost.

Defenders need to understand that an attacker, once authenticated, doesn’t need elevated privileges to exploit this. A standard user account, if its policy is misconfigured with a glob on a kvv2 path, becomes a weapon. This underscores the importance of least privilege principles and rigorous policy review, particularly in highly sensitive systems like secret managers.

The fix is available in Vault Community Edition 2.0.0 and Vault Enterprise 2.0.0, 1.21.5, 1.20.10, and 1.19.16. If you’re running any earlier version, you are exposed. This isn’t a vulnerability to defer patching on; the potential for catastrophic service disruption is too high.