Re: git: 85adc9fdc0e0 - main - security/vuxml: Add devel/cjose vulnerabilities
Date: Tue, 15 Sep 2026 18:23:34 UTC
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.
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