CVE-2026-34986

What it actually does

This vulnerability is a remotely triggerable denial-of-service condition in Go JOSE JWE decryption. When an application parses an attacker-controlled JWE using ParseEncrypted(), ParseEncryptedJSON(), or ParseEncryptedCompact() and then calls Decrypt(), a malformed object can cause a Go panic if the JWE alg value is a key-wrapping algorithm ending in KW, except A128GCMKW, A192GCMKW, and A256GCMKW, and the encrypted_key value is empty or too short. The panic occurs in cipher.KeyUnwrap() in key_wrap.go when it attempts to allocate a slice using a zero or negative length derived from encrypted_key length. If the panic is not recovered, the application process or request handler can crash, causing service disruption. Applications are only exposed when they accept affected key-wrapping algorithms during parsing or call cipher.KeyUnwrap() directly with ciphertext shorter than 16 bytes.

Why it matters to the business

An unauthenticated attacker may be able to crash services that process encrypted tokens or JWE messages, causing authentication, API, session, or message-processing outages. The CVSS availability impact is high, but current exploitation signals are low: it is not in the CISA KEV catalog, is not known to be ransomware-associated, has no reported mature public exploitation, and has a low, flat EPSS score of 0.00651 over 30 days. Because Go JOSE is a reusable library, the operational risk depends on where it is embedded; internet-facing services that decrypt externally supplied JWE content should be prioritized even if no widespread exploitation is currently reported.

How an attack unfolds

An attacker identifies an endpoint or workflow that accepts encrypted JWE/JWT-style input and uses the vulnerable Go JOSE library to parse and decrypt it. The attacker crafts a JWE whose alg header specifies an affected AES key-wrap style algorithm such as A128KW, A192KW, A256KW, PBES2-HS256+A128KW, PBES2-HS384+A192KW, or PBES2-HS512+A256KW, while setting the encrypted_key component to an empty value or otherwise causing a ciphertext shorter than 16 bytes to reach KeyUnwrap(). If the application includes that algorithm in the accepted key algorithm list, parsing succeeds and Decrypt() reaches the vulnerable key unwrap path. The library panics during slice allocation; if the application does not recover the panic safely, the process, worker, or request path terminates. Repeated requests can create sustained denial of service.

How to fix it

Upgrade Go JOSE to a fixed release: v4 users should upgrade to 4.1.4 or later, and v3 users should upgrade to 3.0.5 or later. Regenerate and redeploy binaries or containers that statically include the vulnerable dependency; updating the module file alone is not sufficient until affected applications are rebuilt and released. If immediate upgrade is not possible, reduce exposure by rejecting JWE messages that use affected key-wrapping algorithms, removing unused KW algorithms from the accepted key algorithm list passed to parse functions, validating that encrypted_key is present and at least the required key-wrap length before decryption, and adding defensive panic recovery around untrusted token processing so a malformed token cannot terminate the service. Do not rely solely on restart policies, because an attacker can repeatedly trigger the crash.

How to confirm the fix worked

Confirm dependency versions with Go module tooling such as go list -m all, go version -m <binary>, SBOM scans, or dependency lockfile review, and verify that github.com/go-jose/go-jose/v4 is 4.1.4 or later or the v3 module line is 3.0.5 or later. Confirm deployed artifacts were rebuilt after the dependency update. Review application code for ParseEncrypted(), ParseEncryptedJSON(), ParseEncryptedCompact(), Decrypt(), and direct cipher.KeyUnwrap() usage, and verify accepted key algorithms do not include unused affected KW algorithms. Where safe in a test environment, send a malformed JWE using an affected KW alg and empty encrypted_key and confirm the service returns a controlled error rather than panicking or restarting. Monitor production crash, panic, and restart metrics after rollout to confirm the issue is no longer reproducible.

Typical attack path

1. Discover an application endpoint or protocol path that accepts JWE/JWT encrypted input from untrusted users.
2. Craft a compact or JSON-serialized JWE with an affected key-wrapping alg value ending in KW, excluding A128GCMKW, A192GCMKW, and A256GCMKW.
3. Set the encrypted_key field/component to empty or shorter than the minimum required key-wrap ciphertext length.
4. Submit the malformed JWE to the target application.
5. Trigger ParseEncrypted(), ParseEncryptedJSON(), or ParseEncryptedCompact() followed by Decrypt(), or a direct cipher.KeyUnwrap() call.
6. Cause a Go panic in key_wrap.go, potentially crashing the process or disrupting request handling.
7. Repeat requests to sustain service unavailability if restart or recovery mechanisms bring the service back online.

How to detect it

Look for evidence of prior exploitation in application logs, reverse proxy logs, API gateway logs, container logs, crash dumps, panic traces, and process supervisor or orchestration events. Useful signals include repeated HTTP 4xx/5xx responses followed by process restarts, Go panic messages referencing slice length allocation, stack traces involving go-jose key_wrap.go or cipher.KeyUnwrap(), and bursts of requests carrying compact JWE values or JSON JWE bodies with alg values such as A128KW, A192KW, A256KW, PBES2-HS256+A128KW, PBES2-HS384+A192KW, or PBES2-HS512+A256KW and an empty encrypted_key. For compact JWE, an empty encrypted_key appears as two adjacent periods after the protected header segment, producing a five-part token pattern like <protected>..<iv>.<ciphertext>.<tag>. For JSON serialization, look for "encrypted_key":"" together with affected alg headers. Correlate suspected malformed JWE requests with application panics, container restarts, Kubernetes CrashLoopBackOff events, systemd restarts, or load balancer health-check failures. Because no specific threat actors or active campaigns are currently reported for this issue, focus detection on exploit behavior and crash artifacts rather than actor-specific infrastructure.

• panic: runtime error: makeslice: len out of range
• panic: runtime error: makeslice: len out of range
• cipher.KeyUnwrap
• key_wrap.go
• ParseEncrypted
• ParseEncryptedJSON
• ParseEncryptedCompact
• Decrypt
• "encrypted_key":""
• "alg":"A128KW"
• "alg":"A192KW"
• "alg":"A256KW"
• "alg":"PBES2-HS256+A128KW"
• "alg":"PBES2-HS384+A192KW"
• "alg":"PBES2-HS512+A256KW"
• alg=A128KW
• alg=A192KW
• alg=A256KW
• PBES2-HS256+A128KW
• PBES2-HS384+A192KW
• PBES2-HS512+A256KW
• CrashLoopBackOff
• Back-off restarting failed container
• systemd: Scheduled restart job
• github.com/go-jose/go-jose
• github.com/go-jose/go-jose/v4

What your security team should do

• Inventory applications, containers, and binaries that include Go JOSE, especially services that process externally supplied JWE, JWS, JWT, or encrypted authentication/session tokens.
• Prioritize internet-facing and authentication-adjacent services for upgrade to Go JOSE 4.1.4+ or 3.0.5+.
• Rebuild and redeploy affected Go binaries after dependency updates; verify deployed binaries, not just source manifests.
• Temporarily disable unused key-wrapping algorithms ending in KW in accepted algorithm lists until all affected services are patched.
• Add input validation and panic recovery around untrusted token decryption paths to limit denial-of-service blast radius.
• Search logs and crash telemetry for Go panic stack traces involving key_wrap.go, KeyUnwrap(), ParseEncrypted(), or Decrypt().
• Create detection rules for malformed JWE inputs containing affected alg values with an empty encrypted_key component.
• Track advisories for any change in exploit maturity, KEV status, or threat actor reporting, but treat exposed token-decryption paths as patch-priority despite currently low EPSS.