An update for cjose is now available for openEuler-24.03-LTS-SP3,openEuler-24.03-LTS-SP4,openEuler-20.03-LTS-SP4,openEuler-22.03-LTS-SP4,openEuler-24.03-LTS-SP1 Security Advisory openeuler-security@openeuler.org openEuler security committee openEuler-SA-2026-4057 Final 1.0 1.0 2026-09-25 Initial 2026-09-25 2026-09-25 openEuler SA Tool V1.0 2026-09-25 cjose security update An update for cjose is now available for openEuler-24.03-LTS-SP3,openEuler-24.03-LTS-SP4,openEuler-20.03-LTS-SP4,openEuler-22.03-LTS-SP4,openEuler-24.03-LTS-SP1 Implementation 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) An update for cjose is now available for openEuler-24.03-LTS-SP3,openEuler-24.03-LTS-SP4,openEuler-20.03-LTS-SP4,openEuler-22.03-LTS-SP4,openEuler-24.03-LTS-SP1. openEuler Security has rated this update as having a security impact of critical. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section. Critical cjose https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4057 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-53938 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-53939 https://nvd.nist.gov/vuln/detail/CVE-2026-53938 https://nvd.nist.gov/vuln/detail/CVE-2026-53939 openEuler-24.03-LTS-SP3 openEuler-24.03-LTS-SP4 openEuler-20.03-LTS-SP4 openEuler-22.03-LTS-SP4 openEuler-24.03-LTS-SP1 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 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 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 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 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 cjose-0.6.2.7-1.oe2403sp3.src.rpm cjose-0.6.2.7-1.oe2403sp4.src.rpm cjose-0.6.2.7-1.oe2003sp4.src.rpm cjose-0.6.2.7-1.oe2203sp4.src.rpm cjose-0.6.2.7-1.oe2403sp1.src.rpm 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 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 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 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 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 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. 2026-09-25 CVE-2026-53938 openEuler-24.03-LTS-SP3 openEuler-24.03-LTS-SP4 openEuler-20.03-LTS-SP4 openEuler-22.03-LTS-SP4 openEuler-24.03-LTS-SP1 High 8.2 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H cjose security update 2026-09-25 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4057 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). 2026-09-25 CVE-2026-53939 openEuler-24.03-LTS-SP3 openEuler-24.03-LTS-SP4 openEuler-20.03-LTS-SP4 openEuler-22.03-LTS-SP4 openEuler-24.03-LTS-SP1 Critical 9.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N cjose security update 2026-09-25 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4057