CVE-2026-93335 · Infrastructure
NO FIX YET · SEE WHAT TO DO
Vault did not apply explicit ACL deny rules to request paths that differ only by a trailing slash. An authenticated user with broad delete permission on system configuration paths could disable a secrets engine, auth method, or audit device that a deny rule was meant to protect.
first public Nov 12, 2026 · 1 source
Check it with your coding agent
It reads this page and tells you if your code or app is affected.
Teams running HashiCorp Vault Community Edition or Enterprise that rely on explicit ACL deny rules to protect system configuration paths. The attacker must already hold an authenticated token with a broader delete permission. Teams that do not use explicit deny rules on these paths are less exposed.
Not affected if no-explicit-acl-deny-rules, unauthenticated-only
Who cares kubernetes, self-hosted, vault
vault versionsys/mounts, sys/auth, or sys/audit paths and for broad delete grants2.2.22.2.2, 1.21.14, 1.19.25Vault 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.
This page as .md · .json · CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
InfraStack checks it against your stack and answers on your report, with the evidence and the fix.