CVE-2026-53939Critical· 9.1▾ AbyssalPoC availableOpenIDC/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-HS3…
▾ Abyssal zone — Critical with a public exploit or in-the-wild use
impact 50.1 · likelihood 0 · exploitation 12
A public proof-of-concept already exists for this vulnerability — see Exploit availability below.
Stakeholder-Specific Vulnerability Categorization from CISA's ADP record at CVE.org: whether exploitation is observed, whether an attack can be automated, and how much of the system is at stake.
Exploit-prediction probability, daily snapshots since Sep 9.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via NVD
0.2%
Last analysed / modified upstream
Exploit / PoC code exists
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).
Refer to the linked advisories for vendor-supplied fixes and affected version ranges.
Field changes observed since this record was first indexed.
Connected by shared product, vendor, weakness, or advisory.
CVE-2026-53938High· 8.2OpenIDC/cjose is a C library implementing the Javascript Object Signing and Encryption (JOSE)
CVE-2026-92912Medium· 6.5AVideo through c3edcc274c389816d434acadac07ee78eaf330c1 uses cryptographically weak uniqid() values for RTMP publish keys in LiveTransmition, reducing key entropy to approximately one million possibilities per creation second
CVE-2026-92913High· 7.4AVideo through commit c3edcc274c389816d434acadac07ee78eaf330c1 uses a cryptographically weak pseudo-random number generator when creating account activation / login pairing codes
CVE-2026-89026Critical· 9.8The Issabel Framework, the web framework supporting Issabel PBX software, before commit b97dbaf contains a hard-coded HS256 JWT signing key in the pbxapi index.php file that is identical across every installation, allowing unauthenticate…
CVE-2026-90945Critical· 9.8Crawlab through 0.6.3 uses a hard-coded HMAC-SHA256 secret for JWT token signing that cannot be overridden via configuration or environment variables
CVE-2026-90510High· 8.3A security vulnerability has been detected in dromara orion-visor up to 2.5.7