CVE-2026-53939: OpenIDC/cjose uses all-zero Content Encryption Key for AES-CBC-HMAC JWE encryption
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 cjosejwesetcekaescbc() generating the CEK from RANDbytes. A regression test asserts that the encryptedkey 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).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
OpenIDC/cjoseto a version that resolves this vulnerability.Fixed in 0.6.2.6 - Configuration
For new JWE ciphertexts, use AES-GCM `enc` (`A128GCM` / `A192GCM` / `A256GCM`) instead of AES-CBC-HMAC (`A128CBC-HS256`, `A192CBC-HS384`, `A256CBC-HS512`).
OpenIDC/cjose JWE enc (content-encryption algorithm) for AES-CBC-HMAC = A128GCM / A192GCM / A256GCM - Configuration
For new JWE ciphertexts, use `alg=dir` together with a caller-supplied, non-zero random content-encryption key (CEK) instead of relying on a fresh CEK generated by cjose for the affected AES-CBC-HMAC `enc`.
OpenIDC/cjose JWE alg with AES-CBC-HMAC when CEK must be caller-supplied = dir - Compensating control
Until upgrading, avoid using cjose for JWE encryption with the affected algorithm pair: AES-CBC-HMAC `enc` (`A128CBC-HS256`, `A192CBC-HS384`, `A256CBC-HS512`) combined with any key-management algorithm that generates a fresh CEK.
- Operational
Re-encrypt data previously encrypted with cjose using the affected AES-CBC-HMAC algorithm pair (regardless of later mitigations), and rotate any secrets that may have been exposed in the compromised JWE.
Event History
Frequently Asked Questions
Which JWE encryption operations are affected?
Affected operations use cjose versions 0.6.1 through 0.6.2.5 with A128CBC-HS256, A192CBC-HS384, or A256CBC-HS512 as the enc algorithm and a key-management algorithm that generates a fresh CEK. The issue applies when cjose performs the encryption under that algorithm combination.
What does an attacker need to exploit this issue?
An attacker only needs to obtain an affected JWE. Because the encryption and authentication key is fixed to publicly known zero bytes, they can recover its plaintext and forge or modify its contents.
How can teams mitigate the issue before upgrading?
For new ciphertexts, use an AES-GCM enc value (A128GCM, A192GCM, or A256GCM), use alg=dir with a caller-supplied CEK, or avoid cjose JWE encryption for the affected algorithm pair. These mitigations apply only to newly created ciphertexts.
What version contains the fix, and how can deployments be identified?
The issue is fixed in cjose 0.6.2.6, which generates the AES-CBC-HMAC CEK using RAND_bytes. Review the deployed cjose version and JWE configuration for the affected AES-CBC-HMAC enc values combined with key management that creates a fresh CEK.