# HCSEC-2026-58 - Vault vulnerable to ACL deny bypass via case-variant auth method user and group names **URL:** \ **Category:** Security\ **Tags:** security-vault\ **Created:** [November 13, 2026, 8:08pm UTC](https://discuss.hashicorp.com/t/hcsec-2026-58-vault-vulnerable-to-acl-deny-bypass-via-case-variant-auth-method-user-and-group-names/78256 "2026-11-13T20:08:59Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![james.warren](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/james.warren/32/44042_2.png) [@james.warren](https://discuss.hashicorp.com/u/james.warren)\ **Post date:** [November 13, 2026, 8:08pm UTC](https://discuss.hashicorp.com/t/hcsec-2026-58-vault-vulnerable-to-acl-deny-bypass-via-case-variant-auth-method-user-and-group-names/78256/1 "2026-11-13T20:08:59Z")
**Bulletin ID:** HCSEC-2026-58 **Affected Products / Versions:** Vault and Vault Enterprise up to 2.2.1; fixed in Vault 2.2.2 and Vault Enterprise 2.2.2, 1.21.14, and 1.19.25. **Publication Date:** November 13, 2026 **Summary** Vault Community Edition and Vault Enterprise did not apply explicit ACL policy deny rules to letter case variants of user and group names in auth methods that treat these names as case-insensitive. This may allow an authenticated user with delegated permissions to modify a protected user or group, potentially leading to privilege escalation. This vulnerability (CVE-2026-128100) is fixed in Vault Community Edition 2.2.2 and Vault Enterprise 2.2.2, 1.21.14, and 1.19.25. **Background** Vault ACL policies grant or deny capabilities on API paths, and an explicit deny rule on a specific path is intended to take precedence over a broader rule that would otherwise allow access. Operators commonly combine these rules to delegate management of auth method users and groups while protecting specific higher-privilege entries. Some auth methods treat user and group names as case-insensitive, so names that differ only by letter case refer to the same user or group. **Details** Vault matched ACL rules against the request path as supplied, while the LDAP auth method and the RADIUS auth method when configured for case-insensitive names resolved names regardless of letter case. Vault Enterprise SCIM client updates also normalized client names to lowercase. A request that referred to a protected user, group, or SCIM client using different letter case could therefore fail to match an explicit deny rule, be authorized by a broader rule, and still act on the protected entry. This may allow a delegated user to change the policies associated with a protected user or group, which are then granted to anyone who logs in as that user or as a member of that group. This issue requires an authenticated user whose policies grant write access to the broader user, group, or SCIM client path, and a policy that relies on a more specific explicit deny rule to protect an individual entry. Deployments that do not combine these rules are not affected. LDAP user and group management paths are not affected when `case_sensitive_names` is enabled. RADIUS user management paths are not affected unless `case_insensitive_names` is enabled, which is disabled by default. **Remediation** Customers should evaluate the risk associated with this issue and consider upgrading to Vault Community Edition 2.2.2 or Vault Enterprise 2.2.2, 1.21.14, or 1.19.25. After upgrading, explicit deny rules in ACL policies also match case variants of request paths, subject to the usual rule specificity and the limitations below. This includes secrets engines and other components that treat names as case-sensitive, so operators should review deny rules that are intended to apply to only one letter case form of a path. This update applies to explicit deny rules in ACL policies; to protect individual users, groups, and SCIM clients that treat names as case-insensitive, operators should use explicit deny rules written without a trailing slash rather than narrower capability grants, parameter constraints, or Sentinel policies. Operators should consider tightly scoped policies that grant only the access required, rather than relying on broad allow rules with more specific deny rules to protect sensitive resources. Vault Enterprise delegation tokens are not covered by this fix; operators should avoid combining broad allow rules with more specific deny rules when using delegation tokens. **Acknowledgement** This issue was reported to HashiCorp by Chase Bevan-Thomas. _We deeply appreciate any effort to coordinate disclosure of security vulnerabilities. For information about security at HashiCorp and the reporting of security vulnerabilities, please see [https://hashicorp.com/security](https://hashicorp.com/security)._