CVE-2026-3605: HashiCorp Vault DOS Vulnerability

CVE-2026-3605 Overview

CVE-2026-3605 is an authorization bypass vulnerability affecting HashiCorp Vault's KVv2 (Key-Value version 2) secrets engine. 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, resulting in a denial-of-service condition. Importantly, this vulnerability does not allow attackers to delete secrets across namespaces or read any secret data.

Critical Impact

Authenticated attackers can cause denial-of-service by deleting secrets beyond their authorized scope within a namespace, potentially disrupting critical applications and services that depend on Vault-managed secrets.

Affected Products

• HashiCorp Vault Community Edition versions prior to 2.0.0
• HashiCorp Vault Enterprise versions prior to 2.0.0, 1.21.5, 1.20.10, and 1.19.16

Discovery Timeline

• 2026-04-17 - CVE CVE-2026-3605 published to NVD
• 2026-04-17 - Last updated in NVD database

Technical Details for CVE-2026-3605

Vulnerability Analysis

This vulnerability stems from improper authorization enforcement when processing glob patterns in Vault policies for KVv2 secrets engine paths. The KVv2 secrets engine provides versioning capabilities for secrets, storing both the secret data and associated metadata. When policies are configured using glob patterns (wildcards like *) to define access paths, the authorization logic fails to properly restrict delete operations to only the specific secrets the user is authorized to access.

The flaw is classified under CWE-288 (Authentication Bypass Using an Alternate Path or Channel), indicating that the standard authorization checks can be circumvented through the glob pattern matching mechanism. While the vulnerability's impact is constrained to the current namespace (cross-namespace deletion is not possible) and no secret data can be read, the ability to delete secrets can severely impact system availability and operational continuity.

Root Cause

The root cause lies in the policy evaluation logic for KVv2 delete operations. When a policy contains glob patterns to grant access to a subset of secrets, the authorization check for delete operations does not properly validate that the user's policy explicitly grants write or delete permissions on the targeted secret path. Instead, the presence of any glob-based access to the parent path is incorrectly interpreted as sufficient authorization for deletion operations.

Attack Vector

The attack is network-accessible and requires low-privilege authenticated access. An attacker must have:

1. Valid authentication credentials to the Vault instance
2. A policy assigned that includes glob patterns for KVv2 paths
3. Network access to the Vault API endpoint

The attacker can then enumerate or guess secret paths within their namespace and issue delete requests against secrets they should not have delete permissions for. The attack does not require user interaction and can be automated to delete multiple secrets in rapid succession, maximizing the denial-of-service impact.

The vulnerability mechanism involves exploiting the glob pattern matching in Vault policies. When a policy grants access using wildcards (e.g., secret/data/myapp/*), the authorization system improperly evaluates delete requests against paths that match the glob pattern even when the specific delete capability was not granted. For detailed technical information, refer to the HashiCorp Security Advisory HCSEC-2026-05.

Detection Methods for CVE-2026-3605

Indicators of Compromise

• Unexpected deletion of secrets in KVv2 mounts by users with limited read-only or path-specific policies
• Audit log entries showing delete operations from users whose policies only contain glob-pattern read access
• Application failures due to missing secrets that were previously available
• Unusual patterns of metadata delete requests against KVv2 paths

Detection Strategies

• Enable and monitor Vault audit logs for all delete operations on KVv2 paths
• Implement alerting for delete operations performed by service accounts or users with policies containing glob patterns
• Cross-reference delete operations against expected access patterns defined in policies
• Deploy SentinelOne Singularity Platform to detect anomalous API activity patterns targeting Vault endpoints

Monitoring Recommendations

• Configure Vault audit device to log all requests and responses for forensic analysis
• Establish baseline metrics for secret deletion rates and alert on deviations
• Monitor for rapid successive delete requests that may indicate automated exploitation
• Implement real-time alerting integration between Vault audit logs and SIEM platforms

How to Mitigate CVE-2026-3605

Immediate Actions Required

• Upgrade HashiCorp Vault Community Edition to version 2.0.0 or later
• Upgrade HashiCorp Vault Enterprise to version 2.0.0, 1.21.5, 1.20.10, or 1.19.16 depending on your release branch
• Audit existing policies containing glob patterns in KVv2 paths and restrict delete capabilities explicitly
• Review audit logs for any unauthorized delete activity that may have occurred prior to patching

Patch Information

HashiCorp has released fixed versions that properly enforce authorization checks for delete operations on KVv2 paths with glob-based policies. The fix ensures that delete operations require explicit delete or write capabilities on the specific path, rather than inheriting permissions from glob pattern matches. For complete details, see the HashiCorp Security Advisory HCSEC-2026-05.

Workarounds

• Remove glob patterns from policies where possible and use explicit path definitions
• Implement Sentinel policies (Enterprise feature) to add additional authorization checks for delete operations
• Temporarily revoke delete capabilities from policies containing glob patterns until patching is complete
• Consider implementing namespace isolation to limit the blast radius of potential exploitation

# Configuration example
# Review and audit policies with glob patterns for KVv2 paths
vault policy list | while read policy; do
  vault policy read "$policy" | grep -E 'secret/data/.*\*' && echo "Policy: $policy contains glob patterns"
done

# Example: Replace glob pattern with explicit paths
# Before (vulnerable):
# path "secret/data/myapp/*" {
#   capabilities = ["read", "list"]
# }

# After (mitigated - explicit delete denial):
# path "secret/data/myapp/*" {
#   capabilities = ["read", "list"]
#   denied_parameters = {
#     "delete" = []
#   }
# }