A Realistic Code Execution Exploit Chain in OpenBao and Vault

In collaboration with the upstream OpenBao community, ControlPlane recently fixed a full exploit chain from unauthenticated access to full remote code execution. This is the second-ever remote code execution vulnerability in Vault and OpenBao. This chain combines disclosures from three independent reporters patched in the latest release.

There are two main takeaways from this post:

1. This release fixed a number of critical vulnerabilities that have existed for years in OpenBao and Vault.
2. A lack of reliable coordination between forks can result in customers being affected by critical vulnerabilities.

If you haven’t already patched to OpenBao v2.6.3 or 2.7.0, now is a good time to do so!

This post will be updated when IBM’s HashiCorp Vault remediates the below vulnerabilities.

The Situation

Secure Production Identity Framework For Everyone (SPIFFE) is securing the world in 2026 as the major driver of agentic and workload identity. It supports two commonly used backend authentication backends: X.509 certificates and JWTs.

Alongside this, the Automatic Certificate Management Environment (ACME - RFC 8555) is the preferred certificate issuance protocol, largely driven by the success of Let’s Encrypt.

It is not uncommon to back SPIRE with OpenBao, and one commonly sees Certificate Auth used to authenticate back to OpenBao with a certificate also issued by OpenBao. Certificate Auth supports URI SANs (used by SPIFFE) and OpenBao’s PKI supports roles to limit URI SANs.

flowchart TD
   P[Service Provisioner]
   A[Application]

   subgraph OpenBao
     subgraph ns:sandbox
       C[Cert Auth]
       S[KVv2 Secrets]
       end


       PKI[PKI]
       R[Raft Storage]
   end


   P--Create Role-->C
   P--Creates-->A
   A-- Authenticates To -->C
   A--Reads-->S

   PKI--Provides Certificates-->C

Consider the scenario of a service provisioner that, among other duties, needs to create a new Certificate Auth role for an application running on a platform. This platform will use SPIFFE credentials to authenticate and PKI in OpenBao will issue those certificates. That application needs to read credentials out of OpenBao, perhaps from a KVv2 static secrets engine and via a certificate issued by OpenBao. These applications are all sandboxed and should only have limited access to a single namespace, which PKI lives outside of.

Most CAs are used for multiple purposes, since they are rather hard to manage correctly; thus, ACME is enabled on this one. However, ACME can’t directly be used to issue SPIFFE certificates as it doesn’t support validating the URI SANs SPIFFE needs.

This service provisioner should have a very tightly scoped ACL policy: only to write certain fields in a Certificate Auth role. However, we assume there must be at least two other things in this environment:

1. An admin account, authenticated via SPIFFE, inside the sandbox with permissions to modify token_policies in the Certificate Auth role if necessary.
2. A snapshot service role in the root namespace, with capabilities to restore Raft.

We assume the service provisioner shouldn’t be allowed to update the admin account and by virtue of OpenBao namespaces, the sandboxed namespace definitely shouldn’t have access to the root namespace.

Lastly, we assume the service provisioner, like other apps with access to the sandbox, is authenticated via SPIFFE.

(An astute reader will note that the admin and provisioner access looks similar: we’ll assume an attacker inside the network generally can find out easily the SVID of the service provisioner since it will be interacting with a number of other services, but perhaps the admin’s identity is harder to guess.)

The Exploits

This exploit chain uses four patched vulnerabilities in OpenBao:

1. GHSA-j6wc-jpvg-xfxq: CVSSv4 @ 9.4 (Critical) – RCE via snapshot restore.
2. GHSA-x8fg-h69x-p28f: CVSSv4 @ 8.2 (High) – PKI ACME validation bypass.
3. GHSA-mjch-vcw3-hhmf: CVSSv4 @ 7.7 (High) – cross-namespace policy access.
4. GHSA-fg5x-7whg-6c28: CVSSv4 @ 7.6 (High) – bypass ACL denies via non-canonical URLs.

flowchart LR
  ATK{Attacker}


   subgraph OpenBao
     subgraph ns:sandbox
       C[Cert Auth]
       end


       PKI[PKI]
       R[Raft Storage]
   end


  ATK--1. ACME with URI SAN on the CSR-->PKI
  ATK--2. Authenticate as Provisioner-->C
  ATK--3.  Modify Admin as Provisioner-->C
  ATK--4. Authenticate to Admin Role-->C
  ATK--5. Modify Admin Role to access snapshot policy-->C
  ATK--6. Reauthenticate to Admin Role-->C
  ATK--7. Restore snapshot, giving RCE-->R

From the above exploit graph, we see:

