Re: [Buildroot] [PATCH v2] package/libmicrohttpd: ignore CVE-2025-59777 and CVE-2025-62689

From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: yegorslists@googlemail.com
Cc: buildroot@buildroot.org, Bernd Kuhls <bernd@kuhls.net>,
	 Will Newton <will.newton@gmail.com>
Subject: Re: [Buildroot] [PATCH v2] package/libmicrohttpd: ignore CVE-2025-59777 and CVE-2025-62689
Date: Fri, 18 Sep 2026 21:50:59 +0200	[thread overview]
Message-ID: <aq2VV4mwPo83xmnL@windsurf> (raw)
In-Reply-To: <20260901114951.2675876-1-yegorslists@googlemail.com>

Hello Yegor,

On Tue, Sep 01, 2026 at 01:49:51PM +0200, yegorslists--- via buildroot wrote:
> From: Yegor Yefremov <yegorslists@googlemail.com>
> 
> Both CVEs affect the experimental WebSocket helper library
> (src/microhttpd_ws, installed as libmicrohttpd_ws.so), as stated in the
> originating JPCERT/CC advisory JVN76719218:
> 
>   "The vulnerability exists in libmicrohttpd_ws.so, which is generated
>    when building with the --enable-experimental option."
> 
> That directory is guarded by AM_CONDITIONAL([HAVE_EXPERIMENTAL]) in
> src/Makefile.am, and --enable-experimental defaults to "no". Buildroot
> never passes it, so no Buildroot version has ever built the vulnerable
> code. Upstream removed the module outright in commit
> ff13abc1c1d7d2b30d69d5c0bd4a237e1801c50b ("remove broken experimental
> code", 13651 deletions), first released in 1.0.3.
> 
> An ignore is needed rather than a version bump, because the NVD entries
> for both CVEs share a single CPE match criteria that encodes the affected
> range as
> 
>   cpe:2.3:a:gnu:libmicrohttpd:*:*:*:*:*:*:*:*, versionEndExcluding 2025-09-16
> 
> i.e. the author date of the fix commit instead of a version number. Since
> support/scripts/cve.py compares versions using LooseVersion, every 1.0.x
> version evaluates as smaller than "2025-09-16" and is reported as
> affected, no matter how far the package gets bumped.

Thanks a lot, but this is not the right fix I'm afraid. The right fix
is to send an e-mail to NVD at cpe_dictionary@nist.gov to ask them to
update the CVE entry. They are responsive. You just need to explain
very clearly which commit fixed the vulnerability, in which release it
was integrated, and they will fix the CVE description.

Once this is done, we can potentially accept as a temporary measure to
add those IGNORE_CVES entry.

The way I see this is like patches: if you don't "upstream" the fix of
the CVE metadata, then we will have to keep those IGNORE_CVES entries
forever, which is not desirable.

Thanks!

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot