[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87sep3jmne.fsf@oldenburg.str.redhat.com>
Date: Tue, 28 Jan 2025 10:47:01 +0100
From: Florian Weimer <fweimer@...hat.com>
To: Pete Allor <pallor@...hat.com>
Cc: oss-security@...ts.openwall.com
Subject: Re: Node.js EOL CVEs: CVE-2025-23087,
CVE-2025-23088, CVE-2025-23089
* Pete Allor:
> It is why I would advocate for a CVSS review (as we do at Red Hat) and
> then assign a 'Severity Rating' as that now involves how the component
> is used within our software which changes HOW a
> customer/downstream/user should actually view that CVE.
But is this really how it works these days? For example, if we use a
component to render the in-program documentation (traditionally called
“online help”, but we would consider this offline today), and the
upstream for this component documents publicly that a vulnerability is
being actively exploited for (user-initiated) remote code execution, we
must fix the component even if it's just used in an offline
documentation viewer. CVSS impact review does not change that, as far
as I know.
Hence the suggestion of a fork, so that upstream's exploitation
announcements do not carry over 1:1 to the product.
I think this fix-regardless-of-impact requirement is new.
Legitimate-looking sources for inflated impact ratings have been around
for more than a decade, on the other hand.
Thanks,
Florian
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
