OpenBao vs. HashiCorp Vault: The Fork War and the RCE That Broke the Truce

Launch day, and the design that outlived the company

Vault's repository was created on February 25, 2015 — the initial commit ed3069f01d still anchors the LICENSE file's history in the fork — and v0.1.0 shipped on April 28, 2015, the same day the launch post reached the top of Hacker News. What Armon Dadgar and Mitchell Hashimoto had built was not a password store. It was an encrypted-barrier architecture: every request, authenticated or not, hits a sealed barrier that decrypts storage only for the lifetime of a single request; the barrier key itself is assembled at unseal time from Shamir's secret sharing, so that no single operator ever holds the root key. Around that core sat the ideas that made Vault infrastructure rather than tooling: dynamic secrets (issue a database credential with a TTL instead of rotating a shared password), leases (everything issued expires), response wrapping (a secret can be handed over inside a single-use token), and the audit log as a first-class write-only sink. The launch-day comment threads already read like a requirements list for the next decade of the industry: teams wanted AWS IAM credential brokering, PKI issuance, and encryption-as-a-service. All three became built-in engines within two years.

The moat gets built (2017–2023)

The release history that matters to this story is short. Vault 0.8.0 (August 9, 2017) introduced the plugin architecture that would haunt both projects eight years later — external auth and secrets engines executed as separate binaries from a configurable plugin_directory, checksum-pinned at registration. Vault 0.10.0 (April 10, 2018) added versioned KV (KVv2). Vault 1.0.0 (December 3, 2018) declared the Integrated Storage Raft backend production-ready. And Vault 1.14.0 (June 21, 2023) shipped the feature that step one of the 2026 exploit chain would abuse: an ACME server in the PKI engine, letting standard clients like certbot and cert-manager request certificates "with no knowledge of Vault APIs or authentication mechanisms." The release note carried its own warning — for public-facing instances, "we recommend requiring External Account Bindings (EAB) to limit the ability to request certificates to only authenticated clients" — which is, verbatim, the mitigation operators had to rediscover in September 2026.

Meanwhile the commercial architecture hardened along a different axis. Namespaces — isolated mount tables, policies, and token scopes inside one cluster — arrived as a Vault Enterprise feature and stayed there, alongside HSM auto-unseal, KMIP, replication, and Sentinel policy. By 2023 the open-source edition was the funnel; the things a multi-tenant platform actually needed were the paywall. When The New Stack covered the fork in December 2023, it described the plan bluntly: "one of the initiatives of the project is to build out some of the advanced features that have only been in the Vault Enterprise commercial edition, such as high-speed replication, multiple namespaces, and perhaps even a policy-as-code framework." That sentence became OpenBao's roadmap, and namespaces — the single most-requested Enterprise feature in every platform-engineering conversation about Vault — became its proof of intent.

HashiCorp's announcement that Vault, Terraform, Consul, Nomad, Packer, Vagrant, and Waypoint would move from MPL-2.0 to the Business Source License landed on August 10, 2023. For Vault the switch took 48 days to reach a release: the last MPL-licensed train was v1.14.4 (published September 26, 2023), and v1.15.0 — dated September 27, 2023 in its own changelog — shipped under BSL 1.1. The LICENSE diff between those two tags is the entire story in two headers:

The BSL's operative restriction — production use is permitted, but offering the software as a competing commercial service is not, until each release's change date — was aimed at cloud providers in general. But the affected party that actually moved first was not a cloud provider. It was an IBM-anchored Linux Foundation project.

An edge project with a compliance problem

Open Horizon — IBM's LF Edge edge-computing framework, along with EdgeX Foundry — used Vault internally and was offered commercially by other organizations. Under the BSL, that combination became impossible. Joe Pearson, Open Horizon's project chair and an IBM technology strategist, explained the bind to TechTarget in words that should be quoted in every postmortem of the BSL era: "Open Horizon's goal is not to compete with Hashicorp Vault, and in fact, they've built a great product with which we would like to continue to provide compatibility. Unfortunately, Linux Foundation projects cannot embed BSL-licensed code. So we've been placed in a situation where our alternatives are to switch to a competing product with an open-source friendly license or to fork an earlier MPL-licensed branch of Vault and continue to maintain that ourselves going forward."

