fix(deps): pin Netty to 4.1.135.Final to fix CVE-2025-24970 (high-severity DoS)

[joerg84]

Summary

Fixes CVE-2025-24970 (HIGH, CVSS 7.5) in Netty. grpc-netty:1.60.2 pulls Netty 4.1.100.Final transitively, where a specially crafted packet can crash the native SslHandler, causing a denial of service. The fix is Netty ≥ 4.1.118.Final.

grpc-netty does not pin a patched Netty even in recent releases (see grpc/grpc-java#11911 — 1.70.0 still scans HIGH), so this pins Netty directly without a large grpc upgrade.

Changes

• Pin the three Netty modules that grpc-netty declares directly — netty-codec-http2, netty-handler-proxy, netty-transport-native-unix-common — to 4.1.135.Final.
• Bump netty-tcnative-boringssl-static 2.0.61.Final → 2.0.77.Final (the version paired with Netty 4.1.135).

Why pin those three modules

The published artifact is the thin jar with a flat dependency POM (no <dependencyManagement>), so consumers resolve Netty transitively from grpc-netty. A BOM/constraint would not override the transitive version for Maven consumers. Declaring the same three modules grpc-netty declares — as direct deps at the patched version — makes the patched version win for everyone (Maven nearest-wins, Gradle highest-wins), pulling the whole Netty graph (incl. the vulnerable netty-handler / netty-common) up to 4.1.135.

Bonus

Also brings in patched netty-codec-http (CVE-2024-29025) and netty-common (CVE-2025-25193).

Verification

• ./gradlew clean build jar compileIntegrationTestJava → BUILD SUCCESSFUL, unit tests pass (JDK 17, Gradle 8.5).
• gradle dependencies --configuration runtimeClasspath → every io.netty:* module resolves to 4.1.135.Final (the three 4.1.100 -> 4.1.135 overrides are visible), tcnative at 2.0.77.
• Generated POM lists the three Netty modules at 4.1.135.Final + tcnative 2.0.77 as direct deps, so the override propagates to consumers.

Notes

• Netty 4.1.x is binary-backward-compatible, so pinning ahead of grpc-netty's tested 4.1.100 is safe; this is the remediation grpc recommends for these CVEs. CI's integration-test job exercises the live gRPC/Netty transport.
• Related but heavier alternative: draft Update grpc version to 1.75.0 #198 (grpc → 1.75.0). This PR is the focused CVE fix.

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes the gRPC transport stack (Netty/tcnative) for all library consumers; low code churn but affects security-sensitive networking dependencies.

Overview
Pins Netty 4.1.135.Final on the three modules grpc-netty pulls in directly (netty-codec-http2, netty-handler-proxy, netty-transport-native-unix-common) so Gradle/Maven consumers get patched artifacts instead of 4.1.100.Final from grpc-netty:1.60.2, addressing CVE-2025-24970 and related Netty CVEs without upgrading gRPC.

Bumps netty-tcnative-boringssl-static from 2.0.61.Final to 2.0.77.Final to match the pinned Netty line.

^{Reviewed by Cursor Bugbot for commit 7dbacce. Bugbot is set up for automated code reviews on this repo. Configure here.}

[joerg84]

integration-test failure is a known shared-account flake, not caused by this change — re-running

I analyzed the failed integration-test jobs:

• 161 integration tests passed, including gRPC data-plane operations (upsert/query/fetch) over the Netty TLS transport. There are zero transport/SSL/binary-compat errors (no SSLHandshakeException, NoSuchMethodError, NoClassDefFoundError, UNAVAILABLE).
• The 9 failures are: 8× PineconeNotFoundException for a missing pod index pod-index-xydcufjr (via the REST control-plane / OkHttp, not Netty) and 1× gRPC UNAUTHENTICATED — note the server responded, which proves the Netty connection is healthy (a broken transport would surface UNAVAILABLE/connection errors).
• The exact same tests passed on fix(deps): bump jackson to 2.18.8 to fix CVE-2025-52999 (high-severity DoS) #221 (jackson PR, identical setup apart from this change): 107 tests, 0 failed. The two suites ran at overlapping times against the same shared Pinecone account, and the per-run pod index was removed mid-run (concurrent runs + the automated index-cleanup utility). This matches the integration-test flakiness addressed in 6072a1d.

Re-running the failed jobs now that #221's run has finished. The Netty 4.1.135 pin is validated by the passing data-plane tests + green build on Java 8/11/16/17.

[rohanshah18]

Thank you for addressing the vulnerability, LGTM!