OpenIDC/cjose uses all-zero Content Encryption Key for AES-CBC-HMAC JWE encryption
Summary
| CVE | CVE-2026-53939 |
|---|---|
| State | PUBLISHED |
| Assigner | GitHub_M |
| Source Priority | CVE Program / NVD first with legacy fallback |
| Published | 2026-09-09 00:17:31 UTC |
| Updated | 2026-09-10 19:57:48 UTC |
| Description | 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). |
Risk And Classification
Primary CVSS: v3.1 9.1 CRITICAL from [email protected]
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS: 0.001960000 probability, percentile 0.094820000 (date 2026-09-09)
Problem Types: CWE-321 | CWE-330 | CWE-321 CWE-321: Use of Hard-coded Cryptographic Key | CWE-330 CWE-330: Use of Insufficiently Random Values
| Version | Source | Type | Score | Severity | Vector |
|---|---|---|---|---|---|
| 3.1 | [email protected] | Secondary | 9.1 | CRITICAL | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N |
| 3.1 | CNA | DECLARED | 9.1 | CRITICAL | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N |
CVSS v3.1 Breakdown
Attack Vector
NetworkAttack Complexity
LowPrivileges Required
NoneUser Interaction
NoneScope
UnchangedConfidentiality
HighIntegrity
HighAvailability
NoneCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Vendor Declared Affected Products
References
| Reference | Source | Link | Tags |
|---|---|---|---|
| github.com/OpenIDC/cjose/releases/tag/v0.6.2.6 | [email protected] | github.com | |
| github.com/OpenIDC/cjose/security/advisories/GHSA-f6wf-pqg3-6wqq | 134c704f-9b21-4f2e-91b3-4a467353bcc0 | github.com | |
| github.com/OpenIDC/cjose/commit/2a6e5bd969fa20059fb00913fb9f57d77ea6a4d9 | [email protected] | github.com | |
| CVE Program record | CVE.ORG | www.cve.org | canonical |
| NVD vulnerability detail | NVD | nvd.nist.gov | canonical, analysis |
No vendor comments have been submitted for this CVE.
There are currently no legacy QID mappings associated with this CVE.