1. The attacker can abuse GHSA-x8fg-h69x-p28f (PKI ACME validation bypass) to gain access to a certificate and key that identifies the service provisioner. Knowing the SVID and being able to solve challenges for any domain will allow an attacker to gain access to a certificate with an unvalidated URI SAN of their choosing.

   (We should note that OpenBao’s ACME by default doesn’t allow issuing certificates with the ClientAuth ExtKeyUsage field. This flag is non-standard but added to support certain Kubernetes and containerised workloads which live in an environment where DNS access is effectively the client identifier.)

2. The attacker can then use this certificate to authenticate as the service provisioner to the sandboxed Certificate Auth engine, gaining access to OpenBao at a somewhat privileged level, although it’s expected to be sandboxed and strongly restricted!

3. The attacker can then abuse GHSA-fg5x-7whg-6c28 (bypass ACL denies via non-canonical URLs) to overwrite the admin role’s required URI SANs (to those of the known service provisioner’s) via a non-canonical string such as AdMiN.

4. The attacker can then re-authenticate to gain access to this admin role and its policies within the sandbox.

5. Using these admin permissions, the attacker can update the admin’s own policy to add a new token policy, crossing the namespace boundary into the root namespace by abusing GHSA-mjch-vcw3-hhmf (cross-namespace policy access).

6. The attacker can then re-authenticate once more, granting this final token access to the snapshot restore endpoint.

7. Finally, the attacker can restore their own snapshot, unseal the node using their own keys, and achieve RCE by abusing GHSA-j6wc-jpvg-xfxq (RCE via snapshot restore).

While steps 1 and 2 are specific to this version of the exploit, other vulnerabilities addressed in this release help attackers achieve this in other scenarios:

• An attacker could abuse GHSA-2cjw-94fw-wqjx to obtain an admin’s token or otherwise gain a foothold in the cluster through an open redirect in the UI.
• If the identity system is in use, a similar ACL denial might be possible by accessing identity metadata from GHSA-hr5j-3j78-4vh2. Though this setup is fundamentally unsafe, as they could also adjust token metadata to bypass denials anyway.

Reproducer

If you’re a fellow security researcher or an enterprise user needing to reproduce this finding against your own OpenBao or Vault setup, reach out to us for the full PoC exploit chain. We’ll be releasing this publicly for the community’s education once everyone has had a fair chance to patch. In the meantime, if your team needs an extra set of eyes, our threat modelling experts are happy to help assess your environment.

Impact

This remote code execution vulnerability is significantly worse than the one last year: it is full, unconditional code execution against any pre-existing binary on the system, prohibited only by the attacker’s ability to guess the SHA-256 checksum. It does not rely on writing into the plugin directory (thereby working on read-only container images), doesn’t rely on an attacker guessing the unknown suffix after an audit log prefix (to guess the SHA-256 checksum), and it isn’t bound to the configured plugin_directory. Additionally, attackers can embed arbitrarily many guesses at binary paths and checksums, leading to a high likelihood of success despite the one-shot approach to execution.

Furthermore, while Vault’s and OpenBao’s threat models disclaim arbitrary control over the storage backend, this is easily accessible to many instances by the sys/storage/raft/snapshot-force API endpoint in the Integrated Storage (Raft) backend. It was also accessible to any attacker who could overwrite the storage state with their own. Anyone using the already-unsafe (and disabled by default) sys/raw APIs or recovery mode access could have also achieved code execution.

Notably, this works independently of how OpenBao is unsealed: if the victim’s node is configured auto-unseal, the attacker can provision a Shamir’s configuration, wait for it to restart, and perform a seal migration using their Shamir’s keys to the victim’s auto-unseal device.

The impact of the PKI ACME vulnerability is dependent on how widely used URI SANs are within an organisation. With SPIFFE as a motivating use case, many more organisations are adopting URI SANs attested certificates, leading to quite a wide potential impact. However, operators have the option of requiring External Account Bindings (EAB) on–including mandating it cluster-wide through environment variables–to require access to ACME to be first authenticated.

Besides tight policy scoping, many of these other vulnerabilities are hard to mitigate without an upgrade. Someone will need access to modify token_policies in authentication methods, creating the potential for exploitation if their access is compromised. Many will have access to paths which are vulnerable to missing normalisation. ACL policies will need to be evaluated to ensure that they refer to canonical path variants.

Sadly, many of the root causes of these vulnerabilities have been dormant for years.

The core portion of plugin execution has remained largely unchanged for several years, though it has seen recent improvements in both OpenBao (for OCI-based plugin distribution) and Vault (for remote, containerised plugin execution), both of which missed this vulnerability.