The design-candidate submission for Open Horizon considered adopting EnvKey instead — and rejected it on migration cost. In late October 2023 the technical committee voted to fork. The repository was created on November 9, 2023 at 18:17 UTC — the same day as the first working group meeting — and issue #1 appeared the next morning, opened by Nathan Phelps, an IBM senior software engineer: "Fork the current and near future Vault source to this repository. Must include the current and future source for the 1.14.x stream of Vault changes." The assignment of that issue to Jeremiah Butler on November 27 — "I'll start by updating the import references and getting it building in our repo" — and its eventual closure by PR #45, "feat: rename Vault to OpenBao in build files", in February 2024, is the fork's birth certificate.

What the import actually looked like

The fork did not start from a tarball. OpenBao imported Vault's full git history — its oldest commit is still the February 25, 2015 initial commit — and then began a compliance scrub on top. The early native commits read like a sterilization log: "[COMPLIANCE] Add Copyright and License Headers" (PR #50, November 1, 2023), "enos: fix licensing on backported files" (PR #24162, November 16, 2023), and dependency bumps from the new repo's own PR numbering (#39, #40) interleaved with the last upstream Vault commits still flowing in from the release/1.14.x branch — including "Bumped product version to 1.14.7" on November 8, 2023, which pins the fork point: the last MPL-licensed maintenance line, a few commits ahead of v1.14.7, just before HashiCorp moved even its maintenance branches under the BSL.

IBM's fingerprints, on the record

The governance record is unambiguous about who founded the fork's technical steering committee: the LF Edge proposal lists five founding organizations — IBM, IOTech Systems, Viaccess-Orca (Orange), WALLIX, and ZEDEDA — with thirteen initial committers including Nathan Phelps (IBM, Open Horizon) and Alexander Scheel, the independent maintainer who would later do the security work at the center of this story. The TSC was formalized in June 2024 per the project's own GOVERNANCE.md. At the December 2023 launch, IBM had "not (yet) officially endorsed" the project, as The Register put it — but the HN launch thread (314 points, December 9, 2023) caught the subtext anyway. One commenter put it flatly: "IBM, somewhat unofficially, is behind this recent fork." And a self-described HashiCorp engineer, posting from a throwaway account in the same thread, supplied the detail that reframes the entire BSL episode: "There's no overall consensus within engineering about the change itself. What is amusing is that most of the public response has been aimed at Terraform whilst internally Terraform wasn't the concern. It was Vault. It was IBM." Fourteen months later, IBM announced it was buying HashiCorp.

The launch thread also preserved the complaint that would define the fork's most visible engineering work. The top comment, from a frustrated Vault operator: "Vault had a lot of community contributions blocked or stalled due to internal politics/roadmap stuff at [HashiCorp]... the Vault plugin model is terrible IMO... Lifecycling plugins, especially with container deployments of Vault, is a nightmare." An OpenBao maintainer replied asking for issues. Three years later, OpenBao 2.6/2.7 shipped OCI-based plugin distribution with digest pinning, automatic registration, and a bao plugin prune command — the nightmare, addressed.

OpenBao's versioning decision was itself a statement: the first release was not 1.15 — it was 2.0.0. The jump over Vault's entire 1.x line said out loud what the LICENSE diff implied: this is a different product now. The alpha arrived March 29, 2024, the beta on June 18, and GA on July 16, 2024 — with a warning banner in its own release notes that tells the deeper licensing story better than any blog post: "OpenBao's 2.0.0 GA does not include the builtin WebUI! You can only access a running Bao instance via the CLI or API." Vault's web UI had never been plain MPL-2.0 code; the fork could not ship it. The UI was rebuilt and reintroduced in v2.2.0 (March 5, 2025, PR #940) — eight months of GA spent as a headless secrets server.

The 2.0.0 changelog is a catalog of the fork's early instincts, and several entries read as corrections to Vault's oldest operational debts: mlock functionality was removed outright (PR #363) — two years before IBM-era Vault would concede the same point in its 2.2.0 breaking change ("Remove cap_ipc_lock capability on vault at build time... Operators should set disable_mlock = true"); the Shamir implementation was hardened to shuffle X coordinates with a CS-PRNG instead of math/rand (PR #210); cert auth was fixed to compare the full bytes of trusted leaf certificates "to prevent trusting certs with the same serial number but not the same public/private key" (PR #173); Transit gained XChaCha20-Poly1305 keys (PR #36) and lost the convergent encryption modes migrated from Vault v0.6.2 (PR #85). And in one of the more aggressive supply-chain moves any fork has made, OpenBao retracted every prior Vault version of its core, api, and sdk Go modules (PR #238) — anyone resolving the module path gets the fork's versions only, by design.

The New Stack's December 2023 prediction — that the fork would port Enterprise features — became the announcement of May 30, 2025: "Announcing OpenBao Namespaces," by Christoph Voigt. The framing was architectural, not commercial: "Each namespace acts like a mini-OpenBao, with its own policies, authentication methods, secret engines, tokens, and identity groups," enabling "a true OpenBao-as-a-Service model" where tenant administrators self-manage without cluster-level operators. The blog also declared namespaces "one of a few planned stepping stones towards OpenBao's horizontal scalability journey." Namespaces went beta in v2.3.0-beta20250528 (May 28, 2025) and GA in v2.3.1 (June 25, 2025). The per-namespace system backend — visible in the output as ns_cubbyhole, ns_identity, ns_system accessors — later became a single shared sys backend across all namespaces in 2.6.0 (PR #3007), an idle-memory optimization that itself became relevant to the September 2026 story.

Then the fork went past parity. OpenBao 2.6.0 (July 14, 2026) added Namespace Sealing (PR #3297): "Partitions tenant storage with distinct cryptographic key material. Allows tenants to revoke access to their namespace via seal operation without impacting other tenants." A tenant locking itself out of its own namespace data without a cluster-wide seal event is a primitive Vault Enterprise never shipped — the community edition of the fork had overtaken the commercial edition of the ancestor on the exact feature that defined the ancestor's moat.

Governance moved the same season. On March 28, 2025, Alexander Scheel opened the application to move OpenBao laterally within the Linux Foundation — from LF Edge to the OpenSSF as a sandbox project (ossf/tac PR #461). The application was candid: "We currently receive no budget from LF Edge," the contributor base was "not Edge-aligned and instead more broadly security focused," and LF Edge's foundation membership requirements were ones "this project cannot meet." The LF Edge TAC chair approved with no objections. On June 17, 2025, OpenBao joined the OpenSSF. The project that exists because of a license fight had found its durable home in the security foundation — with its maintainer base now including ControlPlane (which also staffs Flux maintainers), the same company that would coordinate the 2026 RCE response.

The acquisition HashiCorp's throwaway-account engineer had hinted at closed on February 27, 2025: IBM bought HashiCorp for $6.4 billion, taking custody of Vault — and with it the ancestor of a fork its own edge project had seeded. The corporate irony is now the defining governance fact of the ecosystem: the company whose engineers founded OpenBao's TSC, and which sat on that TSC in the months after the acquisition closed, owns the upstream whose security coordination the fork would later beg for in writing.

IBM-era Vault renumbered. Vault 2.0.0 shipped April 14, 2026 — a major-version bump that vaulted past the fork's own 2.x line — carrying, among its security entries, "core: reject URL-encoded paths that do not specify a canonical path." That single changelog line is the quiet beginning of IBM's hardening against the exact vulnerability class (non-canonical path handling) that the September 2026 chain would weaponize. An Enterprise 1.21 LTS line continued shipping patches in parallel, and the Enterprise feature conveyor kept moving: a PKI External CA plugin that acquires certificates from public CAs through ACME, first-class AI Agent support with an Agent Registry and OAuth resource server (beta, Enterprise), KMIP and SCEP plugins. The community edition, as before, got the funnel.

HCSEC-2025-14: eight years of dormant attack surface

On August 1, 2025, HashiCorp published HCSEC-2025-14: "Privileged Vault Operator May Execute Code on the Underlying Host" — CVE-2025-6000, CVSS 9.1, CWE-94. The mechanics married two features that had coexisted since the plugin era: a privileged operator with write access to sys/audit in the root namespace could create audit log files inside a configured plugin_directory, then use plugin registration to execute them — reproducing an audit file's HMAC'd contents well enough to satisfy the registration checksum, and getting arbitrary code execution on the host. The affected range told the real story: every Vault since 0.8.0 — August 9, 2017. The bug had been live for eight years and through eighteen minor releases. Fixes shipped in Community 1.20.1 and Enterprise 1.20.1, 1.19.7, 1.18.12, and 1.16.23.

HashiCorp disclosed unilaterally. OpenBao — whose codebase carries that same 2017 plugin-execution lineage — had no patch on disclosure day. Its mirror advisory, GHSA-xp75-r577-cvhp / CVE-2025-54997 ("Privileged OpenBao Operator May Execute Code on the Underlying Host," critical), shipped with v2.3.2 on August 8, 2025, alongside a batch of same-day fixes including a token-privilege elevation (CVE-2025-54996). Seven days of publicly-documented critical exposure for every OpenBao deployment, because the two projects no longer had a working channel.

How the channel died, in the maintainers' own timeline

ControlPlane's September 2026 post — written by Alexander Scheel, the OpenBao maintainer who developed the embargoed patches — lays out the coordination history with dates. When IBM sat on OpenBao's TSC immediately after the acquisition closed, "a mutual disclosure policy between the two projects was proposed." In September 2025 it was revisited with HashiCorp's security department "in connection with an active mutual disclosure" — by then, "many of these former colleagues are no longer with the business." In May 2026, with introductions from OpenSSF staff, OpenBao reached out to IBM's senior leadership to seek a mutual disclosure agreement. The post's next sentence is six words: "IBM is unwilling to discuss one." And because "too many vulnerabilities have been unilaterally disclosed by HashiCorp — including last year's RCE — the OpenBao maintainers declined to continue proactively disclosing and coordinating vulnerabilities with HashiCorp." Two codebases sharing 2017-vintage plugin internals, with no agreement on how to warn each other. What followed was predictable, and it arrived in September 2026.

On September 23, 2026, OpenBao shipped two releases in the same hour — v2.6.3 at 17:06 UTC and v2.7.0 at 17:39 UTC — fixing what ControlPlane's post, published five days later, described as "a full exploit chain from unauthenticated access to full remote code execution," and "the second-ever remote code execution vulnerability in Vault and OpenBao." The chain stitched together disclosures from three independent reporters: Tuan Do (Calif.) reported the snapshot-restore RCE on September 4; Mike Reed reported the namespace policy traversal on September 8; Marc Ilunga (Trail of Bits, whose "Patch the Planet" engagement with OpenBao began September 14) found the ACME bypass on September 15 and independently rediscovered the RCE a day later; Jonas Köhnen (Reply) developed the embargoed traversal patch. Alexander Scheel developed the other embargoed patches and the full-chain PoC on September 24. The post's acknowledgements section contains the era's signature sentence: "All but one vulnerability discovered in this release was found by an AI."

The bug that lived in both hulls

The most sobering evidence in the disclosure is a GitHub blame link. The plugin-execution core the RCE abuses — vault/plugin_catalog.go, lines 829–840 — traces to commit 8993802145833ab01d49c6070d787a9eccb81546, a nine-line backport dated December 21, 2023, inherited from the 1.14.x lineage and "largely unchanged for several years," as the post puts it. The policy-store bypass traces to the path.Join(...) path-cleaning behavior at policy_store.go L881–883; the case normalization the ACL bypass abused lives at builtin/credential/cert/path_certs.go L237–241, "particularly pervasive across the project." These are not OpenBao bugs or Vault bugs. They are 1.14.x bugs that both ships carried, and both ships' recent re-architectures — OpenBao's OCI-based plugin distribution, Vault's remote containerized plugin execution — "both of which missed this vulnerability," in the post's words. The fork war split licensing, governance, and feature sets; it did not split the attack surface. Only the remediation split — and that is precisely what no coordination agreement means in practice.

OpenBao's fixes landed in one PR (#4065, backported across both release trains): plugin command names must resolve relative to plugin_directory before execution; plugin catalog writes are restricted to the root namespace; ACME issuance of non-validated SANs is forbidden outright; and the SDK gained a ResolvePathOperation primitive "to report canonical URLs prior to ACL evaluation" — canonicalization moved from convention into the request path itself. For operators who could not upgrade immediately, the post's workaround list was short and blunt: disable plugins entirely (remove plugin_directory from the configuration), or set BAO_DISABLE_PUBLIC_ACME to force EAB on ACME cluster-wide — "a significant, breaking change to roll out if it is not already enforced."

The remediation race, on the other side

Vault's own changelog tells the other side without ever mentioning OpenBao. On October 7, 2026 — fourteen days after OpenBao's release — Vault 2.1.2 appeared with: "Fix plugin catalog entries restored from a raft snapshot, written through sys/raw, or replicated being able to run a binary outside plugin_directory," plus use-time enforcement ("Plugin catalog entries are now checked against plugin_directory whenever they are used, not only at registration"). On October 15, Vault 2.2.0 rejected ACME finalizations carrying URI, email, or Other SANs under the default policy — with an escape hatch named, without apparent irony, sign-verbatim-unsafe — and fixed the case-variant exact-deny bypass across AppRole, AWS, Azure, GCP, Kubernetes, SCEP, TPM, GitHub, certificate, policy, and userpass names. On October 22, Vault 2.2.1 fixed the policy cache-key collision that let policy-name aliases like "./root" and "a/../root" resolve to the immutable root policy. Twenty-two to twenty-nine days behind the fork, with no coordinated advisory, no shared CVE, and one upgrade hazard IBM shipped quietly in the changelog: "Existing deny rules using mixed-case resource names will fail open (become allow-all) after upgrade until rewritten with lowercase names."

As of November 11, 2026 — seven weeks after the chain's publication — ControlPlane's post still reads "This post will be updated when IBM's HashiCorp Vault remediates the below vulnerabilities," and the October releases answer it in the changelog's whispers rather than in a coordinated announcement. Both codebases are now patched for the published chain; neither project will say so in the same document.

Honest weaknesses — OpenBao

The upgrade tax is real and recent. OpenBao 2.7.0 alone removed the built-in LDAP, Kerberos, and RADIUS auth engines from the main binary (now external plugins, PR #3882), removed every built-in cloud KMS seal, removed the HSM distribution, removed the file storage backend, and moved the Go module to github.com/openbao/openbao/v2 with most code behind internal/ (PR #3210) — packagers must rewrite their ldflags. If you run a brownfield OpenBao deployment, 2.6→2.7 is a project, not a bump.

Its security record is transparent because it has to be. Fifty-one published advisories since mid-2025 is the honest cost of running a secrets manager under modern AI-assisted auditing with a Trail of Bits engagement — and several of those bugs (namespace traversal, LIST deny bypass, recovery-mode timing leak) were in code the fork itself wrote or ported. The namespaces port, for all its strategic value, introduced the cross-namespace policy cache traversal that became step four of the 2026 chain.

Enterprise support is third-party, not first-party. No OpenBao vendor is contractually obliged to answer a 3 a.m. page; the commercial ecosystem (ControlPlane, Secretz) is young, and the OpenSSF sandbox stage means the foundation's involvement is still largely governance, not funding.

Honest weaknesses — Vault

The disclosure posture is now a documented liability. The maintainer who coordinated the 2026 response states in print that IBM declined to discuss a mutual disclosure agreement after three attempts across a year, and that Vault customers "were impacted at the time of release, with no mitigations in place." The October 2026 fixes shipped 14–29 days after the fork's, without coordinated advisories.

BSL compliance is an ongoing engineering constraint for your users. Any internal platform that embeds, repackages, or offers Vault-derived services — the exact thing an internal developer platform does — needs counsel to read the Additional Use Grant per release. The license that created OpenBao has not changed.

Its community edition is a funnel, and the funnel shows. Through 2.2.1, post-quantum crypto, per-tenant sealing, and OCI-native plugin distribution all live outside IBM's community line — two of them in a competitor's MPL codebase. And the 2.2.x mixed-case deny fail-open migration is the kind of sharp edge a coordinated disclosure process would have surfaced loudly rather than in a changelog bullet.

Three years in, the fork war has produced a genuinely unusual equilibrium. OpenBao is no longer a protest project; it is the OpenSSF-hosted, ML-DSA-shipping, namespace-sealing heir to Vault's open-source lineage, with an advisory cadence that outpaces its ancestor's and an enterprise-features-for-everyone strategy that has already erased the fork's biggest functional gap. Vault under IBM is the install-base incumbent with the Enterprise conveyor belt, HCP, and a compliance story (FIPS, Sentinel, KMIP) the fork does not try to match — and it is now visibly behind on disclosure coordination, an area where a secrets manager cannot afford to be behind anyone.

The strategic lesson for platform teams is the one the 2017-vintage plugin core teaches: forking splits governance, not attack surface. The September 2026 chain hit both codebases because both still run code their authors shipped eight years and one acquisition ago, and the only difference between the two outcomes — 0 days versus 14–29 days of exposure — was organizational, not technical. When you choose between these two, you are no longer primarily choosing a feature list. You are choosing whose security process you trust to tell you first.

Who should skip this

Teams standardized on Vault Enterprise compliance machinery. If your operating model is FIPS-validated HSM auto-unseal, Sentinel policy, KMIP clients, or HCP Vault Dedicated with an IBM paper trail behind it, OpenBao's third-party support ecosystem is not yet an equivalent procurement story. The fork's PQC and namespaces work is impressive; your auditor's checklist is not moved by impressiveness.

Greenfield teams without a secrets-management problem worth owning. If you have one cloud account and a dozen workloads, a managed KMS plus your cloud's native secrets manager — or External Secrets Operator pointed at it — beats operating either a Vault or an OpenBao cluster, with its unseal ceremonies, storage backends, upgrade taxes, and 51-advisory patch cadence. The barrier architecture is for platforms, not projects.

Organizations that cannot stomach a young commercial ecosystem. OpenBao the codebase is battle-inherited; OpenBao the vendor relationship is three years old, sandbox-stage, and staffed by maintainers whose employers happen to care. If you need a decade-old SLA culture behind your secrets infrastructure, that product is called Vault Enterprise — and its 2026 disclosure record is the price you accept for the maturity.

Anyone planning to ignore the shared lineage. The single worst outcome of the fork war would be assuming either side's patches cover you. If you run Vault, OpenBao's September advisories are your reconnaissance report on your own binary — the ACME, canonicalization, and plugin-catalog families landed in your codebase too, three weeks later and quieter. Read both changelogs. The attackers already do.