CVE-2026-53939

CriticalCVSS 9.1

Published: 09/09/2026(UTC)Translated: 09/09/2026(UTC)NVD NIST

Summary

In cjose versions 0.6.1 through 0.6.2.5, when encrypting a JWE using AES-CBC-HMAC content-encryption algorithms (A128CBC-HS256, A192CBC-HS384, A256CBC-HS512) with any key-management algorithm that generates a fresh content-encryption key (CEK), the CEK is all zero bytes instead of being randomly generated. The resulting JWE is encrypted and authenticated under a fixed, publicly known key, allowing anyone who obtains the JWE to recover plaintext and forge or modify content. Fixed in 0.6.2.6 by generating CEK from RAND_bytes.

Risk Assessment

Data encrypted with affected cjose versions is vulnerable to disclosure and tampering, potentially leading to confidentiality and integrity breaches of transmitted information.

Recommendation

Upgrade cjose to 0.6.2.6 or later. Until then, for new data use AES-GCM algorithms, use alg=dir with a caller-supplied CEK, or avoid using cjose for JWE encryption with affected algorithm pairs. Data already encrypted under the zero key should be re-encrypted and secrets rotated.

Other vulnerabilities in cjose

CVE-2026-53938High
The cjose C library implementing JOSE has a vulnerability in the JWE decryption path for AES Key Wrap algorithms (A128KW, A192KW, A256KW) due to lack of validation of the attacker-supplied encrypted_key length before unwrapping into a fixed-size heap buffer. A remote unauthenticated attacker can trigger an out-of-bounds heap write, leading at least to a crash (DoS) and potentially to further memory corruption. The entry points cjose_jwe_import() and cjose_jwe_decrypt() are pre-authentication and process fully attacker-controlled input.

Original NVD description (English source)

OpenIDC/cjose is a C library implementing the Javascript Object Signing and Encryption (JOSE). In versions 0.6.1 through 0.6.2.5, when cjose encrypts a JWE using an AES-CBC-HMAC content-encryption algorithm (`A128CBC-HS256`, `A192CBC-HS384`, or `A256CBC-HS512`) together with any key-management algorithm that generates a fresh content-encryption key (CEK), the CEK is all zero bytes instead of being randomly generated. The resulting JWE is therefore encrypted and authenticated under a fixed, publicly known key, so anyone who obtains the JWE can recover the plaintext and forge or modify the content. This is fixed in version 0.6.2.6 by `_cjose_jwe_set_cek_aes_cbc()` generating the CEK from `RAND_bytes`. A regression test asserts that the `encrypted_key` differs across two encryptions for each AES-CBC-HMAC variant. Until upgrading, for data encrypted with cjose, three options are available. Use an AES-GCM `enc` (`A128GCM` / `A192GCM` / `A256GCM`) instead of an AES-CBC-HMAC `enc`, use `alg=dir` with a caller-supplied CEK, or avoid using cjose for JWE encryption with the affected algorithm pair. These are mitigations for new ciphertexts only; data already encrypted under the zero key remains compromised and should be re-encrypted (and any secrets it contained rotated).