CVE-2026-34986: 
Packer vulnerability analysis and mitigation

CVE-2026-34986 is a denial-of-service vulnerability in the Go JOSE library (github.com/go-jose/go-jose) caused by a panic during JSON Web Encryption (JWE) decryption. When a JWE object specifies a key wrapping algorithm (any KW-suffixed algorithm except A128GCMKW, A192GCMKW, and A256GCMKW) and the encrypted_key field is empty, the library panics attempting to allocate a slice of zero or negative length. Affected versions include go-jose/v3 < 3.0.5, go-jose/v4 < 4.1.4, and all versions of go-jose/v2 (≤ 2.6.3, no patch available). The vulnerability was published on March 31, 2026, and carries a CVSS v3.1 base score of 7.5 (High) (Github Advisory, go-jose Advisory).

The root cause is an incorrect buffer size calculation (CWE-131) combined with an uncaught exception/panic (CWE-248) in cipher.KeyUnwrap() within key_wrap.go. When encrypted_key is empty, the function attempts to allocate a slice with a zero or negative length derived from the ciphertext length, triggering a Go runtime panic. The vulnerable code path is reachable via ParseEncrypted(), ParseEncryptedJSON(), or ParseEncryptedCompact() followed by a call to Decrypt() on the resulting object; it is also reachable by calling cipher.KeyUnwrap() directly with any ciphertext parameter shorter than 16 bytes. The attack requires no authentication or privileges and is network-accessible, making it trivially exploitable against any application that accepts externally supplied JWE objects and permits key wrapping algorithms (Github Advisory, go-jose Advisory).

Successful exploitation causes the Go application to panic and crash, resulting in a denial of service. There is no confidentiality or integrity impact — the vulnerability exclusively affects availability. Any service that processes externally supplied JWE tokens using key wrapping algorithms (e.g., authentication services, API gateways, identity providers) is at risk of being repeatedly crashed by a single malformed request, potentially causing sustained outages. Downstream projects that embed go-jose — including HashiCorp Vault, Podman, Buildah, Skopeo, containerd, oauth2-proxy, Grafana, and many others — are transitively affected (Github Advisory, Red Hat Bugzilla).

No public exploit code or active in-the-wild exploitation has been reported. The EPSS score is approximately 0.035% (11th percentile), indicating a low near-term exploitation probability (Github Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. However, exploitation is conceptually trivial — an attacker need only craft a JWE object with a KW-type alg header and an empty encrypted_key field and submit it to any vulnerable endpoint that decrypts JWE tokens. No threat actor attribution has been identified. The vulnerability was discovered by Datadog's Security team (go-jose Advisory).

1. Reconnaissance: Identify applications that accept and decrypt JWE tokens using the go-jose library (v2, v3 < 3.0.5, or v4 < 4.1.4), particularly those exposing HTTP endpoints that process encrypted JWT/JWE inputs (e.g., token exchange, decryption APIs).
2. Craft malicious JWE object: Construct a JWE JSON object with the alg header set to a key wrapping algorithm such as A128KW, A192KW, A256KW, RSA-OAEP, or PBES2-HS256+A128KW, and set the encrypted_key field to an empty string ("").

   {
     "protected": "<base64url({\"alg\":\"A128KW\",\"enc\":\"A128CBC-HS256\"})",
     "encrypted_key": "",
     "iv": "<valid_iv>",
     "ciphertext": "<any_value>",
     "tag": "<any_value>"
   }

3. Submit to target: Send the crafted JWE object to the vulnerable application endpoint (e.g., via HTTP POST with Content-Type: application/json or as a Bearer token).
4. Trigger panic: The application calls ParseEncrypted() followed by Decrypt(), which invokes cipher.KeyUnwrap() in key_wrap.go with an empty ciphertext, causing a Go runtime panic and crashing the service.
5. Repeat for sustained DoS: Repeatedly send the malformed JWE to prevent service recovery if the application does not have automatic restart mechanisms (go-jose Advisory, Github Advisory).

• Logs: Go runtime panic stack traces in application logs referencing key_wrap.go and cipher.KeyUnwrap() or runtime: makeslice: len out of range; repeated panic/crash entries in service logs correlated with inbound JWE decryption requests.
• Network: Repeated HTTP requests to JWE decryption or token exchange endpoints containing JWE objects with an empty encrypted_key field (second segment of compact serialization is empty, i.e., header..iv.ciphertext.tag); unusual volume of requests to authentication or token endpoints from a single source IP.
• Process: Unexpected Go application process restarts or crashes; process supervisor (systemd, Kubernetes) logs showing repeated container/service restarts coinciding with inbound network activity.

Upgrade to github.com/go-jose/go-jose/v3 version 3.0.5 or github.com/go-jose/go-jose/v4 version 4.1.4; note that v2 (≤ 2.6.3) has no patch and should be migrated to v3 or v4. If immediate upgrade is not possible, two workarounds are available: (1) ensure the keyAlgorithms list passed to ParseEncrypted() / ParseEncryptedJSON() / ParseEncryptedCompact() does not include any KW-suffixed algorithms, which prevents the vulnerable code path from being reached; or (2) prevalidate incoming JWE objects to confirm the encrypted_key field is non-empty before calling Decrypt() — for Compact Serialization, verify the second .-delimited segment is non-empty (go-jose Advisory, Github Advisory). Red Hat has issued numerous errata (e.g., RHSA-2026:10135, RHSA-2026:19173, RHSA-2026:22937) addressing this in RHEL 9 and 10 packages (Red Hat Bugzilla).

The vulnerability was discovered and responsibly disclosed by Datadog's Security team, credited in the official advisory (go-jose Advisory). Red Hat tracked the issue as high severity and issued a large number of errata across RHEL 9 and 10 product lines, reflecting the broad impact of go-jose as a transitive dependency in the container and cloud-native ecosystem (Red Hat Bugzilla). The vulnerability propagated widely through downstream projects including HashiCorp Vault, Podman, Buildah, Skopeo, containerd, Grafana, oauth2-proxy, and CircleCI Server, prompting patch releases across the ecosystem.