11/05/2026
Cybersecurity Insights
Publication of a security audit report performed on HashiCorp Vault
During the last months of 2025, our internal Security Evaluation Laboratory had the chance to conduct a security audit of HashiCorp Vault. This audit aim was to assess the security level of Vault, focusing on code source analysis and dynamic penetration testing (configuration handling, authentication and ACL, secure storage of secrets, API robustness).
This security audit was funded by the French cybersecurity agency (ANSSI) as part of its efforts to support the security assessment of open source software (more info here).
The audit showed that Vault is designed to be simple to install and already secured with its default configuration. Its design and user-side tools are also neat and intuitive, improving its security and the security of the secrets carried by the system. Following this simplicity scheme, Vault has a very limited attack surface, mainly restricted to its REST API.
The static and dynamic analysis focused on this API robustness and authentication mechanisms. The security of the tokens used to carry this authentication and protect the exchanged data was audited at different levels (generation, storage, usage by the users, protection carried by them, etc.). The use of policies to carry the protection of secrets was also evaluated, without raising any major defect.
Analysis of the network communications protection and logging mechanisms showed some minor possible improvements, without any major threat to the security of the system.
The same way, a thorough cryptographic analysis of the cryptography used by Vault was performed, with similar results.
At the end of this audit, and on top of the 12 minor findings shared with ANSSI and HashiCorp, one CVE detailed below was issued and fixed.
ALMOND, ANSSI and HashiCorp decided to share a public version of the audit report to improve the security and transparency of this process, following a responsible disclosure process to HashiCorp.
If you want to find out more about the security audit or evaluation capabilities of our SEAL, feel free to reach us.
If you would like more information about ANSSI’s efforts to support open‑source security, please send an email to opensource@ssi.gouv.fr.
Responsible disclosure timeline
- 2025/10/14: Audit kickoff
- 2026/01/26: Audit final meeting
- 2026/02/20: Final audit report sent to ANSSI
- 2026/02/23: Public version of the audit shared to ANSSI
- 2026/03/11: Public report shared to RedHat and IBM by ANSSI
- 2026/03/31: HashiCorp replied with comments on all vulnerability, findings and recommendations
- 2026/04/14: Release of a new version fixing the vulnerability
- 2026/04/16: Publication of the vulnerability advisory by HashiCorp
- 2026/05/11: Publication of the joint ALMOND & ANSSI blog posts and audit report
CVE-2026-3605: Vault KVv2 Metadata and Secret Deletion Policy Bypass Denial-of-Service
This vulnerability, rated 8.1 (CVSS 3.1) was reported to HashiCorp, that patched it and issued a CVE. It was also independently reported by chungkn from OneMount Group.
A test aimed to perform a path traversal by encoding the special characters ../ in URL encoding. Two users were set up: user1 and user2, each with their own policy to set secrets on the path /data/user1/* and /data/user2/* respectively with a kv-v2 engine.
The auditor tried to reach a secret mysecret stored in non-authorized path /data/user1/ via an authorized path /data/user2/../user1/mysecret using user2. The TOE returned 500 Internal Server Error, but no 403 Forbidden. This suggests the request was authorized by the server. The logs revealed that the path targeted is indeed secret/data/user2/../user1/mysecret. The authorization comes from the fact that the token is authorized to all sub repositories with prefix /data/user2/*.
Moreover, if the last version of the secret is soft-deleted, the evaluator can reach the metadata of it using this process:
However, user2 is not supposed to access metadata (“deny” capability on secret/metadata/user1/* path).
The evaluator tried the same test, but with the DELETE method. The unauthorized data is indeed soft deleted.
A similar test was to use the PUT method to overwrite unauthorized secrets. This is a success:
The legitimate user cannot access this data anymore and got the same error as the one depicted previously. But the attacker can reach the data he wrote when reaching the endpoint secret/data/user2/%2E%2E%2F/user1/newsecret:
Using this method, the evaluator tried to reach the endpoint secret/metadata/user2/%2E%2E%2F/user1?list=true with GET method using user2 token to list the names of the secrets of the sub repository user1, which user2 cannot access due to its policy. However, the TOE lists the secrets presents in sub repository user1, even though user2 is not authorized to access this information. Thus, an attacker can list secrets of other users.
The evaluator performed a similar test, but using kv1 secret engine which does not use versions. He tried to reach the secret kv1/user2/vuln through the authorized path kv1/user1/* with relative path kv1/user1/%2E%2E%2F/user2/vuln. An error code 400 is returned:
Code: 400. Errors:
* 1 error occurred:
* read failed: relative paths not supported
In this case, Vault handles the malformed path.
