CVE-2026-93335 in Vault
Summary
by MITRE • 11/13/2026
Vault Community Edition and Vault Enterprise did not consistently apply explicit ACL policy deny rules to request paths that differ only by a trailing slash. This may allow an authenticated user who holds a broader delete permission on system configuration paths to disable a secrets engine, auth method, or audit device that a more specific deny rule was intended to protect. This vulnerability (CVE-2026-93335) is fixed in Vault Community Edition 2.2.2 and Vault Enterprise 2.2.2, 1.21.14, and 1.19.25.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/13/2026
The vulnerability identified as CVE-2026-93335 represents a critical access control flaw within HashiCorp Vault, affecting both the Community Edition and Enterprise versions prior to their respective patched releases. This issue stems from an inconsistency in how the system processes Access Control List (ACL) policies when evaluating request paths that differ solely by the presence or absence of a trailing slash. In many web-based systems and API gateways, path normalization is expected to treat /path/ and /path as equivalent entities for security policy enforcement. However, Vault's internal logic failed to consistently apply explicit deny rules in this specific scenario, creating a discrepancy between the intended security posture defined by administrators and the actual runtime behavior of the system. This inconsistency allows an authenticated user with broader delete permissions on general configuration paths to bypass more granular restrictions designed to protect sensitive infrastructure components such as secrets engines, authentication methods, or audit devices.
From a technical perspective, this flaw is classified under CWE-284, which describes Improper Access Control, specifically relating to the failure to enforce restrictive access control rules due to inconsistent path handling. The vulnerability exploits the lack of canonicalization in ACL evaluation logic. When an administrator configures policies using HCL syntax, they may explicitly deny delete operations on specific paths like /sys/auth/my-auth-method/ or /secret/data/sensitive/. If a user attempts to perform a DELETE request against these resources but includes a trailing slash where none was specified in the deny rule, or vice versa depending on how the internal routing maps the request, the system might fail to match the explicit deny policy. Instead of blocking the action based on the specific restriction, the evaluation logic may fall back to broader allow rules that grant delete access to parent directories or wildcard paths. This bypass mechanism effectively neutralizes the intent of fine-grained security policies, allowing users with elevated privileges to perform destructive actions they should not be authorized to execute.
The operational impact of this vulnerability is severe for organizations relying on Vault for centralized secrets management and identity governance. An attacker who has obtained credentials for an account with broad delete permissions could disable critical authentication methods, effectively locking out other legitimate users or disrupting the authentication flow entirely. Similarly, disabling a specific secrets engine can lead to service failures in applications that depend on dynamic credential generation or secret retrieval from that backend. Furthermore, tampering with audit device configurations could compromise the integrity of security logging and monitoring capabilities, hindering incident response efforts. Since this affects both Community and Enterprise editions, organizations running older versions are exposed regardless of their support tier, making immediate remediation a priority for maintaining operational continuity and compliance with internal security policies.
This vulnerability aligns with several techniques in the MITRE ATT&CK framework, particularly T1078 Valid Accounts, as it requires initial authentication, and T1499 Endpoint Denial of Service if used to disrupt services by disabling auth methods or secrets engines. It also relates to T1530 Data from Cloud Storage Object Exfiltration indirectly, as compromising the integrity of vaulted data can lead to broader security breaches. The core issue is a logic error in access control enforcement rather than a memory corruption or injection flaw, highlighting the importance of rigorous testing for edge cases in path-based authorization systems.
To mitigate this risk, organizations must upgrade their Vault installations immediately to version 2.2.2 for Community Edition and versions 1.21.14 or 1.19.25 for Enterprise Edition. These releases contain the necessary patches to ensure that ACL policies are applied consistently regardless of trailing slash variations in request paths. In addition to upgrading, administrators should review their existing policy configurations to identify any reliance on implicit permissions that might have been masking this vulnerability. It is recommended to adopt a principle of least privilege by ensuring that delete operations require explicit allow rules rather than relying on the absence of deny rules. Regular audits of ACL policies and testing them against various path formats can help prevent similar access control bypasses in the future, ensuring that security boundaries remain robust even when request parameters vary slightly from their canonical forms.