Second critical RCE in HashiCorp Vault unpatched while OpenBao ships fixes

What was reported

A report published on dev.to describes a second remote code execution vulnerability in HashiCorp Vault's codebase, one that also affects the OpenBao fork and, under specific conditions, allows a complete server compromise. According to the article, engineers at security firm ControlPlane demonstrated the exploit by chaining four distinct flaws, combining an unauthenticated entry path with a misconfigured Raft snapshot policy to run arbitrary code with root privileges.

The situation the report highlights is asymmetric. OpenBao has already shipped fixes in versions 2.6.3 and 2.7.0, while HashiCorp Vault, in the article's telling, remains unpatched. The stated reason is procedural rather than technical: no coordinated disclosure has taken place between the two projects, which leaves Vault operators without a vendor-sanctioned fix.

How the attack chain is said to work

According to the dev.to write-up, the exploit proceeds in four stages. First, the attacker reaches an API endpoint that requires no authentication, where weak input sanitisation and validation allow a malicious payload to be injected and executed within the application context. Second, from that foothold, the attacker abuses the Raft snapshot mechanism — a feature meant to keep distributed data consistent — by feeding commands into the snapshot process; the report says command validation is missing there, so the injected code runs with root privileges.

Third, with root access the attacker can rewrite system configuration, switch off security controls or plant backdoors, which the article argues neutralises conventional defences such as firewalls and intrusion detection. Fourth, the server is fully compromised: secrets can be exfiltrated, system behaviour altered, or the machine used as a pivot into the wider network.

The article also contends the chain is practical rather than theoretical, claiming that many deployments leave unauthenticated endpoints reachable for operational convenience, and that Raft snapshot policies are frequently switched on by default or set up incorrectly, giving attackers a predictable pathway.

OpenBao patched, Vault has not

Per the report, the OpenBao fixes do two things: check input at the entry point that previously demanded no authentication, and tighten the Raft snapshot mechanism so snapshots can no longer serve as a route to running commands. Both changes are available in OpenBao 2.6.3 and 2.7.0.

HashiCorp Vault is another matter. The article says the product has not received a fix because no coordinated disclosure has occurred between HashiCorp and IBM, which the report names as OpenBao's maintainer, and it does not point to any HashiCorp security advisory. As a result, Vault deployments are described as exposed to the same exploit chain with no official mitigation. It is worth noting that these claims come from a single published report and are not corroborated by a second source in the material available.

Interim steps for Vault operators

Until a patch exists, the article recommends three defensive measures: turn off or lock down unauthenticated endpoints so the initial entry point disappears; review Raft snapshot settings and lock them down so the mechanism cannot be co-opted to run commands; and watch closely for unusual activity, such as commands running unexpectedly or critical binaries and configuration files changing. The author is explicit that these steps reduce exposure but do not fix the underlying flaw, and urges users to press both vendors to coordinate disclosure and ship an official remedy.

Why it matters

Vault servers hold the credentials, certificates and encryption keys that the rest of an infrastructure depends on, so root-level code execution on one is close to a worst-case outcome — an attacker who reaches that point can walk away with the secrets guarding everything downstream. The episode also illustrates a structural risk created when forks share a codebase: once one fork publishes a patch, the diff itself can act as a map to the unfixed flaw in the other product, which makes the gap between OpenBao's releases and a Vault fix more dangerous than a simple delay. Above all, it is a concrete argument for coordinated disclosure across vendors — without a shared process, the patch that protects one user base can leave another exposed, with nothing official to guide operators caught in between.