HashiCorp Vault CVE-2026-5006

Exploitation requires the Vault deployment to have at least one ACL policy configured with a templated path variable that references a user-controllable identity attribute - such as an entity name, entity alias, or metadata field populated by an external auth method (e.g., LDAP, GitHub, AWS IAM). The attacker must hold valid, authenticated Vault credentials with at least low-privilege access (PR:L per CVSS vector). The vulnerability is entirely unexploitable in deployments that do not use templated ACL policy paths, or where all identity values referenced in templates are set exclusively by Vault operators and cannot be influenced by the authenticating user. The requirement for this specific non-default configuration (AC:H) is the primary factor limiting realistic attack surface; organizations using Vault purely with static ACL policies are not affected regardless of version.

The CVSS 3.1 score of 6.8 (Medium) accurately reflects the real-world constraint encoded in AC:H: exploitation requires a Vault deployment that has deliberately configured templated ACL policy paths AND references an identity attribute that an authenticated user can influence - a non-default, operator-constructed scenario rather than a universally present attack surface. CISA has not listed this in KEV at time of analysis, and no proof-of-concept code appears in the provided intelligence, consistent with a targeted rather than mass-exploitation risk profile. EPSS data is absent from the available intelligence and cannot be assessed. The C:H/I:H impact metrics are serious: secrets management systems are inherently high-value targets, and successful exploitation would fully compromise the confidentiality and integrity of reachable Vault paths - an outcome relevant to supply-chain and lateral-movement scenarios. Environments using identity-based multi-tenancy segmentation in Vault should treat this as an urgent patch priority despite the moderate overall score, because the templating feature that introduces the vulnerability is precisely the one relied upon for tenant isolation. The S:U scope and A:N metrics indicate no privilege escalation beyond the Vault instance itself and no service disruption, which limits but does not eliminate the blast radius.

An authenticated Vault user with limited access - for example, scoped to secret/data/tenants/alice/ via a templated policy - manipulates their entity name or a user-settable metadata field to include slash characters, such as alice/../admin. When Vault renders the templated policy path using this value, it evaluates secret/data/tenants/admin/ as the effective path, granting the attacker read and write access to another tenant's secrets outside their authorization boundary. No public proof-of-concept code exists at time of analysis, but the attack concept is straightforward for any user who understands Vault's policy templating syntax.