FrankChen021 commented on code in PR #20236:
URL: https://github.com/apache/druid/pull/20236#discussion_r3940684267
##########
owasp-dependency-check-suppressions.xml:
##########
@@ -274,6 +320,69 @@
<cve>CVE-2025-58057</cve> <!-- Netty 3.x not affected; compression issue
only in 4.x -->
<cve>CVE-2026-33870</cve> <!-- We don't use HttpPostRequestDecoder -->
<cve>CVE-2026-33871</cve> <!-- Netty 3.x not affected; HTTP/2 issues only
in 4.x -->
+ <cve>CVE-2026-44893</cve> <!-- We don't use the HAProxy codec -->
+ <cve>CVE-2026-44250</cve> <!-- We don't use the Redis codec -->
+ <cve>CVE-2026-48059</cve> <!-- We don't use the HAProxy codec -->
+ <cve>CVE-2026-44890</cve> <!-- We don't use the Redis codec -->
+ <cve>CVE-2026-44891</cve> <!-- We don't use the STOMP codec -->
+ <cve>CVE-2026-50011</cve> <!-- We don't use the Redis codec -->
+ <cve>CVE-2026-59901</cve> <!-- We don't use Netty's Bzip2Decoder; Druid
uses Apache Commons Compress for bzip2 -->
+ <cve>CVE-2026-62380</cve> <!-- We don't use the SOCKS codec; Druid uses
HTTP CONNECT proxy tunneling -->
+ <cve>CVE-2026-59898</cve> <!-- Server-side WebSocket vulnerability;
Druid's HTTP server is Jetty, not Netty -->
+ <cve>CVE-2026-59899</cve> <!-- Server-side HttpContentEncoder
vulnerability; Druid uses Netty 3.x as HTTP client only -->
+ <cve>CVE-2026-42587</cve> <!-- Affects brotli/zstd/snappy decompression
added in Netty 4.x; Netty 3.x only supports gzip/deflate -->
+ <cve>CVE-2026-42586</cve> <!-- We don't use the Redis codec -->
+ <cve>CVE-2026-44248</cve> <!-- We don't use the MQTT codec -->
+ <cve>CVE-2026-44249</cve> <!-- We don't use Netty's IpSubnetFilterRule;
Druid uses Jetty for HTTP access control -->
+ <cve>CVE-2026-45416</cve> <!-- Server-side TLS SNI vulnerability; Druid
uses Netty 3.x as TLS client only, never as a server -->
+ <cve>CVE-2026-42581</cve> <!-- Server-side HTTP request smuggling; Druid's
HTTP server is Jetty, not Netty -->
+ <cve>CVE-2026-45674</cve> <!-- Affects netty-resolver-dns which Druid
doesn't use; Druid uses JDK DNS resolution -->
+ <cve>CVE-2026-48006</cve> <!-- We don't use the Redis codec -->
+ <cve>CVE-2026-42585</cve> <!-- Server-side HTTP request smuggling; Druid's
HTTP server is Jetty, not Netty -->
+ <cve>CVE-2026-42584</cve> <!-- HttpClientCodec response desynchronization
in Netty 4.x codec; Druid uses Netty 3.x's HttpClientCodec which has a
different implementation -->
+ <cve>CVE-2026-46340</cve> <!-- We don't use SCTP transport; Druid uses
TCP/NIO -->
+ <cve>CVE-2026-42583</cve> <!-- We don't use Netty's Lz4FrameDecoder; Druid
uses lz4-java directly -->
+ <cve>CVE-2026-48043</cve> <!-- We don't use netty-codec-http2 directly;
Druid's HTTP/2 is served by Jetty -->
+ <cve>CVE-2026-56822</cve> <!-- We don't use netty-handler-ssl-ocsp -->
+ <cve>CVE-2026-56821</cve> <!-- We don't use netty-handler-ssl-ocsp -->
+ <cve>CVE-2026-47691</cve> <!-- Affects netty-resolver-dns which Druid
doesn't use; Druid uses JDK DNS resolution -->
+ <cve>CVE-2026-56820</cve> <!-- We don't use netty-handler-ssl-ocsp -->
+ <cve>CVE-2026-50010</cve> <!-- Druid's Netty 3.x HTTP client does not use
SslContextBuilder; gRPC/AWS SDK paths use managed SSL contexts -->
+ <cve>CVE-2026-42578</cve> <!-- We don't use HttpProxyHandler; Druid uses a
custom HTTP CONNECT tunnel via HttpClientCodec -->
+ <cve>CVE-2026-42579</cve> <!-- We don't use netty-codec-dns; Druid uses
JDK DNS resolution -->
+ </suppress>
+
+ <suppress>
+ <notes><![CDATA[
+ file name: async-http-client-3.0.2.jar
+ ]]></notes>
+ <packageUrl
regex="true">^pkg:maven/org\.asynchttpclient/[email protected]$</packageUrl>
Review Comment:
Verified on the current head: the stale
`org.asynchttpclient:async-http-client:3.0.2` suppression is gone, so this
version-mismatch follow-up is resolved. Reviewed 1 of 1 changed files.
<!-- mergelens:review -->
---
This is an automated review by Codex GPT-5.6-Luna(max)
##########
owasp-dependency-check-suppressions.xml:
##########
@@ -274,6 +320,69 @@
<cve>CVE-2025-58057</cve> <!-- Netty 3.x not affected; compression issue
only in 4.x -->
<cve>CVE-2026-33870</cve> <!-- We don't use HttpPostRequestDecoder -->
<cve>CVE-2026-33871</cve> <!-- Netty 3.x not affected; HTTP/2 issues only
in 4.x -->
+ <cve>CVE-2026-44893</cve> <!-- We don't use the HAProxy codec -->
+ <cve>CVE-2026-44250</cve> <!-- We don't use the Redis codec -->
+ <cve>CVE-2026-48059</cve> <!-- We don't use the HAProxy codec -->
+ <cve>CVE-2026-44890</cve> <!-- We don't use the Redis codec -->
+ <cve>CVE-2026-44891</cve> <!-- We don't use the STOMP codec -->
+ <cve>CVE-2026-50011</cve> <!-- We don't use the Redis codec -->
+ <cve>CVE-2026-59901</cve> <!-- We don't use Netty's Bzip2Decoder; Druid
uses Apache Commons Compress for bzip2 -->
+ <cve>CVE-2026-62380</cve> <!-- We don't use the SOCKS codec; Druid uses
HTTP CONNECT proxy tunneling -->
+ <cve>CVE-2026-59898</cve> <!-- Server-side WebSocket vulnerability;
Druid's HTTP server is Jetty, not Netty -->
+ <cve>CVE-2026-59899</cve> <!-- Server-side HttpContentEncoder
vulnerability; Druid uses Netty 3.x as HTTP client only -->
+ <cve>CVE-2026-42587</cve> <!-- Affects brotli/zstd/snappy decompression
added in Netty 4.x; Netty 3.x only supports gzip/deflate -->
+ <cve>CVE-2026-42586</cve> <!-- We don't use the Redis codec -->
+ <cve>CVE-2026-44248</cve> <!-- We don't use the MQTT codec -->
+ <cve>CVE-2026-44249</cve> <!-- We don't use Netty's IpSubnetFilterRule;
Druid uses Jetty for HTTP access control -->
+ <cve>CVE-2026-45416</cve> <!-- Server-side TLS SNI vulnerability; Druid
uses Netty 3.x as TLS client only, never as a server -->
+ <cve>CVE-2026-42581</cve> <!-- Server-side HTTP request smuggling; Druid's
HTTP server is Jetty, not Netty -->
+ <cve>CVE-2026-45674</cve> <!-- Affects netty-resolver-dns which Druid
doesn't use; Druid uses JDK DNS resolution -->
+ <cve>CVE-2026-48006</cve> <!-- We don't use the Redis codec -->
+ <cve>CVE-2026-42585</cve> <!-- Server-side HTTP request smuggling; Druid's
HTTP server is Jetty, not Netty -->
+ <cve>CVE-2026-42584</cve> <!-- HttpClientCodec response desynchronization
in Netty 4.x codec; Druid uses Netty 3.x's HttpClientCodec which has a
different implementation -->
Review Comment:
I re-checked the local `netty-3.10.6.Final` source and the Druid client
lifecycle. The conclusion that Netty 3 is safe because it is a different
implementation does not hold for this integration:
`org.jboss.netty.handler.codec.http.HttpClientCodec` skips `queue.poll()` only
for status 100; status 103 falls through to `queue.poll()`, and the base
decoder treats every 1xx response as empty. Druid’s `NettyHttpClient` then
calls `finishRequest()` for every non-chunked response and returns the channel
to `ResourcePool` before the final response is consumed. A 103 followed by the
final response can therefore reuse the socket with the previous response still
in flight. Please remove CVE-2026-42584 from the Netty 3 suppression or
explicitly track and mitigate the exposure until the client waits for final
responses or is patched/upgraded.
Reviewed 1 of 1 changed files.
<!-- mergelens:review -->
---
This is an automated review by Codex GPT-5.6-Luna(max)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
