CVE-2026-3605: 
HashiCorp Vault vulnerability analysis and mitigation

CVE-2026-3605 is a KVv2 metadata and secret deletion policy bypass vulnerability in HashiCorp Vault that can result in denial-of-service. An authenticated user with access to a KVv2 path through a policy containing a glob pattern may be able to delete secrets they were not authorized to read or write. The vulnerability affects Vault Community Edition versions 0.10.0 through 1.x (prior to 2.0.0) and Vault Enterprise versions prior to 2.0.0, 1.21.5, 1.20.10, and 1.19.16. It was published on April 17, 2026, with a CVSS v3.1 base score of 8.1 (High) (GitHub Advisory, HashiCorp Advisory).

The root cause is an authorization bypass through user-controlled key (CWE-639) combined with authentication bypass using an alternate path or channel (CWE-288), where glob patterns in Vault KVv2 policies are not properly scoped to restrict delete operations. When a policy grants access to a KVv2 path using a glob wildcard, the authorization check for delete operations does not correctly enforce the intended boundaries, allowing an authenticated low-privileged user to delete secrets outside their authorized scope within the same namespace. The attack requires network access, low privileges, no user interaction, and no special configuration beyond having a policy with a glob-based KVv2 path assignment (GitHub Advisory, HashiCorp Advisory).

Successful exploitation allows an authenticated attacker to delete KVv2 secrets they are not authorized to access, causing denial-of-service by destroying secret availability for legitimate users and applications within the same namespace. The vulnerability has high integrity and availability impact, as secrets can be permanently deleted, disrupting dependent workloads and services that rely on those secrets. Critically, the vulnerability does not allow cross-namespace secret deletion or unauthorized reading of secret data, limiting the blast radius to secret availability within the attacker's authorized namespace (GitHub Advisory, HashiCorp Advisory).

As of the time of disclosure, there is no public proof-of-concept exploit and no evidence of in-the-wild exploitation (HashiCorp Advisory). The EPSS score is approximately 0.012% (0.000120), placing it in the 6th percentile for exploitation likelihood within 30 days (GitHub Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and no threat actor attribution has been reported. Exploitation requires authenticated access with at least low privileges, reducing the attack surface compared to unauthenticated vulnerabilities.

1. Reconnaissance: Identify a HashiCorp Vault instance running a vulnerable version (Community Edition < 2.0.0 or Enterprise < 1.19.16, < 1.20.10, < 1.21.5) with KVv2 secrets engine enabled.
2. Obtain authenticated access: Acquire valid credentials or a token for a low-privileged Vault account that has a policy granting access to at least one KVv2 path using a glob pattern (e.g., secret/data/myapp/*).
3. Identify target secrets: Enumerate accessible KVv2 paths within the namespace to identify secrets that fall within the glob pattern scope but are outside the attacker's intended authorization boundary.
4. Trigger unauthorized deletion: Issue a DELETE request (or equivalent Vault CLI/API call) targeting KVv2 metadata or secret paths that the glob pattern inadvertently covers but the policy was not intended to permit deletion of (e.g., vault kv delete secret/data/other-app/credentials).
5. Achieve denial-of-service: The improperly scoped glob authorization allows the delete operation to succeed, permanently removing secrets and disrupting services or applications that depend on those secrets within the namespace (GitHub Advisory, HashiCorp Advisory).

• Logs: Vault audit logs showing DELETE operations on KVv2 paths by a token/entity that does not have explicit delete permissions for those paths; unexpected delete or destroy operations on KVv2 metadata endpoints (/v1/secret/metadata/) from low-privileged accounts.
• Logs: Audit log entries where the auth.policies field contains glob-based KVv2 policies and the request.operation is delete on paths not matching the intended policy scope.
• Behavioral: Sudden disappearance of KVv2 secrets or metadata entries not correlated with authorized administrative activity; applications or services reporting missing secrets or authentication failures due to deleted credentials.
• Network: Repeated DELETE API calls to /v1/secret/data/ or /v1/secret/metadata/ endpoints from a single authenticated client in a short time window (HashiCorp Advisory).

HashiCorp has released patches addressing this vulnerability: Vault Community Edition 2.0.0 and Vault Enterprise 2.0.0, 1.21.5, 1.20.10, and 1.19.16 (HashiCorp Advisory). Organizations should prioritize upgrading to one of these patched versions as the primary remediation. As interim workarounds, administrators should review and restrict KVv2 path policies to eliminate unnecessary glob patterns, apply the principle of least privilege by removing delete permissions from non-administrative accounts, and monitor Vault audit logs for unexpected secret deletion activity. Temporarily restricting secret deletion permissions for non-administrative accounts until patches are deployed is also advisable.

HashiCorp published an official security advisory (HCSEC-2026-05) disclosing the vulnerability and providing patched versions on April 17, 2026 (HashiCorp Advisory). Red Hat tracked the issue via Bugzilla and assigned it high severity, indicating downstream impact on products shipping HashiCorp Vault (Red Hat Bugzilla). Community discussion and coverage appeared across vulnerability tracking platforms and security blogs shortly after disclosure, though no significant controversy or notable researcher commentary has been identified.