release: Suppress CVEs that do not affect Druid by kfaraz · Pull Request #20236 · apache/druid

kfaraz · 2026-09-02T18:05:00Z

Created with the same changes as in #20235 since that PR was from a fork which couldn't use secrets (NVD_API_KEY) to run security vulnerabilities check.

This patch suppresses some CVEs encountered while preparing the release of Apache Druid 38.0.0
https://github.com/apache/druid/actions/runs/31012362900/job/92327549691

The patch is mostly Claude-generated.

This PR has:

FrankChen021 · 2026-09-03T02:01:35Z

The job above didn't scan all modules. You can refer to the job in this following link to find out all reported CVEs to check whether we should suppress these CVEs

https://github.com/apache/druid/actions/runs/33229536711/job/99039733975?pr=20126

Druid's web console only calls uuidv4() with no buf argument, so the vulnerable v3/v5/v6 code path is never exercised. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

FrankChen021

Severity	Findings
P0	0
P1	1
P2	1
P3	0
Total	2

Reviewed 1 of 1 changed files.

This is an automated review by Codex GPT-5.6-Luna(max)

FrankChen021 · 2026-09-03T13:09:20Z

CVE-2026-42584

+    <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 -->


[P1] Do not suppress the Netty response desynchronization

The new suppression is unsafe for the Netty 3 client used by Druid. Netty 3's HttpClientCodec queues request methods and only treats status 100 as an empty informational response; a 103 response can therefore complete the current response early while the connection remains reusable, desynchronizing the next request's response. Keep this CVE unsuppressed until the client holds the connection through the final response or the codec is patched or upgraded.

Hmm, this does seem like a valid concern.
The CVE-2026-42584 does seem to affect all Netty versions lower than 4.1.133.
Let me double check on what can be done here, because upgrading Netty3 to Netty4 has already been discussed and there is also a PR (#19754 ) but we cannot block Druid 38 release on that.

Thanks for checking. I re-verified this against the current head and the local netty-3.10.6.Final source. The suppression is still present at this line, but the comment's “Netty 4.x codec; different implementation” justification does not hold for the client Druid actually uses:

org.jboss.netty.handler.codec.http.HttpClientCodec skips queue.poll() only for status 100; status 103 falls through to queue.poll(), while the base decoder still treats all 1xx responses as empty.

NettyHttpClient treats every non-chunked response as complete, removes its handler, and returns the channel to ResourcePool. A server can therefore send an interim 103, cause the channel to be reused, and then deliver the original final response after the next request has been written.

That is the same unsafe response/request pairing described by CVE-2026-42584. Please remove this CVE from the Netty 3 suppression until this client waits for the final response or is patched/upgraded. If release timing requires accepting the exposure, it should be tracked as an explicit risk rather than suppressed as unaffected.

Reviewed 1 of 1 changed files.

I checked this again, and it seems that the CVE affects 4.x versions only.
All sources agree that Netty3 is unaffected as it uses a different implementation.

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.

This is an automated review by Codex GPT-5.6-Luna(max)

FrankChen021

Severity	Findings
P0	0
P1	1
P2	0
P3	0
Total	1

The stale async-http-client suppression was removed and that follow-up is resolved. The Netty 3 response-desynchronization suppression remains unresolved; the inline finding documents why the current Druid integration is still unsafe. No additional issues were found in the current one-file diff.

Reviewed 1 of 1 changed files.

This is an automated review by Codex GPT-5.6-Luna(max)

FrankChen021 · 2026-09-05T12:54:14Z

+    <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 -->


[P1] Do not suppress the Netty response desynchronization

The “Netty 4.x / different implementation” justification is not safe for Druid's client. In the local Netty 3.10.6 source, HttpClientCodec.Decoder special-cases only status 100 before queue.poll(), while HttpMessageDecoder treats all 1xx statuses (including 103) as empty. NettyHttpClient calls finishRequest() for every non-chunked response and returns the channel to ResourcePool at lines 258-259 and 317-335. Thus a server can send 103, make Druid return and reuse the socket, and deliver the final response after the next request has been written. Remove this CVE from the Netty 3 suppression or explicitly track and mitigate the exposure until the client waits for final responses or is patched/upgraded.

…s, opentelemetry, testcontainers) - CVE-2026-33117 (azure): affects Key Vault Keys local crypto path; Druid uses Azure for blob storage only - CVE-2026-49845, CVE-2026-53561, CVE-2026-55976 (hive-storage-api): Hive server CVEs; Druid only uses Murmur3 hash util from this jar - CVE-2026-54512, CVE-2026-54513, CVE-2026-68497 (jackson-databind): affect jackson shaded inside hadoop-client-runtime and parquet-jackson jars; not Druid's own jackson - CVE-2026-2332, CVE-2026-10050 (jetty): affect Jetty shaded in hadoop-client-runtime; not Druid's own Jetty 12.x - CVE-2026-56741, CVE-2026-56740 (jline): JLine Telnet server DoS; shaded in hadoop-client-runtime, Druid exposes no Telnet endpoint - CVE-2026-24051, CVE-2026-39883, CVE-2026-29181 (opentelemetry): false positive — all affect the Go SDK, not the Java artifact - CVE-2026-40542, CVE-2026-71290, CVE-2026-54399, CVE-2026-54428 (httpclient5/httpcore5): shaded in docker-java-transport-zerodep which is test-scoped only Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

FrankChen021

Severity	Findings
P0	0
P1	1
P2	4
P3	0
Total	5

This is an automated review by Codex GPT-5.6-Luna(max)

FrankChen021 · 2026-09-07T12:27:54Z

