[FP]: False positive CVE for netty-shaded 1.75.0

[vishwa-ramkumar]

Package URl

pkg:maven/io.grpc/grpc-netty-shaded@1.75.0

CPE

cpe:2.3:a:netty:netty:*:*:*:*:*:*:*:* versions up to (excluding) 4.1.124

CVE

CVE-2025-55163

ODC Integration

None

ODC Version

12.1.0

Description

No response

[github-actions]

Maven Coordinates

<dependency>
   <groupId>io.grpc</groupId>
   <artifactId>grpc-netty-shaded</artifactId>
   <version>1.75.0</version>
</dependency>

Suppression rule:

<suppress base="true">
   <notes><![CDATA[
   FP per issue #7981
   ]]></notes>
   <packageUrl regex="true">^pkg:maven/io\.grpc/grpc-netty-shaded@.*$</packageUrl>
   <cpe>cpe:/a:netty:netty</cpe>
</suppress>

Link to test results: https://github.com/dependency-check/DependencyCheck/actions/runs/18034980432

[chadlwilson]

I’m not sure about this suppression. Shaded netty is still netty, it’s just the wrong version. The CVE you link is a recent CVE and it’s quite possible your shaded grpc version is vulnerable to it. (although I do note that the full report does show all the old netty CVEs also)

Have you looked at earlier issues like #5433? Do you have the central analyzer enabled?

[chadlwilson]

Hiya @aikebah - what do you think about re-evaluating this one? It keeps coming up with or without Central Analyzer and I can see why given the naming and reality.

Do you think it’s fair to expect that if the GRPC-Java client was exposed to a Netty bug in their shaded Netty that it’d be reported against grpc, rather than Netty? The fix certainly needs to be in grpc-Java due to the shading. If so, we should probably suppress this common source of false positives since we’re constantly comparing a Netty version against a grpc version which doesn’t make much sense.

[aikebah]

@chadlwilson grpc-netty-shaded library is affected (but not anymore on 1.75 as they upgraded the shaded version of netty to the non-vulnerable 4.1.124).

https://github.com/grpc/grpc-java/releases/tag/v1.75.0

[chadlwilson]

Even if so, this is not the reason that the vuln is being reported, because if you look at the FP ops run it’s also reporting things back to 2019, simply due to comparing a grpc version number to a Netty cpe version.

[aikebah]

The CVE itself is the Netty-specific CVE and as such properly applies to grpc-netty-shaded versions lower than 1.75.0 as those re-package a netty version that does not yet have a mitigation for abusive use of the HTTP/2 protocol. (but only that specific library of grpc-java)

Ideally NVD would have a separate CPE for grpc-netty-shaded that gets CVE-linked to the applicable netty CVEs

[chadlwilson]

Yes, all these FPs being reported are Netty specific CVEs.

However I think you’re missing my point. It’s not about this specific CVe. As far as I can tell, any time a Netty vuln is correctly reported on grpc-Netty-shaded it’s entirely by accident because ODC cannot detect the true underlying Netty version reliably and disentangle it from the grpc version, unless the vuln is classified against the grpc cpe directly within NVD (or elsewhere. This is why there are about 6 FP reports against grpc-netty-shaded that keep coming up.

I don’t think this is helpful at all, and don’t think ODC should be trying to magically match shaded dependencies when it has no idea what the version is.

[chadlwilson]

Please look at the FP run report. There are many CVEs being reported which are all nonsense.

[aikebah]

@chadlwilson Didn't mean that we should not try to find a way to mitigate these, but only commented my findings so others would be able more quickly triage what to do with the assumed FP when it happens (check which version of Netty the library is shading and judge by that what the real positives are from the list).

Simply suppressing netty:netty will not help surface current and future acual issues lurking in grpc-netty-shaded library versions. It could lead to false negatives instead where people wrongly think they're safe because they use grpc-netty-shaded instead of the netty version that it repackages in shaded form.

Not saying we shouldn't do anything on them, but it's hard to 'do the right thing' if grpc-netty-shaded does not get picked up by NVD as something to additionally link Netty CVEs to based on applicable version-range versus the actually shaded version in a grpc-java project release and we don't have the proper version of Netty to compare to for this lib.