FrankChen021 commented on code in PR #20236:
URL: https://github.com/apache/druid/pull/20236#discussion_r3979249567
##########
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:
## Follow-up assessment
Thanks — understood. I rechecked the current Netty 3 source and client
lifecycle while reviewing 1 of 1 changed files. I agree this can be an explicit
trusted-peer risk decision for Druid-to-Druid traffic. The remaining technical
caveat is that Netty 3 is not automatically safe just because the upstream
advisory names Netty 4.x: its `HttpClientCodec` dequeues the request method for
a 103 response, while Druid completes every non-chunked response and returns
the channel before the final response arrives. A peer that emits 103 can
therefore still create the unsafe reuse window.
I’m not reopening the prior finding as a separate merge recommendation given
the explicit risk acceptance. Please track it with
[apache/druid#19567](https://github.com/apache/druid/pull/19567), and consider
updating the suppression comment so it describes this as an accepted
trusted-peer exposure rather than implying that Netty 3’s different
implementation removes the risk.
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]
