Re: git: 85adc9fdc0e0 - main - security/vuxml: Add devel/cjose vulnerabilities
- In reply to: Dan Langille: "Re: git: 85adc9fdc0e0 - main - security/vuxml: Add devel/cjose vulnerabilities"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 15 Sep 2026 20:33:25 UTC
On Tue, Sep 15, 2026 at 6:23 PM Dan Langille <dan@langille.org> wrote: > On Mon, Sep 14, 2026, at 12:43 PM, Fernando Apesteguía wrote: > > The branch main has been updated by fernape: > > > > URL: > > > https://cgit.FreeBSD.org/ports/commit/?id=85adc9fdc0e0535ead4b6b5368df074d96c17ae2 > > > > commit 85adc9fdc0e0535ead4b6b5368df074d96c17ae2 > > Author: Fernando Apesteguía <fernape@FreeBSD.org> > > AuthorDate: 2026-09-14 16:41:03 +0000 > > Commit: Fernando Apesteguía <fernape@FreeBSD.org> > > CommitDate: 2026-09-14 16:41:03 +0000 > > > > security/vuxml: Add devel/cjose vulnerabilities > > > > * CVE-2026-53938 > > * CVE-2026-53939 > > > > PR: 298458 > > Reported by: Ivo Marino <ivo.marino+freebsd@gmail.com> > > --- > > security/vuxml/vuln/2026.xml | 99 > ++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 99 insertions(+) > > > > diff --git a/security/vuxml/vuln/2026.xml b/security/vuxml/vuln/2026.xml > > index 6a4f629c86fd..e11e5f033ccc 100644 > > --- a/security/vuxml/vuln/2026.xml > > +++ b/security/vuxml/vuln/2026.xml > > @@ -1,3 +1,102 @@ > > + <vuln vid="3a38fdda-b05a-11f1-9369-b42e991fc52e"> > > + <topic>cjose: Use of Hard-coded Cryptographic Key</topic> > > + <affects> > > + <package> > > + <name>cjose</name> > > + <range><lt>0.6.2.6</lt></range> > > + </package> > > + </affects> > > + <description> > > + <body xmlns="http://www.w3.org/1999/xhtml"> > > + <p> > https://github.com/OpenIDC/cjose/security/advisories/GHSA-f6wf-pqg3-6wqq > > reports:</p> > > + <blockquote > > cite=" > https://github.com/OpenIDC/cjose/security/advisories/GHSA-f6wf-pqg3-6wqq"> > > + <p> > > + 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). > > + </p> > > + </blockquote> > > + </body> > > + </description> > > + <references> > > + <cvename>CVE-2026-53939</cvename> > > + <url>https://cveawg.mitre.org/api/cve/CVE-2026-53939</url> > > + </references> > > + <dates> > > + <discovery>2026-09-08</discovery> > > + <entry>2026-09-14</entry> > > + </dates> > > + </vuln> > > + > > + <vuln vid="35b3a492-b05a-11f1-9369-b42e991fc52e"> > > + <topic>cjose: Heap-based Buffer Overflow</topic> > > + <affects> > > + <package> > > + <name>cjose</name> > > + <range><lt>&lt; 0.6.2.5</lt></range> > > I believe that's not valid. The embedded HTML needs to be removed AFAIK. > Sorry. Should be fixed now. Thanks for the heads up! > > Granted, `make validate` does not reveal it. But parsing it is a problem > (or so FreshPorts tells me. > > [18:20 mydev dvl /usr/ports/security/vuxml] % sudo make validate > /bin/sh /usr/ports/security/vuxml/files/tidy.sh > "/usr/ports/security/vuxml/files/tidy.xsl" > "/usr/ports/security/vuxml/vuln-flat.xml" > > "/usr/ports/security/vuxml/vuln.xml.tidy" > /usr/local/bin/python3.12 > /usr/ports/security/vuxml/files/check_vuln_portepoch.py > /usr/ports/security/vuxml/vuln/2026.xml > /var/ports/INDEX-15.xz 1982 kB 10 MBps > 01s > >>> Validating... > /usr/local/bin/xmllint --valid --noout > /usr/ports/security/vuxml/vuln-flat.xml > file:///usr/local/share/xml/dtd/xhtml-modularization/xhtml-special.ent:37: > parser warning : Invalid redeclaration of predefined entity 'lt' > <!ENTITY lt "&<" ><!-- less-than sign, U+003C ISOnum --> > ^ > file:///usr/local/share/xml/dtd/xhtml-modularization/xhtml-special.ent:39: > parser warning : Invalid redeclaration of predefined entity 'amp' > <!ENTITY amp "&&" ><!-- ampersand, U+0026 ISOnum --> > ^ > >>> Successful. > Checking if tidy differs... > ... seems okay > Checking for space/tab... > ... seems okay > Checking CVE IDs... > ... seems okay > /usr/local/bin/python3.12 > /usr/ports/security/vuxml/files/extra-validation.py > /usr/ports/security/vuxml/vuln-flat.xml > Warning: description too long (30492 chars, 5000 is warning threshold): > 16cb13dc-a55d-11f1-bf98-a8a1599412c6) > Warning: description too long (5765 chars, 5000 is warning threshold): > fee67ad5-a05e-11f1-ad2b-40b034429ecf) > Warning: description too long (55291 chars, 5000 is warning threshold): > a188c081-9ce8-11f1-8fc6-cb9659fdabad) > Warning: description too long (36732 chars, 5000 is warning threshold): > 20683bca-e344-4348-a033-db862123615d) > Warning: description too long (38134 chars, 5000 is warning threshold): > 659e52d0-7574-11f1-8de5-a8a1599412c6) > Warning: description too long (7235 chars, 5000 is warning threshold): > efa1873c-64a0-11f1-b189-a8a1599412c6) > Warning: description too long (13739 chars, 5000 is warning threshold): > e725f5d5-5c24-11f1-b189-a8a1599412c6) > Warning: description too long (18960 chars, 5000 is warning threshold): > 738f5590-550c-11f1-9f97-3fa0ea3edd7d) > Warning: description too long (11908 chars, 5000 is warning threshold): > da4d7162-4aa3-11f1-b189-a8a1599412c6) > > Be sure to get versioning right for PORTEPOCH and remember possible > linux-* ports! > Also, <gt> tags are usually wrong in ranges. Use <ge> where adequate. > > [18:20 mydev dvl /usr/ports/security/vuxml] % > > > > + </package> > > + </affects> > > + <description> > > + <body xmlns="http://www.w3.org/1999/xhtml"> > > + <p> > https://github.com/OpenIDC/cjose/security/advisories/GHSA-75r7-f5cv-g3wj > > reports:</p> > > + <blockquote > > cite=" > https://github.com/OpenIDC/cjose/security/advisories/GHSA-75r7-f5cv-g3wj"> > > + <p> > > + 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. > > + </p> > > + </blockquote> > > + </body> > > + </description> > > + <references> > > + <cvename>CVE-2026-53938</cvename> > > + <url>https://cveawg.mitre.org/api/cve/CVE-2026-53938</url> > > + </references> > > + <dates> > > + <discovery>2026-09-08</discovery> > > + <entry>2026-09-14</entry> > > + </dates> > > + </vuln> > > + > > <vuln vid="fac18f5f-afc2-11f1-8266-3c7c3fba4204"> > > <topic>Gitea -- multiple vulnerabilities</topic> > > <affects> > > -- > Dan Langille > dan@langille.org >