The policy store bypass (while missed in OpenBao’s implementation of namespaces) is due to the path.Join(...) behaviour of cleaning the path, leading to path traversal vulnerabilities.

And many places, in an effort to be more user-friendly, have long had case normalisation, which is particularly pervasive across the project.

Combined, these vulnerabilities provide an attacker with a broad range of tools for traversal and privilege escalation across the OpenBao and Vault platforms.

Remediation

The best remediation approach for these sets of vulnerabilities is simply to upgrade to a patched version. What workarounds exist that only fix a subset of the vulnerabilities:

• Code execution can be blocked by disabling plugins altogether (removing plugin_directory from your configuration), though this will block further usage of any legitimate plugins you might’ve already registered.
• ACME support globally can be configured to require EAB through the BAO_DISABLE_PUBLIC_ACME variable, though this is a significant, breaking change to roll out if it is not already enforced.

However, most of these attacks have obvious attack signatures in audit logs and monitoring tooling should be able to detect them fairly easily.

Timeline

Vulnerabilities

• September 4th - RCE through Snapshots disclosed by Tuan Do at Calif.

  • Same day - Embargoed patch developed by Alex Scheel at ControlPlane.

• September 4th - ACL Policy store case canonicalization issue disclosed by Tuan.

  • September 7th - Scope expanded by Alex to cover many additional subsystems beyond policy store.
  • September 11th - Embargoed patch developed by Alex.

• September 8th - Namespace Policy Traversal disclosed by Mike Reed.

  • September 11th - Embargoed patch developed by Jonas Köhnen at Liquid Reply.

• September 14th - OpenBao’s Patch the Planet engagement started.

• September 15th - ACME SANs bypass discovered by Marc Ilunga at Trail of Bits, disclosed formally on September 17th.

  • September 21st - Embargoed patch developed by Alex.

• September 16th - RCE was independently rediscovered by Marc.

• September 18th - Policy canonicalization rediscovered by Marc.

• September 23rd - v2.6.3 and v2.7.0 release shipped, fixing these vulnerabilities and more.

• September 23rd - Backchannel used to ensure HashiCorp is aware of these disclosed vulnerabilities.

• September 24th - Full exploit chain PoC developed by Alex.

These releases were made to address immediate vulnerabilities, and the project team continue to work on further triage, with another patch set expected in the coming weeks.

HashiCorp Disclosures

Many vulnerabilities in HashiCorp Vault affect OpenBao and vice versa. This chain was built from exploits we know affect Vault Community Edition and reasonably suspect to affect Vault Enterprise Edition.

When IBM was on OpenBao’s Technical Steering Committee (TSC) immediately after HashiCorp’s acquisition closed, following regulatory approvals granted in early 2025, a mutual disclosure policy between the two projects was proposed.

In September of 2025, the proposal was revisited with other contacts in HashiCorp’s security department in connection with an active mutual disclosure, facilitated by the reporter. Many of these former colleagues are no longer with the business.

In May of 2026, with introductions from OpenSSF staff, OpenBao once again reached out to IBM’s senior leadership to seek a mutual disclosure agreement.

IBM is unwilling to discuss one.

OpenBao’s policy is to respect any reporter’s decision to disclose to both organisations, though the reporter will have to handle coordination or hand-off themselves. While we try to negotiate agreeable dates, we tend to defer to HashiCorp’s preferred disclosure timeline in cases when the reporter provides one.

As 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, despite initially doing this.

IBM’s unwillingness to put an agreement in place has unfortunately meant that Vault customers were impacted at the time of release, with no mitigations in place.

Acknowledgements

Our greatest thanks to the many reporters and organisations who have disclosed vulnerabilities in OpenBao and to the many maintainers and community members who have helped make this release (and many past and future releases!) possible.

As AI tools have gotten better, more and more legitimate security reports have been arriving to the project. All but one vulnerability discovered in this release was found by an AI (or, highly suspected to have been discovered in this way based on the write ups given to us) – and that one remaining vulnerability, found by Jonas, was later independently discovered with AI. But we’ve also seen an increase in false positives, including cases where the human-in-the-loop obviously failed to access even the basic premise of the disclosure. We’ve also seen cases where AI has vastly underestimated the scope of a legitimate problem.

Want help accessing your security?

ControlPlane continues to be committed to supporting open source projects and their customers by performing threat modelling and assessing the full impact of security vulnerabilities. We hire and support maintainers so that they can move quickly and efficiently across large volumes of vulnerability reports, prioritising and remediating them based on their impact.

If you’re interested in finding out more about how ControlPlane Enterprise for OpenBao can support your business, ensuring timely CVE patches or in a broader capacity, conducting threat modelling of your environments, contact our team today to discuss how we can support you and your organisation.