Upgrade and Verify Netty 4.1.137 or 4.2.17
A version change in the build file is only one part of remediating CVE-2026-75595. The fixed release must reach the packaged application, and the deployed TLS listener must keep its intended client-authentication policy. The affected io.netty:netty-handler ranges are up to 4.1.136.Final, and 4.2.0.Final through 4.2.16.Final. The patched releases are 4.1.137.Final and 4.2.17.Final.
Choose the correct release line
Select the fixed version that matches the application's supported Netty branch. Do not downgrade a newer major line merely to satisfy a version string. Check the framework's compatibility notes and its dependency-management rules before changing the version.
If the vulnerable package arrives through a platform BOM, update the BOM or add a narrowly scoped constraint. If the application shades Netty, rebuild the shaded artifact. If a container base image supplies the class, rebuild the image from a patched parent rather than copying a replacement class into the running filesystem.
Inspect before and after
Before the change, record the resolved netty-handler version and the service owner. After the build, inspect the artifact again:
mvn dependency:tree -Dincludes=io.netty:netty-handler
For Gradle, use:
./gradlew dependencyInsight --dependency netty-handler --configuration runtimeClasspath
Compare the output with the affected ranges. Then verify the file inside the deployable image or executable jar. The source build can be correct while a stale layer or alternate class path leaves the vulnerable copy in production.
Test mTLS behavior
Prepare test clients for the intended SNI route, a missing or unrecognized SNI, and the fallback context. Verify that a client with a valid certificate reaches the protected service when expected. Verify that a client without a certificate is rejected. Use controlled test credentials and avoid reading production client keys.
Review the default SslContext as part of the deployment. If it permits clients without certificates and there is no application-level peer-certificate check, treat that configuration as a separate access-control finding, even after the library is patched.
Roll out with observable checks
Use a canary or small service slice to compare TLS handshake outcomes before and after the upgrade. Track certificate-authentication failures, TLS parsing errors and route-selection failures. A jump in valid-client failures can indicate a certificate or SNI mapping problem. A drop in required-auth rejections can indicate that policy changed.
Do not use a successful health check as proof that mTLS works. Health endpoints may use a different listener or context. Add a dedicated test that exercises the same SNI mapping and client-auth settings as the protected workload.
Handle the fallback as a temporary control
If the upgrade is delayed, review whether the default context can require a client certificate. That change can remove the permissive fallback condition described by the advisory. It may break clients that rely on the fallback route, so test it and keep the library upgrade in the remediation plan.
The temporary control does not fix the parser error. It changes the surrounding policy so a selection failure is less likely to grant access. Record the residual affected version until the dependency is updated.
Close the finding with evidence
A complete record contains the application identity, resolved fixed version, packaged artifact hash, deployment time and mTLS test result. The owner should be able to show that the affected range is gone from the running artifact and that the protected route still requires the intended certificate.
ZoomEye Search app="Netty" returned 505 product fingerprints on 2026-10-31, with a CVE Filter result of 0. Those values support external discovery but do not replace the rollout evidence. Use them to look for forgotten public services, while the upgrade record remains the basis for closure.
Top comments (0)