CVE-2026-53939 in cjose
Summary
by MITRE • 09/09/2026
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).
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified in OpenIDC/cjose versions 0.6.1 through 0.6.2.5 represents a critical failure in cryptographic random number generation within the Javascript Object Signing and Encryption implementation. Specifically, when utilizing AES-CBC-HMAC content-encryption algorithms such as A128CBC-HS256, A192CBC-HS384, or A256CBC-HS512 combined with key-management algorithms that are designed to generate a fresh Content Encryption Key for each encryption operation, the library erroneously initializes this CEK with all zero bytes rather than deriving it from a cryptographically secure random source. This defect fundamentally undermines the security model of JWE encryption because the confidentiality and integrity protections provided by these algorithms rely entirely on the secrecy and unpredictability of the key used to encrypt the payload. By producing a fixed, publicly known key composed entirely of zeros, the library effectively removes any cryptographic barrier against unauthorized access or modification of the encrypted data.
From an operational perspective, this flaw allows any adversary who obtains the JWE ciphertext to decrypt it without possessing any secret material other than knowledge of the algorithm used. Since the CEK is constant and predictable across all encryption operations performed by vulnerable versions of cjose under these specific conditions, attackers can recover plaintext content with ease. Furthermore, because HMAC authentication tags are also generated using this compromised key state or related derived values depending on implementation specifics, an attacker may not only read sensitive information but also forge valid JWE tokens or modify existing ciphertexts in a way that passes integrity verification checks. This breaks the core guarantees of confidentiality and authenticity expected from JOSE standards, potentially leading to severe data breaches, authentication bypasses, or injection attacks if these encrypted payloads are used for session management or secure communication channels.
This issue aligns with CWE-330: Use of Insufficiently Random Values, as the root cause lies in the failure to utilize a proper entropy source when generating cryptographic keys. In terms of attack vectors and techniques, this vulnerability facilitates attacks categorized under MITRE ATT&CK T1528: Steal Application Access Token or similar data exfiltration tactics where encrypted tokens are intercepted and decrypted due to weak key generation practices. The impact is particularly severe in environments relying on JWE for securing sensitive API payloads, OAuth token exchanges, or secure messaging protocols where the assumption of unique per-message keys is standard practice. Organizations utilizing these versions must recognize that any data encrypted during this window remains exposed indefinitely unless remediated through re-encryption procedures.
To mitigate this risk immediately, developers should upgrade to version 0.6.2.6 and later, which corrects the flaw by ensuring that `_cjose_jwe_set_cek_aes_cbc()` generates the CEK using `RAND_bytes`, thereby restoring reliance on cryptographically secure random number generation. For systems unable to upgrade instantly, alternative mitigation strategies include switching to AES-GCM based content-encryption algorithms such as A128GCM, A192GCM, or A256GCM, which do not suffer from this specific implementation bug in the affected versions. Another viable approach is using direct key agreement with `alg=dir` while supplying a caller-managed CEK that is properly randomized by external logic rather than relying on cjose to generate it. It is imperative to avoid using cjose for JWE encryption involving AES-CBC-HMAC algorithms until these mitigations are applied or the library is updated.
Finally, organizations must conduct an audit of all data encrypted with affected versions of cjose under the specified algorithm combinations. Since the vulnerability affects historical ciphertexts as well as new ones, any secrets contained within previously encrypted payloads should be considered compromised and rotated immediately. Re-encrypting existing data using a secure key generation method is essential to restore confidentiality guarantees. This incident highlights the critical importance of rigorous testing for cryptographic primitives in security libraries, particularly regarding random number generator integration, and underscores the need for continuous monitoring of library updates that address foundational crypto failures.