CVE-2026-116585

What it actually does

Decrypting attacker-supplied JWE ciphertext using A128CBC-HS256, A192CBC-HS384, or A256CBC-HS512 passes an empty buffer to CBC-HMAC unpadding, allowing an out-of-bounds index operation that triggers a Go panic.

Why it matters to the business

Applications accepting untrusted JWE tokens can be crashed on demand, producing denial-of-service conditions that interrupt services until the process restarts.

How an attack unfolds

An attacker generates a JWE object containing a zero-length ciphertext protected by one of the three CBC-HMAC algorithms, submits it to any decryption routine, and the library panics before returning a result.

How to fix it

Upgrade github.com/go-jose/go-jose/v4 to version 4.1.5 or later; if pinned to an earlier major version, apply the equivalent patch that rejects empty ciphertext buffers before CBC-HMAC processing.

How to confirm the fix worked

Confirm the go-jose module version is at least 4.1.5, then attempt decryption of a crafted zero-length JWE under the affected algorithms and verify the operation returns an error instead of panicking.

Typical attack path

1. Identify an endpoint or API that decrypts attacker-controlled JWE objects
2. Construct a JWE with empty ciphertext using A128CBC-HS256, A192CBC-HS384, or A256CBC-HS512
3. Deliver the token to the decryption code path
4. Observe process termination due to unhandled panic

How to detect it

Search application logs and crash reports for Go runtime panics originating from CBC-HMAC unpadding or jose ciphertext handling; correlate spikes in decryption errors with unusual JWE token sizes or algorithm identifiers.

What your security team should do

• Immediately update all Go modules that depend on go-jose to 4.1.5
• Audit code paths that call Decrypt or ParseEncrypted on untrusted input
• Add runtime guards or circuit breakers around JWE decryption to limit blast radius of crashes
• Monitor dependency scanners for any transitive consumers of the vulnerable versions