CVE-2026-105816 in Vault
Summary
by MITRE • 10/08/2026
Vault and Vault Enterprise did not consistently verify that stored plugin catalog entries reference binaries within the configured plugin directory. When Vault uses Shamir seals and has an external plugin directory configured, a privileged operator able to restore an Integrated Storage (Raft) snapshot may be able to execute arbitrary code on the Vault host. This vulnerability (CVE-2026-105816) is fixed in Vault Community Edition 2.1.2, and Vault Enterprise 2.1.2, 1.21.12, 1.20.17, and 1.19.23.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/08/2026
The vulnerability identified as CVE-2026-105816 represents a critical security flaw within HashiCorp Vault and Vault Enterprise architectures that undermines the integrity of plugin execution through insufficient path validation during snapshot restoration operations. This issue specifically affects environments utilizing Shamir seal configurations combined with an external plugin directory setting, creating a scenario where the boundary between trusted administrative actions and untrusted data input becomes blurred. The core technical flaw lies in the application's failure to consistently verify that entries within the stored plugin catalog correspond strictly to binaries located within the designated safe plugin directory path. In standard secure implementations, any reference to an executable or library must be validated against a whitelist of allowed directories to prevent attackers from redirecting execution flow to maliciously placed files elsewhere on the filesystem.
When an operator with privileged access restores an Integrated Storage Raft snapshot, they are essentially importing a serialized state that includes metadata about installed plugins and their locations. Because Vault did not rigorously validate these stored paths against the configured plugin directory constraint, it allowed for path traversal or arbitrary file reference injection through crafted snapshot data. This lack of validation means that if an attacker can influence the contents of a Raft snapshot—either by compromising a backup source, manipulating a trusted operator's workflow, or exploiting another vector to inject malicious metadata—they can cause Vault to load and execute plugins from unintended locations on the host system rather than the secure plugin directory.
The operational impact of this vulnerability is severe due to its potential for arbitrary code execution with the privileges of the Vault process. Since Vault typically runs as a service account that may have elevated permissions necessary to manage secrets, keys, and certificates, successful exploitation allows an attacker to gain full control over the host machine hosting the Vault instance. This compromises not only the confidentiality and integrity of all stored secrets but also provides a foothold for lateral movement within the infrastructure. The requirement for a privileged operator to restore a snapshot does not mitigate the risk significantly in environments where backup management is automated or shared among multiple administrators, as it expands the attack surface beyond direct application exploitation to include operational procedures like disaster recovery and migration tasks.
This vulnerability aligns with CWE-22 Improper Limitation of a Pathname to a Restricted Directory, which describes flaws where software does not properly neutralize path sequences such as dot-dot-slash or uses insufficient validation when resolving file paths. Furthermore, it relates to CWE-94 Improper Control of Generation of Code Command Injection in the context that malicious plugin binaries are executed by the application logic during startup after snapshot restoration. From an ATT&CK perspective, this flaw facilitates Initial Access via Compromise Infrastructure and Execution through Dynamic Linker/Loader exploitation, allowing adversaries to establish persistence or escalate privileges within a containerized or bare-metal environment hosting critical identity management services.
Mitigation strategies must prioritize immediate patching as the primary defense vector. Organizations running affected versions of Vault Community Edition prior to 2.1.2 or Vault Enterprise prior to version 2.1.2, 1.21.12, 1.20.17, and 1.19.23 should upgrade immediately upon availability. For environments where immediate patching is not feasible due to operational constraints, strict access controls on snapshot files are essential. Administrators must ensure that Raft snapshots are stored in highly restricted locations with integrity checks such as cryptographic signing or hashing to prevent tampering before restoration. Additionally, enforcing the use of sealed configurations other than Shamir seals may reduce exposure if alternative seal mechanisms provide different validation paths, though upgrading remains the only definitive fix for this specific code-level deficiency. Regular auditing of plugin directories and monitoring for unexpected binary executions can also aid in detecting potential exploitation attempts while mitigation measures are implemented.