Bulletin ID: HCSEC-2026-43
Affected Products / Versions: Vault Community Edition up to 2.1.1; fixed in Vault Community Edition 2.1.2. Vault Enterprise up to 2.1.1; fixed in Vault Enterprise 2.1.2, 1.21.12, 1.20.17, and 1.19.23.
Publication Date: October 7, 2026
Summary
Vault and Vault Enterprise did not consistently evaluate ACL policies against the canonical form of resource and policy names. This may allow an authenticated user with delegated permissions to bypass an explicit deny restriction and access a protected resource or assign a denied policy, potentially leading to privilege escalation. This vulnerability (CVE-2026-89322) is fixed in Vault Community Edition 2.1.2, and Vault Enterprise 2.1.2, 1.21.12, 1.20.17, and 1.19.23.
Background
Vault ACL policies grant or deny capabilities on request paths, where a more specific rule takes precedence over a broader wildcard rule, and can use denied_parameters to prevent a principal from setting specific values in a request. Operators commonly combine these controls to delegate management of auth method roles, users, tokens, and identities while protecting specific resources and higher-privilege policies. Many Vault components, including several auth methods, ACL policies, and identity entities and groups, treat resource and policy names as case-insensitive.
Details
Vault evaluated ACL policies against resource and policy names as supplied in a request, while the receiving component later normalized those names into their canonical form, for example by disregarding letter case or surrounding whitespace. A request that referred to a protected resource or policy using a non-canonical name could therefore avoid a restriction during policy evaluation and still be applied to the protected resource or denied policy. This may allow a delegated user to access or modify a resource protected by a more specific rule, such as obtaining credentials for an explicitly denied auth method role, or to assign an explicitly denied policy to a token, role, user, or identity. In Vault Enterprise, Sentinel policies evaluated against the request path were similarly affected. Exploitation requires an authenticated principal holding broad delegated permissions on an affected endpoint, and a policy that relies either on a more specific rule to deny or limit access alongside a broader allow rule, or on value-specific denied_parameters to restrict assignable policy names. Assigning a denied policy also requires that the policy already exists and that the principal can obtain a token carrying it. Root and internal policies cannot be assigned through this issue, and token creation without sudo remains limited to the caller’s own policies. Deployments that do not combine broad allow rules with more specific restrictions on these resources, do not use non-canonical casing in policy names, and do not use denied_parameters to restrict policy names, are not affected.
Remediation
Customers should evaluate the risk associated with this issue and consider upgrading to Vault Community Edition 2.1.2, or Vault Enterprise 2.1.2, 1.21.12, 1.20.17, or 1.19.23. After upgrading, ACL policy rules and Vault Enterprise Sentinel policies for affected resources are evaluated against the lowercase resource name, so existing rules that reference mixed-case resource names, including deny rules, will no longer match and should be rewritten in lowercase before upgrading. The Okta, LDAP, and RADIUS auth methods, and Vault Enterprise SCIM clients, are not covered by this fix; operators should avoid combining broad allow rules with more specific deny rules on those resources.
Acknowledgement
This issue was reported to HashiCorp by Han Sang-Kyung (HAN-BAMBO) and by additional internal and external parties.