OpenBao patched the Vault RCE on 23 September. HashiCorp Vault has not shipped it yet

TL;DR - The top post on r/netsec this week is an alert titled "Critical RCE Alert: Full takeover of HashiCorp Vault and OpenBao. OpenBao is patched. Vault remains exposed." The OpenBao half checks out. On 23 September 2026 OpenBao published CVE-2026-104090, a critical remote code execution bug scored 9.4 under CVSS 4.0, and shipped fixes in v2.7.0 and v2.6.3 the same day. Its advisory says it in plain words: this vulnerability is original to HashiCorp Vault. Vault's newest release is still v2.1.1 from 16 September, and its security notes cover dependency bumps only. One correction worth carrying, the advisory's own vector is PR:H, so this is not pre-auth. What you need to do: confirm who can reach your Vault API listener, read the audit log for snapshot, policy and token events you did not make, and stage the rotation order now - root credentials, then unseal material, then downstream secrets by blast radius.

By The Numbers

I read the r/netsec top feed with my coffee on Saturday and the top post stopped me, not because a critical RCE is news, but because of the second half of the title. OpenBao is patched. Vault remains exposed. The OpenBao half checks out, and the other half is the part that should get your attention this week.

Here is what the advisory actually says, what the sibling fixes do to the picture, and the order to work through tonight.

What CVE-2026-104090 actually is

The advisory is short and the bug is unusual. sys/storage/raft/snapshot and sys/storage/raft/snapshot-force write a Raft snapshot into storage. The snapshot-force variant replaces the current storage state with one unrelated to what is already there, and it does so without knowledge of the current seal mechanism. Normally you cannot manufacture valid encrypted storage without the keys that sealed it. This endpoint lets you supply one.

The plugin catalog lives inside that encrypted storage, so an attacker who can write to that endpoint plants a catalog entry pointing at a binary of their choosing and OpenBao executes it as a plugin on the next unseal. The fix, in the v2.7.0 release note, is to "ensure plugin command name is relative to plugin_directory prior to executing." Two lines matter for triage: operators not running the Raft storage backend are not affected, and the advisory ends with "This vulnerability is original to HashiCorp Vault." Same code lineage, stated on the record.

The headline says pre-auth. The vector says otherwise

That r/netsec framing is the part I would push back on. The CVSS 4.0 vector is AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H. Read the fourth element: PR:H, privileges high. This is network-reachable, but the caller already needs high privileges on that endpoint. Anyone telling you an unauthenticated attacker can take over Vault with one crafted request is repeating the Reddit title, not reading the advisory.

That does not make it a non-event. It makes the threat model privileged-path RCE, and the people holding high privileges on the snapshot endpoints are usually the break-glass operators and the automation identities. A much smaller population, and one whose access is rarely logged with care.

Why a critical RCE turns into a takeover story

The RCE is the payload. Four siblings in the same batch are about reaching the privileged place in the first place.

CVE-2026-104088, critical, 9.2, fixed in v2.6.2 on 18 August: request handling did not validate operation type when non-HTTP API requests were created, such as through inline authentication. Certain internal operation types would result in token issues when handled as a login request. That one is PR:N. Reported by Gia Bui from Calif.io.

CVE-2026-104093, high, 7.6: an ACL bypass via non-canonical URL access. Policies allowed case-insensitive, whitespace-trimmed and path-simplified access, so a broad wildcard grant with specific denies to carve out exceptions can be walked around with a name that does not match your deny rule. PR:L.

GHSA-mjch-vcw3-hhmf, high, 7.7, no CVE yet: the ACL policy cache let tokens with crafted policy names reference policies from other namespaces, acting across namespaces including root. The workaround is disable_cache = true, which the advisory warns will hurt performance.

CVE-2026-104092, high, 8.2, also PR:N: the PKI engine's ACME support did not validate SANs against completed orders, so an attacker could get a certificate valid for many non-validated SANs, including email addresses.

The individual bugs are serious. The pattern, where a token minting flaw, a policy bypass and a namespace traversal all landed in one release, is what should move your patch date forward.

Why the fork is ahead of the product

This is the part that made me slow down. OpenBao is the community-run fork of Vault, it carries the same code, and the September advisories say so. It shipped v2.7.0 and v2.6.3 on 23 September, then v2.7.1 and v2.6.4 on 1 October. The v2.7.0 security section lists nine advisories, and every one cites the same pull request, GH-4065. One coordinated drop, not nine separate emergencies.

HashiCorp Vault's newest release is v2.1.1, published 16 September 2026. Its security section lists three dependency bumps and nothing about the plugin catalog, the snapshot endpoints or the policy cache. So the fork that exists because of a licensing change is shipping the fix, and the product it forked from has not. I have no HashiCorp advisory promising a date, so I will not predict one. Check the release feed yourself this week.

What to do tonight

1. Work out whether this is your problem at all. Check the storage backend first. Not on Raft means CVE-2026-104090 does not apply.

