CVE-2026-3605

What it actually does

An authenticated user with access to a kvv2 path via a glob-containing policy can bypass authorization to delete secrets outside their read/write scope, causing denial-of-service without enabling cross-namespace deletion or secret data reads.

Why it matters to the business

Organizations relying on HashiCorp Vault risk operational disruptions from unauthorized secret deletions that impair dependent applications and services; the rising EPSS trend signals growing attacker interest, increasing urgency for remediation across widespread deployments.

How an attack unfolds

An attacker authenticates to Vault, locates a kvv2 path covered by a glob policy, and issues delete requests for secrets they lack authorization to access, resulting in targeted availability loss.

How to fix it

Upgrade HashiCorp Vault Community Edition to 2.0.0 or Vault Enterprise to 2.0.0, 1.21.5, 1.20.10, or 1.19.16; audit and refine policies to minimize reliance on broad globs.

How to confirm the fix worked

Confirm running versions match the listed fixed releases; retest glob policies to ensure delete operations now enforce original authorization boundaries.

Typical attack path

1. Obtain authenticated Vault access with a glob-based kvv2 policy
2. Map target kvv2 paths to identify deletion candidates
3. Issue crafted delete API calls against unauthorized secrets
4. Confirm successful deletions leading to denial-of-service

How to detect it

Examine Vault audit logs for successful delete operations on kvv2 paths where the user policy would normally restrict access; correlate with authentication events and policy evaluations to identify unauthorized deletions.

What your security team should do

• Prioritize upgrades to the specified fixed versions on all affected Vault deployments
• Review and tighten kvv2 policies containing globs
• Enable enhanced audit logging for secret delete events
• Establish monitoring for anomalous delete activity on protected paths