UBUNTU-CVE-2026-53939 (CVE-2026-53939)
Vulnerability from osv_ubuntu – Published: 2026-09-09 00:17 – Updated: 2026-09-16 11:36 – Source websiteOpenIDC/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).
| URL | Type | |
|---|---|---|
{
"affected": [
{
"ecosystem_specific": {
"binaries": [
{
"binary_name": "libcjose0",
"binary_version": "0.6.0+dfsg1-1ubuntu0.1~esm1"
}
]
},
"package": {
"ecosystem": "Ubuntu:Pro:18.04:LTS",
"name": "cjose",
"purl": "pkg:deb/ubuntu/cjose@0.6.0+dfsg1-1ubuntu0.1~esm1?arch=source\u0026distro=esm-apps/bionic"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.4.1-3ubuntu1",
"0.5.1+dfsg1-1",
"0.5.1+dfsg1-2",
"0.5.1+dfsg1-2build1",
"0.6.0+dfsg1-1",
"0.6.0+dfsg1-1ubuntu0.1~esm1"
]
},
{
"ecosystem_specific": {
"binaries": [
{
"binary_name": "libcjose0",
"binary_version": "0.6.1+dfsg1-1ubuntu0.1"
}
]
},
"package": {
"ecosystem": "Ubuntu:20.04:LTS",
"name": "cjose",
"purl": "pkg:deb/ubuntu/cjose@0.6.1+dfsg1-1ubuntu0.1?arch=source\u0026distro=focal"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.6.1+dfsg1-1",
"0.6.1+dfsg1-1ubuntu0.1"
]
},
{
"ecosystem_specific": {
"binaries": [
{
"binary_name": "libcjose0",
"binary_version": "0.6.1+dfsg1-3ubuntu1.1"
}
]
},
"package": {
"ecosystem": "Ubuntu:22.04:LTS",
"name": "cjose",
"purl": "pkg:deb/ubuntu/cjose@0.6.1+dfsg1-3ubuntu1.1?arch=source\u0026distro=jammy"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.6.1+dfsg1-1",
"0.6.1+dfsg1-3",
"0.6.1+dfsg1-3ubuntu1",
"0.6.1+dfsg1-3ubuntu1.1"
]
},
{
"ecosystem_specific": {
"binaries": [
{
"binary_name": "libcjose0",
"binary_version": "0.6.2.2-1build3"
}
]
},
"package": {
"ecosystem": "Ubuntu:24.04:LTS",
"name": "cjose",
"purl": "pkg:deb/ubuntu/cjose@0.6.2.2-1build3?arch=source\u0026distro=noble"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.6.2.2-1",
"0.6.2.2-1build1",
"0.6.2.2-1build2",
"0.6.2.2-1build3"
]
},
{
"ecosystem_specific": {
"binaries": [
{
"binary_name": "libcjose0",
"binary_version": "0.6.2.4-1"
}
]
},
"package": {
"ecosystem": "Ubuntu:26.04:LTS",
"name": "cjose",
"purl": "pkg:deb/ubuntu/cjose@0.6.2.4-1?arch=source\u0026distro=resolute"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.6.2.3-1",
"0.6.2.4-1"
]
}
],
"aliases": [],
"details": "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).",
"id": "UBUNTU-CVE-2026-53939",
"modified": "2026-09-16T11:36:38Z",
"published": "2026-09-09T00:17:00Z",
"references": [
{
"type": "REPORT",
"url": "https://ubuntu.com/security/CVE-2026-53939"
},
{
"type": "REPORT",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53939"
}
],
"related": [],
"schema_version": "1.7.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "medium",
"type": "Ubuntu"
}
],
"upstream": [
"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.