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

CVE-2026-12624 is an incorrect authorization vulnerability in HashiCorp Vault's ACL policy engine that allows authenticated users to bypass wildcard (glob) deny rules on LIST requests. Specifically, the engine failed to consistently enforce deny rules when LIST requests were made with a trailing slash on the denied path, enabling a token with a broader allow rule and a narrower wildcard deny rule to enumerate entry names beneath a path it should have been denied access to. It was published on August 10, 2026, and affects Vault Community Edition versions before 2.0.3 and Vault Enterprise versions before 2.0.3, 1.21.8, 1.20.13, and 1.19.19. The CVSS v3.1 base score is 4.3 (Medium) (HashiCorp Advisory).

The root cause is classified as CWE-863 (Incorrect Authorization). The Vault ACL policy engine did not normalize or consistently handle trailing slashes in path comparisons when evaluating glob-based deny rules against LIST requests. An attacker with a valid token that holds a broader allow policy alongside a narrower wildcard deny policy can craft a LIST request appending a trailing slash to the denied path, causing the deny rule to be skipped and the listing operation to succeed. This is a network-accessible, low-complexity attack requiring low privileges and no user interaction (HashiCorp Advisory).

Successful exploitation allows an authenticated attacker to enumerate the names of secrets or entries beneath a Vault path that was intended to be access-restricted via a deny rule. The impact is limited to confidentiality — specifically, unauthorized disclosure of path/key names — with no integrity or availability impact. While this does not directly expose secret values, knowledge of secret names can facilitate further targeted attacks or reconnaissance within the Vault environment (HashiCorp Advisory).

There is no evidence of in-the-wild exploitation or public proof-of-concept code as of the time of disclosure. The NVD SSVC assessment indicates exploitation is "none" and the attack is not automatable. The EPSS score is approximately 0.197%, reflecting a low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog (HashiCorp Advisory).

1. Identify target: Confirm the Vault instance is running a vulnerable version (Community Edition < 2.0.3 or Enterprise < 1.19.19 / 1.20.13 / 1.21.8 / 2.0.3).
2. Obtain a token: Acquire a Vault token that has a policy granting broad LIST/read access to a parent path but includes a narrower wildcard (glob) deny rule on a sub-path (e.g., deny on secret/sensitive/*).
3. Craft trailing-slash LIST request: Issue a LIST request to the denied path with a trailing slash appended (e.g., vault list secret/sensitive/ or via the API: GET /v1/secret/sensitive/?list=true), which causes the ACL engine to skip the glob deny rule evaluation.
4. Enumerate entries: Review the response, which will return the names of keys or sub-paths beneath the denied path that should have been inaccessible.
5. Use enumerated data: Leverage the discovered key names for targeted secret retrieval attempts or further reconnaissance within the Vault namespace (HashiCorp Advisory).

• Logs: Vault audit logs showing LIST requests to paths that include a trailing slash (e.g., secret/sensitive/) from tokens that should be denied access to those paths; repeated LIST operations against paths covered by deny rules.
• Network: Unusual or repeated API calls to Vault endpoints using the ?list=true query parameter or HTTP LIST method targeting sensitive sub-paths with trailing slashes.
• Behavioral: A token performing LIST operations on paths it has no legitimate business need to enumerate, particularly paths explicitly covered by deny rules in its associated policy.

HashiCorp has released patched versions addressing this vulnerability: Vault Community Edition 2.0.3, and Vault Enterprise 2.0.3, 1.21.8, 1.20.13, and 1.19.19. Organizations should upgrade to one of these versions as the primary remediation. As a temporary workaround, administrators can review and tighten ACL policies to avoid configurations that combine broad allow rules with narrower glob deny rules on the same path hierarchy, or restrict LIST capabilities on sensitive paths entirely until patching is complete (HashiCorp Advisory).