2. Find out who can reach the Vault API listener. The question is not "is Vault on the internet". It is "what can reach port 8200, from where, with what". A management VLAN is not a boundary if every contractor laptop and CI runner sits on it.

3. Read the audit log before you patch, not after. This tells you whether you have a patch job or an incident. Look for snapshot and snapshot-force calls, for policy and catalog writes, and for token creation at times nobody logged in. Confirm your audit device was recording before you trust an empty result.

4. Agree the rotation order now, while nothing is on fire. Not "rotate everything at once". Root credentials first, then unseal material, then downstream secrets ordered by blast radius. Working out which secrets are crown jewels, and who has to be awake to change them, takes an afternoon when you have a week.

5. Re-read your ACL policies for wildcard-plus-deny. If CVE-2026-104093 matches how you wrote your policies, a deny rule is not doing what you think. That is a review task, not a patch, and upgrading will not fix it.

Why this could still be good

A critical remote code execution in a secrets manager was found, responsibly disclosed, and fixed by the fork within the same business day it was published. Nine advisories in one coordinated pull request is a community doing what a security response process is supposed to look like, and OpenBao shipped two follow-up releases eight days later rather than sitting on the next tier of findings.

The uncomfortable part sits next to it. Every fix the fork lands is also a fix upstream will eventually need, and until it lands there the fork carries security weight for an ecosystem running on both. You either track both release feeds or you accept a window where one of them carries risk you have not addressed.

Nothing in the batch needs memory corruption, a race condition, or a user clicking something. These are logic bugs in authorisation and storage handling, which are deterministic, testable and closable with a version bump.

Key Takeaways

• CVE-2026-104090 is real, critical, scored 9.4, published 23 September 2026 and fixed the same day.
• It needs high privileges. The vector is PR:H. Anyone calling it pre-auth is repeating a headline.
• It is original to HashiCorp Vault. The newest Vault release is v2.1.1 from 16 September.
• Raft storage only. On file or integrated storage, this bug does not apply.
• The batch is the story. A PR:N token minting bug, an ACL bypass and a cross-namespace policy cache traversal landed alongside the RCE.
• Read the audit log before you patch, then rotate in order: root credentials, unseal material, downstream secrets by blast radius.

FAQ

Is this a pre-authentication RCE in HashiCorp Vault?

No. The vector is PR:H, so the caller needs high privileges on the snapshot endpoint. The "full takeover" framing is about impact once that access exists, not about a single unauthenticated request.

What is the CVE number?

CVE-2026-104090, tracked as GHSA-j6wc-jpvg-xfxq, published 23 September 2026. Two siblings in the same drop are CVE-2026-104092 (PKI ACME unvalidated SANs) and CVE-2026-104093 (ACL bypass via non-canonical URLs). The policy cache namespace traversal has no CVE yet.

I run OpenBao. Am I fine?

On v2.7.0 or v2.6.3, or the later v2.7.1 and v2.6.4, you have the September batch. Six more advisories landed on 1 October, so run the later patch.

I run HashiCorp Vault. What do I do now?

Check whether you are on the Raft storage backend, check who can reach the API listener and with what privileges, read your audit log for snapshot, policy and token events, and stage the rotation order.

Why does the attacker not need the unseal keys?

Because snapshot-force replaces the storage state wholesale, without knowledge of the current seal mechanism. They supply the state, so they never had to seal anything.

Is there evidence anyone exploited this?

I have not found a citable claim of active exploitation and I am not going to imply one. The fix is a week old on the OpenBao side and unshipped on the Vault side, which is exactly the window this gets picked up.

My Take

What I keep coming back to is how ordinary the failure is at the business level. Nobody chose to run an unpatched secrets manager. Somebody scheduled a maintenance window, looked at a queue of other work, and put it behind a quarter. The fork shipped the same day the advisory went public. The difference between the two estates is not security maturity, it is a patch date.

The thing I would change is the pre-auth framing. Every headline saying "unauthenticated" sends an operator into an emergency patch window they may not need, and the ones that genuinely are pre-auth stop being news. The CVSS vector is right there in the advisory, free, and more informative than the title.

None of this is exciting. But it works. Check your storage backend, check who reaches the listener, and put the rotation order in writing while you are calm.

Mathew Clark Founder, SecureInSeconds Currently: staring at a Vault version list where the newest entry is older than the fork's.

Further Reading

• CVE-2026-104090: RCE via the snapshot-force plugin catalog replacement
• CVE-2026-104093: ACL bypass via non-canonical URL access
• CVE-2026-104088: internal operation dispatching leads to token creation
• Policy cache namespace traversal in OpenBao, no CVE yet
• CVE-2026-104092: PKI ACME issues certificate with unvalidated SANs
• OpenBao v2.7.0 release notes, the 23 September batch
• OpenBao v2.7.1 release notes, the 1 October follow-up
• HashiCorp Vault v2.1.1, the newest release as of 4 October 2026
• SolarWinds ARM: a hard-coded key and unauthenticated RCE
• Token theft is the new credential stuffing