Originally published at HOL
CVE-2026-12624: HashiCorp Vault LIST Authorization Bypass via Trailing Slash
TL;DR: CVE-2026-12624 lets a Vault token with a broad allow policy enumerate secrets beneath a path that a narrower deny policy was supposed to block. The ACL policy engine failed to enforce wildcard deny rules on LIST requests carrying a trailing slash. HashiCorp fixed the bug in Vault Community Edition 2.0.3 and Vault Enterprise 2.0.3, 1.21.8, 1.20.13, and 1.19.19.
What to do
The fix is straightforward. Upgrade your Vault deployment to one of the patched versions below.
Vault Community Edition: Update to 2.0.3 or later.
Vault Enterprise: Update to one of the following based on your minor track:
-
2.0.3 -
1.21.8 -
1.20.13 -
1.19.19
After upgrading, audit your existing ACL policies. The fix changes behavior: LIST requests with a trailing slash now correctly respect more-specific deny rules. Policies that relied on the old (broken) behavior may now deny requests they were supposed to allow. HashiCorp's changelog notes this explicitly. Run your policy test suite against the patched version in a staging environment before rolling to production.
If you cannot upgrade immediately, add an explicit deny rule without wildcards for the sensitive paths you need to protect. A non-wildcard deny on path "kv/private/" will block LIST requests regardless of the trailing-slash bug.
What happened
Vault's ACL system uses path-based policies with capabilities: read, write, list, deny. Administrators write policies that combine broad allow rules with narrow deny rules. A common pattern is allowing list on kv/* while denying access to kv/private/*. The deny rule is supposed to win over the allow.
It did not, if the request carried a trailing slash. Vault's request handling canonicalizes LIST operations by appending a trailing slash to the path before the ACL engine evaluates it. This canonicalization has worked correctly for years. The bug is in how the ACL engine matches the canonicalized path against wildcard deny policies. When a path like kv/private/ (with trailing slash) was matched against a deny rule on kv/private/*, the glob pattern failed to match. The deny rule was skipped. The broader allow rule on kv/* took effect instead.
The result: a token holding an allow on kv/* and a deny on kv/private/* could call vault list kv/private/ and receive the names of every secret stored under that path. It could not read the secret values, but key names alone can leak information. A key named kv/private/paypal-prod-api-key tells an attacker exactly what to target next.
NVD classifies this as CWE-863: Incorrect Authorization. No CVSS score has been assigned at publication time.
Who is affected
HashiCorp Vault is an enterprise secrets management tool used by thousands of organizations to store API keys, database credentials, TLS certificates, and encryption keys. Vault Enterprise customers include major financial institutions, healthcare providers, and cloud-native companies. HashiCorp reported $700M+ in annual revenue in fiscal 2026, and Vault is one of its flagship products.
The vulnerable versions are all Vault releases prior to 2.0.3 in the 2.x series, and Enterprise releases before the patch versions listed above. The bug affects both Vault Community Edition and Vault Enterprise.
Deployments using the KV Secrets Engine v1 or v2 with wildcard deny policies are at risk. If your policies do not use wildcard deny rules, or if you do not use LIST operations, the vulnerability does not apply to your configuration.
Why it matters
Secret enumeration is the first step in a multi-stage attack. An attacker who can list secret names but not read values still gains a blueprint of the organization's infrastructure. A key path like database/credentials/rds-prod-billing reveals the existence of a production billing database, the database engine vendor (RDS), and the credential type. This information shapes the attacker's next move: targeting the specific secret, pivoting to the database, or social-engineering someone with read access.
The vulnerability also highlights a subtle class of bug in policy engines: canonicalization mismatches. The request layer normalizes the path (adds trailing slash) and passes it to the policy layer. The policy layer matches against patterns that assume unnormalized input. This category of bug appears repeatedly in authorization systems, from cloud IAM to Kubernetes RBAC.