+      file name: hadoop-client-runtime-3.5.0.jar (shaded jackson-databind 2.18.6)
+                 parquet-jackson-1.18.0.jar (shaded jackson-databind 2.22.1)
+    ]]></notes>
+    <packageUrl regex="true">^pkg:maven/com\.fasterxml\.jackson\.core/jackson-databind@(2\.18\.|2\.22\.).*$</packageUrl>


[P1] Scope Jackson suppressions to the shaded jars

packageUrl is the only matching condition here; the file name in <notes> is informational, so this regex also matches Druid's normal com.fasterxml.jackson.core:jackson-databind dependency. The root POM manages that dependency at 2.22.2, which falls in 2.22.*, meaning these CVEs are suppressed for the production Jackson artifact as well as the shaded 2.18.6/2.22.1 copies. Please scope this to the Hadoop/Parquet container (or otherwise distinguish the shaded artifact) instead of suppressing the same GAV globally.

FrankChen021 · 2026-09-07T12:27:54Z

CVE-2026-33117

+    <notes><![CDATA[
+      file name: azure-core-1.58.1.jar azure-core-http-netty-1.16.5.jar azure-identity-1.18.4.jar azure-json-1.5.1.jar
+    ]]></notes>
+    <packageUrl regex="true">^pkg:maven/com\.azure/azure-.*@.*$</packageUrl>


[P2] Do not match every Azure artifact

The regex is broader than the artifacts listed in the notes: it matches com.azure:azure-security-keyvault-keys, which is the package named by CVE-2026-33117, in addition to azure-core/azure-identity/storage clients. Because notes do not constrain the rule, any future Key Vault Keys dependency would have this critical CVE silently suppressed. Match the specific non-vulnerable GAVs (or the containing jar) instead.

FrankChen021 · 2026-09-07T12:27:54Z

CVE-2026-10050

+    <notes><![CDATA[
+      file name: hadoop-client-runtime-3.5.0.jar (shaded jetty-http/jetty-io 9.4.58.v20250814)
+    ]]></notes>
+    <packageUrl regex="true">^pkg:maven/org\.eclipse\.jetty/jetty-(http|io)@9\.4\.58.*$</packageUrl>


[P2] Include the Jetty artifact for CVE-2026-10050

This pattern matches only purls for jetty-http and jetty-io. CVE-2026-10050 is associated with Jetty's jetty-security artifact and its DigestAuthentication code in jetty-client; neither identifier matches this alternation. Thus the second CVE remains unsuppressed even if it is reported from the embedded Hadoop runtime. Split the CVEs and match the actual reported embedded artifact(s), or the containing Hadoop jar.

FrankChen021 · 2026-09-07T12:27:54Z

+    <notes><![CDATA[
+      file name: hadoop-client-runtime-3.5.0.jar (shaded jline 3.9.0)
+    ]]></notes>
+    <packageUrl regex="true">^pkg:maven/org\.jline/jline@.*$</packageUrl>


[P2] Match JLine's remote Telnet module

The affected Maven package for both CVEs is org.jline:jline-remote-telnet, not org.jline:jline. Hadoop's 3.5.0 runtime embeds the jline-remote-telnet module and its shaded Telnet classes, and Dependency-Check analyzes embedded Maven POMs as separate package identifiers. This exact jline purl therefore misses the reported package, so the suppression will not clear these findings. Match jline-remote-telnet (and any other reported embedded modules) explicitly.

FrankChen021 · 2026-09-07T12:27:54Z

CVE-2026-54428

+    <notes><![CDATA[
+      file name: docker-java-transport-zerodep-3.7.1.jar (shaded httpclient5 5.5.1 and httpcore5 5.3.6)
+    ]]></notes>
+    <packageUrl regex="true">^pkg:maven/org\.apache\.httpcomponents\.(client5/httpclient5|core5/httpcore5)@.*$</packageUrl>


[P2] Include httpcore5-h2 in the suppression

CVE-2026-54428 is published for org.apache.httpcomponents.core5:httpcore5-h2, but the alternation covers only core5/httpcore5 and omits core5/httpcore5-h2. docker-java-transport-zerodep-3.7.1.jar embeds httpcore5-h2 5.3.6 separately, so the HTTP/2 CVE remains reported. Add core5/httpcore5-h2 to the rule or scope it to the containing test jar.

Suppress CVEs that do not affect Druid

c42aa7b

kfaraz mentioned this pull request Sep 2, 2026

release: Suppress CVEs that do not affect Druid #20235

Closed

10 tasks

kfaraz added this to the 38.0.0 milestone Sep 2, 2026

kfaraz requested review from Akshat-Jain and cryptoe September 2, 2026 18:07

Akshat-Jain approved these changes Sep 2, 2026

View reviewed changes

kfaraz and others added 2 commits September 3, 2026 13:12

Suppress memcached CVEs

c4fb739

Suppress uuid GHSA-w5hq-g745-h8pq (not applicable to Druid)

8734482

Druid's web console only calls uuidv4() with no buf argument, so the vulnerable v3/v5/v6 code path is never exercised. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

FrankChen021 reviewed Sep 3, 2026

View reviewed changes

kfaraz closed this Sep 3, 2026

kfaraz reopened this Sep 3, 2026

Fixes

a61e98d

FrankChen021 reviewed Sep 5, 2026

View reviewed changes

FrankChen021 reviewed Sep 7, 2026

View reviewed changes

Uh oh!

Conversation

kfaraz commented Sep 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

FrankChen021 commented Sep 3, 2026

Uh oh!

FrankChen021 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kfaraz Sep 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

FrankChen021 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

FrankChen021 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

kfaraz commented Sep 2, 2026 •

edited

Loading

kfaraz Sep 4, 2026 •

edited

Loading