Unauthenticated RCE chain threatens HashiCorp Vault deployments as OpenBao ships patches

Unauthenticated RCE chain disclosed in Vault and OpenBao

A report published on dev.to describes a critical remote code execution chain affecting both HashiCorp Vault and its open-source fork OpenBao. According to the write-up, the chain combines four separate vulnerabilities in the shared codebase and allows an attacker with no credentials to take complete control of a server. The report frames the scenario as realistic rather than theoretical: the only preconditions it identifies are unauthenticated access to the service and a defined Raft snapshot policy on the target deployment.

How the chain is described as working

Per the dev.to account, the exploit unfolds in two stages. Unauthenticated access first bypasses the service's front-line authentication gate. The attacker then leverages the Raft snapshot policy, a legitimate operational setting used to manage storage snapshots, as a trigger for the remaining flaws. Chained together, the four weaknesses cascade past security controls until arbitrary code executes on the server, at which point the attacker can exfiltrate secrets, alter configuration, or install additional tooling. Because authentication is never required, the report argues, the bar for exploitation is low enough that any instance meeting the two preconditions should be treated as at risk.

The report does not include CVE identifiers, proof-of-concept code, or a per-flaw technical breakdown, so its severity assessment rests on a single account. Operators should watch official vendor channels for confirmation and advisories as the story develops.

OpenBao is patched; Vault is not

The two projects have diverged sharply in their response. OpenBao shipped fixes in versions 2.6.3 and 2.7.0, which the report says address the underlying weaknesses and make the RCE path unreachable. HashiCorp Vault, meanwhile, remains exposed. The dev.to post attributes the gap to a failure of coordinated disclosure between IBM, HashiCorp's parent company since its acquisition closed in early 2025, and HashiCorp itself, leaving Vault operators without an official patch or vendor-endorsed fix.

Mitigation steps for operators

For teams running OpenBao, the report's guidance is direct: upgrade immediately to 2.6.3 or 2.7.0.

For HashiCorp Vault deployments, where no patch exists yet, the report recommends compensating controls:

• Restrict access to Raft snapshot policies and the endpoints that expose them.
• Apply network segmentation so the Vault listener is not reachable from untrusted networks.
• Add runtime protection to detect or block unexpected code execution.
• Increase monitoring for unauthenticated or otherwise anomalous activity.

The report also stresses configuration hygiene. Exposed snapshot policies combined with weak or absent authentication controls are precisely the pattern the chain depends on, and regular audits paired with automated scanning can catch that pairing before an attacker does.

Why it matters

Vault and OpenBao sit at the centre of the trust model for large numbers of infrastructure stacks; they hold database credentials, API keys, TLS material and cloud secrets. Remote code execution in a secrets manager is therefore not a contained incident but a potential master-key event: everything the vault guards becomes accessible at once. That the flaw needs no authentication lowers the difficulty further and makes internet-facing or flat-network deployments the first candidates for compromise.

The episode also highlights a newer risk in the post-acquisition landscape. When a commercial product and its open-source fork share a codebase, a disclosure that reaches one vendor but not the other can leave paying customers exposed while the community fork ships fixes. Until HashiCorp publishes an advisory, organisations self-hosting Vault should assume the chain is exploitable in their environments, apply segmentation and monitoring as stopgaps, and verify the report's claims against official sources as they emerge.