OESA-2026-4057 (CVE-2026-53938)
Vulnerability from osv_openeuler – Published: 2026-09-25 01:27 – Updated: 2026-09-25 01:27 – Source websiteImplementation of JOSE for C/C++
Security Fix(es):
OpenIDC/cjose is a C library implementing the Javascript Object Signing and Encryption (JOSE). Prior to version 0.6.2.5, cjose's JWE decryption path for the AES Key Wrap key-management algorithms (alg = A128KW, A192KW, A256KW) does not validate the length of the attacker-supplied encrypted_key (JWE Encrypted Key) before unwrapping it into a fixed-size, heap-allocated Content Encryption Key (CEK) buffer. A remote, unauthenticated attacker who can submit a crafted JWE to an application that decrypts it with an AES-KW symmetric key can trigger an out-of-bounds heap write, corrupting the heap. This leads at minimum to a crash (denial of service) and, depending on the heap layout and allocator, may be leverageable for further memory-corruption impact. cjose_jwe_import() / cjose_jwe_decrypt() are pre-authentication entry points: they parse and process fully attacker-controlled input. Upgrade to cjose 0.6.2.5 to receive a patch. If upgrading is not immediately possible, reject the AES Key Wrap algorithms (A128KW/A192KW/A256KW) for untrusted JWEs at the application layer.(CVE-2026-53938)
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).(CVE-2026-53939)
| URL | Type | |
|---|---|---|
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"cjose-0.6.2.7-1.oe2403sp3.aarch64.rpm",
"cjose-debuginfo-0.6.2.7-1.oe2403sp3.aarch64.rpm",
"cjose-debugsource-0.6.2.7-1.oe2403sp3.aarch64.rpm",
"cjose-devel-0.6.2.7-1.oe2403sp3.aarch64.rpm"
],
"src": [
"cjose-0.6.2.7-1.oe2403sp3.src.rpm"
],
"x86_64": [
"cjose-0.6.2.7-1.oe2403sp3.x86_64.rpm",
"cjose-debuginfo-0.6.2.7-1.oe2403sp3.x86_64.rpm",
"cjose-debugsource-0.6.2.7-1.oe2403sp3.x86_64.rpm",
"cjose-devel-0.6.2.7-1.oe2403sp3.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP3",
"name": "cjose",
"purl": "pkg:rpm/openEuler/cjose\u0026distro=openEuler-24.03-LTS-SP3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.6.2.7-1.oe2403sp3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"ecosystem_specific": {
"aarch64": [
"cjose-0.6.2.7-1.oe2403sp4.aarch64.rpm",
"cjose-debuginfo-0.6.2.7-1.oe2403sp4.aarch64.rpm",
"cjose-debugsource-0.6.2.7-1.oe2403sp4.aarch64.rpm",
"cjose-devel-0.6.2.7-1.oe2403sp4.aarch64.rpm"
],
"src": [
"cjose-0.6.2.7-1.oe2403sp4.src.rpm"
],
"x86_64": [
"cjose-0.6.2.7-1.oe2403sp4.x86_64.rpm",
"cjose-debuginfo-0.6.2.7-1.oe2403sp4.x86_64.rpm",
"cjose-debugsource-0.6.2.7-1.oe2403sp4.x86_64.rpm",
"cjose-devel-0.6.2.7-1.oe2403sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP4",
"name": "cjose",
"purl": "pkg:rpm/openEuler/cjose\u0026distro=openEuler-24.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.6.2.7-1.oe2403sp4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"ecosystem_specific": {
"aarch64": [
"cjose-0.6.2.7-1.oe2003sp4.aarch64.rpm",
"cjose-debuginfo-0.6.2.7-1.oe2003sp4.aarch64.rpm",
"cjose-debugsource-0.6.2.7-1.oe2003sp4.aarch64.rpm",
"cjose-devel-0.6.2.7-1.oe2003sp4.aarch64.rpm"
],
"src": [
"cjose-0.6.2.7-1.oe2003sp4.src.rpm"
],
"x86_64": [
"cjose-0.6.2.7-1.oe2003sp4.x86_64.rpm",
"cjose-debuginfo-0.6.2.7-1.oe2003sp4.x86_64.rpm",
"cjose-debugsource-0.6.2.7-1.oe2003sp4.x86_64.rpm",
"cjose-devel-0.6.2.7-1.oe2003sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:20.03-LTS-SP4",
"name": "cjose",
"purl": "pkg:rpm/openEuler/cjose\u0026distro=openEuler-20.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.6.2.7-1.oe2003sp4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"ecosystem_specific": {
"aarch64": [
"cjose-0.6.2.7-1.oe2203sp4.aarch64.rpm",
"cjose-debuginfo-0.6.2.7-1.oe2203sp4.aarch64.rpm",
"cjose-debugsource-0.6.2.7-1.oe2203sp4.aarch64.rpm",
"cjose-devel-0.6.2.7-1.oe2203sp4.aarch64.rpm"
],
"src": [
"cjose-0.6.2.7-1.oe2203sp4.src.rpm"
],
"x86_64": [
"cjose-0.6.2.7-1.oe2203sp4.x86_64.rpm",
"cjose-debuginfo-0.6.2.7-1.oe2203sp4.x86_64.rpm",
"cjose-debugsource-0.6.2.7-1.oe2203sp4.x86_64.rpm",
"cjose-devel-0.6.2.7-1.oe2203sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP4",
"name": "cjose",
"purl": "pkg:rpm/openEuler/cjose\u0026distro=openEuler-22.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.6.2.7-1.oe2203sp4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"ecosystem_specific": {
"aarch64": [
"cjose-0.6.2.7-1.oe2403sp1.aarch64.rpm",
"cjose-debuginfo-0.6.2.7-1.oe2403sp1.aarch64.rpm",
"cjose-debugsource-0.6.2.7-1.oe2403sp1.aarch64.rpm",
"cjose-devel-0.6.2.7-1.oe2403sp1.aarch64.rpm"
],
"src": [
"cjose-0.6.2.7-1.oe2403sp1.src.rpm"
],
"x86_64": [
"cjose-0.6.2.7-1.oe2403sp1.x86_64.rpm",
"cjose-debuginfo-0.6.2.7-1.oe2403sp1.x86_64.rpm",
"cjose-debugsource-0.6.2.7-1.oe2403sp1.x86_64.rpm",
"cjose-devel-0.6.2.7-1.oe2403sp1.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP1",
"name": "cjose",
"purl": "pkg:rpm/openEuler/cjose\u0026distro=openEuler-24.03-LTS-SP1"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.6.2.7-1.oe2403sp1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "Critical"
},
"details": "Implementation of JOSE for C/C++\r\n\r\nSecurity Fix(es):\n\nOpenIDC/cjose is a C library implementing the Javascript Object Signing and Encryption (JOSE). Prior to version 0.6.2.5, cjose\u0026apos;s JWE decryption path for the AES Key Wrap key-management algorithms (`alg` = `A128KW`, `A192KW`, `A256KW`) does not validate the length of the attacker-supplied `encrypted_key` (JWE Encrypted Key) before unwrapping it into a fixed-size, heap-allocated Content Encryption Key (CEK) buffer. A remote, unauthenticated attacker who can submit a crafted JWE to an application that decrypts it with an AES-KW symmetric key can trigger an out-of-bounds heap write, corrupting the heap. This leads at minimum to a crash (denial of service) and, depending on the heap layout and allocator, may be leverageable for further memory-corruption impact. `cjose_jwe_import()` / `cjose_jwe_decrypt()` are pre-authentication entry points: they parse and process fully attacker-controlled input. Upgrade to cjose 0.6.2.5 to receive a patch. If upgrading is not immediately possible, reject the AES Key Wrap algorithms (`A128KW`/`A192KW`/`A256KW`) for untrusted JWEs at the application layer.(CVE-2026-53938)\n\nOpenIDC/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).(CVE-2026-53939)",
"id": "OESA-2026-4057",
"modified": "2026-09-25T01:27:46Z",
"published": "2026-09-25T01:27:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4057"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53938"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53939"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "cjose security update",
"upstream": [
"CVE-2026-53938",
"CVE-2026-53939"
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.