CVE-2026-12624: HashiCorp Vault ACL policy engine authorization bypass in LIST requests

CVE-2026-12624 · Severity: medium · CVSS 4.3 · Published 2026-08-10

Vault is a widely-used secrets management platform that enforces access control through ACL policies. An attacker with an authenticated token and specific policy permissions could bypass wildcard deny rules by making LIST requests with a trailing slash, allowing unauthorized enumeration of secret path names. While this does not expose secret values themselves, it reveals the structure and names of protected secrets, which can aid in further attacks.

Technologies: HashiCorp Vault, HashiCorp Vault Enterprise. Vendors: HashiCorp.

Quick answers

Is CVE-2026-12624 exploited in the wild?
No. Junglewise Threat Intelligence has no report of CVE-2026-12624 being exploited in the wild.
How severe is CVE-2026-12624?
Medium severity, with a CVSS score of 4.3, published 10 August 2026.
Which products and versions are affected?
HashiCorp Vault up to 2.0.2; HashiCorp Vault Enterprise up to 2.0.2; 1.21.x before 1.21.8; 1.20.x before 1.20.13; 1.19.x before 1.19.19.
Is there a fix for CVE-2026-12624?
A patch was published on 2026-08-10: Fixed in Vault 2.0.3, Vault Enterprise 2.0.3, 1.21.8, 1.20.13, and 1.19.19 Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
How is CVE-2026-12624 attacked?
It is attacked over the network, in a hosted service.
Am I affected by CVE-2026-12624?
Check whether you run HashiCorp Vault or HashiCorp Vault Enterprise at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

Technical details

The vulnerability is an authorization bypass in Vault's ACL policy engine affecting LIST requests. When a LIST request is made against a denied path with a trailing slash, the policy engine normalizes the request path before performing a prefix lookup, causing it to incorrectly match a broader allow rule instead of the intended more-specific wildcard deny rule. This affects only authenticated tokens that already possess both a broad allow capability on a parent path and a narrower wildcard deny rule—tokens without this specific policy combination are unaffected. The issue is limited to disclosure of entry names via LIST operations; secret values remain protected and no capabilities beyond listing are granted. Fixes are available in Vault 2.0.3, Vault Enterprise 2.0.3, 1.21.8, 1.20.13, and 1.19.19.

Affected products

  • HashiCorp Vault up to 2.0.2
  • HashiCorp Vault Enterprise up to 2.0.2; 1.21.x before 1.21.8; 1.20.x before 1.20.13; 1.19.x before 1.19.19

Timeline

  • 2026-08-10: disclosed: Vulnerability publicly disclosed via HashiCorp security advisory HCSEC-2026-26
  • 2026-08-10: patched: Fixed in Vault 2.0.3, Vault Enterprise 2.0.3, 1.21.8, 1.20.13, and 1.19.19

References

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.