Hi, devel/cjose (0.6.1pl20260427) is affected by two real security issues, both already fixed upstream and both already backported for Debian's LTS branch:
CVE-2026-53938: _cjose_jwe_decrypt_ek_aes_kw() passes the attacker-controlled encrypted_key straight to AES_unwrap_key() without checking its length against the fixed-size jwe->cek buffer it unwraps into. A crafted JWE with an oversized encrypted_key segment for an AES key wrap algorithm triggers an out-of-bounds heap write - at minimum a remote, unauthenticated DoS. Fix adds the length check RFC 3394 already implies (wrapped key length is always the plaintext CEK length plus 8 bytes) before unwrapping. CVE-2026-53939: _cjose_jwe_set_cek_aes_cbc() passes the wrong boolean to _cjose_jwe_malloc()'s "zero" parameter (inverted), so a freshly generated CEK for AES-CBC-HMAC content encryption is always zero-filled instead of randomly generated. Every JWE produced with an AES-CBC-HMAC enc algorithm ends up encrypted and authenticated under the same fixed, publicly known key. Both confirmed against the actual upstream fix commits (OpenIDC/cjose@8c51d2452, OpenIDC/cjose@2a6e5bd96) and verified against this port's own snapshot - the vulnerable functions are identical between OpenIDC's and cisco's forks. Built and tested clean on 7.9, full regression suite passes (1/1). Index: patches/patch-src_jwe_c --- /dev/null +++ patches/patch-src_jwe_c @@ -0,0 +1,49 @@ +Fix two security issues in JWE handling. + +CVE-2026-53938: _cjose_jwe_decrypt_ek_aes_kw() passed the +attacker-controlled encrypted_key straight to AES_unwrap_key() +without checking its length against the fixed-size jwe->cek buffer +it unwraps into. A crafted JWE with an oversized encrypted_key +segment for an AES key wrap algorithm (A128KW/A192KW/A256KW) +triggers an out-of-bounds heap write, which is at minimum a remote, +unauthenticated denial of service. Add the length check RFC 3394 +already implies (wrapped key length is always the plaintext CEK +length plus 8 bytes) before unwrapping. +https://github.com/OpenIDC/cjose/commit/8c51d2452 + +CVE-2026-53939: _cjose_jwe_set_cek_aes_cbc() passed the wrong boolean +to _cjose_jwe_malloc()'s "zero" parameter (inverted), so a freshly +generated CEK for AES-CBC-HMAC content encryption was always +zero-filled instead of randomly generated. Every JWE produced with +an AES-CBC-HMAC enc algorithm was therefore encrypted and +authenticated under the same fixed, publicly known key. +https://github.com/OpenIDC/cjose/commit/2a6e5bd96 + +Index: src/jwe.c +--- src/jwe.c.orig ++++ src/jwe.c +@@ -459,7 +459,7 @@ + { + // allocate memory for the CEK and fill with random bytes or 0's + _cjose_release_cek(&jwe->cek, jwe->cek_len); +- if (!_cjose_jwe_malloc(keysize, !random, &jwe->cek, err)) ++ if (!_cjose_jwe_malloc(keysize, random, &jwe->cek, err)) + { + return false; + } +@@ -588,6 +588,15 @@ + return false; + } + ++ // the wrapped key (RFC 3394) is always the plaintext CEK length plus 8 bytes; ++ // enforce this before calling AES_unwrap_key, which would otherwise copy the ++ // attacker-controlled encrypted_key into the fixed-size jwe->cek buffer ++ if (recipient->enc_key.raw_len != jwe->cek_len + 8) ++ { ++ CJOSE_ERROR(err, CJOSE_ERR_INVALID_ARG); ++ return false; ++ } ++ + // AES unwrap the CEK in to jwe->cek + int len = AES_unwrap_key(&akey, (const unsigned char *)NULL, jwe->cek, (const unsigned char *)recipient->enc_key.raw, + recipient->enc_key.raw_len); OK? Ivo
