CVE-2026-53939

cjose, the OpenIDC C library implementing Javascript Object Signing and Encryption (JOSE), generates an all-zero content-encryption key (CEK) instead of a random one when encrypting a JWE with an AES-CBC-HMAC content-encryption algorithm (A128CBC-HS256, A192CBC-HS384, or A256CBC-HS512) together with any key-management algorithm that generates a fresh CEK. Because the CEK is fixed and publicly known, the resulting JWE is encrypted and authenticated under a known key, so anyone who obtains the ciphertext can recover the plaintext and forge or modify its content without possessing any secret. Applications and services using cjose versions 0.6.1 through 0.6.2.5 for JWE encryption with these algorithm combinations are affected, and any data already encrypted this way remains readable and forgeable by anyone holding the JWE. The flaw is fixed in version 0.6.2.6, where the CEK is generated from RAND_bytes and covered by a regression test; there is no public proof-of-concept, no CISA KEV entry, and no known in-the-wild exploitation, with EPSS estimating only a 0.2% probability of exploitation in the next 30 days.

What to do: Upgrade to cjose 0.6.2.6, where the CEK is randomly generated. Until then, for new ciphertexts use an AES-GCM enc (A128GCM/A192GCM/A256GCM), use alg=dir with a caller-supplied CEK, or avoid cjose for JWE encryption with an AES-CBC-HMAC enc paired with fresh-CEK key management. Audit existing cjose-encrypted data for the affected combinations: anything already encrypted under the zero key is compromised, so re-encrypt it and rotate any secrets it contained.