Vault vs OpenBao in 2026: the RCE patch gap, the features that differ and what a switch touches

Check whether your Vault or OpenBao is exposed in five commands

A server is exposed to the full chain when it runs an unpatched version on Raft storage with a plugin directory configured and ACME open without account binding. Each missing piece narrows it. Start with the version and storage, then the configuration the chain needs:

vault status                       # or: bao status
                                   # Version, Storage Type (raft?), Seal Type (shamir?)
curl -s $VAULT_ADDR/v1/sys/health  # version without a token
vault read pki/config/acme         # enabled, default_directory_policy, eab_policy
vault read sys/config/state/sanitized | grep plugin_directory
for p in $(vault policy list); do vault policy read "$p" | grep -q raft/snapshot && echo "$p"; done

Exposed versions: OpenBao before 2.6.3, Vault Community 2.1.1 and earlier, Vault Enterprise before the four fixed releases. Not on Raft: the RCE step does not apply (GHSA-j6wc). On ACME, eab_policy set to always-required closes the first step; OpenBao's BAO_DISABLE_PUBLIC_ACME=true forces it on every mount.

The sources disagree on auto-unseal. HashiCorp says Vault clusters "using auto-unseal, or without a configured plugin directory, are not affected" by the RCE step. ControlPlane shows that on OpenBao an attacker can set up Shamir keys and migrate the seal, so auto-unseal does not stop it there. Neither speaks about the other product, so treat auto-unseal as narrowing the risk, not removing it.

OpenBao gives away namespaces and HSM unseal that Vault keeps in Enterprise

OpenBao's free release includes features that Vault sells: namespaces since 2.3.1 in June 2025, read-scaling standby nodes since 2.5.0, PKCS#11 HSM auto-unseal and per-namespace sealing since 2.6.0, and in 2.7.0 control groups and ML-DSA post-quantum signatures in PKI and Transit. In Vault, namespaces need an Enterprise licence or HCP, and PKCS#11 auto-unseal requires Vault Enterprise.

That is why the namespace step in this chain hit OpenBao's free users but only Vault Enterprise. Adoption has followed the free features: GitLab's Secrets Manager, generally available since GitLab 19.5 in October 2026, is built on OpenBao, and NVIDIA is on OpenBao's adopters list.

Vault keeps replication, Sentinel and 23 storage backends

Vault Enterprise has what OpenBao does not: performance and disaster-recovery replication, Sentinel policies, Secrets Sync, the Transform and KMIP engines, and FIPS 140-3 builds; the OpenBao project ships none of them, though ControlPlane's paid edition offers FIPS. OpenBao's compatibility policy says some of these are "impossible to do without reverse engineering Vault Enterprise". A team that uses any of them has no in-place path to OpenBao.

Storage is the other gap. Vault documents 23 backends, from Consul and DynamoDB to S3 and etcd; OpenBao 2.7 documents four, and its docs recommend PostgreSQL as "an easier storage backend to safely operate than Raft". A Vault on Consul or DynamoDB has to move to Raft before it can move to OpenBao.

A move from Vault to OpenBao touches storage, tokens, plugins and Kubernetes

OpenBao's in-place migration guide joins OpenBao nodes to a Vault Raft cluster one follower at a time. It was tested only from Vault 1.14.1 with Shamir unseal, and says: "Newer versions are untested and unsupported: OpenBao makes no guarantees about storage compatibility with Vault." Every Vault since then is outside that test, so rehearse on a snapshot copy.

What else changes:

• Tokens. New tokens lose Vault's hvs. prefix. Old tokens work until their TTL; secret scanners and log redaction that match hvs. stop matching.
• Plugins. Mounts whose plugin OpenBao does not ship are skipped at startup, and reads return "No value found". LDAP, Kerberos and RADIUS moved out of core in 2.7.0. List mounts with vault secrets list and vault auth list first.
• CLI. The binary is bao, and BAO_ variables fall back to VAULT_.
• Terraform and OpenTofu. OpenBao has no provider of its own. People point the hashicorp/vault provider at it, which only third parties report testing.
• Kubernetes. The OpenBao Helm chart 0.30.4 still uses HashiCorp's vault-k8s image for the agent injector, so existing annotations keep working. Its CSI provider is OpenBao's own. External Secrets Operator lists its OpenBao provider as alpha, tested with OpenBao 2.2.0.

No source documents a path back from OpenBao to Vault.

Rotate the copies, not only the vault, after a compromise

Code running on an unsealed Vault or OpenBao node can read everything that node decrypts, so treat a compromised cluster as having leaked every secret in it. Neither project publishes a rotation playbook for this chain. Inside the server: rotate and rekey (vault operator rotate, vault operator rekey), revoke tokens and leases, reissue PKI roots and intermediates, rotate Transit keys and the root credentials of database and cloud engines.

The secrets also live in copies outside it. Agent sidecars and CSI mounts hold them in pods, Vault Secrets Operator and External Secrets Operator copy them into Kubernetes Secrets in etcd, Terraform writes the secrets it reads into state, and CI jobs fetch them on every run. Each copy has to be rotated at the source. On Stackness, Terraform is on 2 public stacks and Kubernetes on 1 as of 26 October 2026, bots removed (how I count); the DevOps and infrastructure tools show the rest of that slot.

Pick OpenBao if, pick Vault if

Pick OpenBao if:

• you run Vault Community on Raft or PostgreSQL and use none of the Enterprise features
• you want namespaces or HSM auto-unseal without an Enterprise contract
• an MPL licence and a foundation-hosted project matter to your legal team
• you can rehearse a migration from a Vault newer than the tested 1.14.1

Pick Vault if:

• you use replication, Sentinel, Secrets Sync, Transform, KMIP or FIPS builds
• your storage is Consul, DynamoDB, S3 or another backend OpenBao does not document
• you want HCP Vault Dedicated as a managed service from IBM
• you rely on Vault Secrets Operator, which I found no report of working against OpenBao

Whichever you run, upgrade first: OpenBao 2.7.1 or 2.6.4, Vault 2.2.1.