Testing Fragmented ClientHello Handling After CVE-2026-75595

The upstream fix for CVE-2026-75595 changes how Netty buffers a fragmented ClientHello and reads its handshake header. The accompanying tests cover fragment sizes from one through four bytes. Those tests are valuable, but a production owner also needs to verify that the upgraded service still enforces the intended SNI and mTLS policy.

Test the parser boundary

Create controlled TLS record inputs where the four-byte handshake header is split across records. The historical test range of one through four bytes is a useful starting point because it exercises the boundary that the old guard mishandled.

The expected result is deterministic parsing of the ClientHello and selection of the appropriate SNI context. The test should fail if an out-of-bounds read causes the generic exception path to select the default context. Keep the fixture data synthetic and avoid using customer traffic.

Test the policy, not only the parser

A parser test can show that a fixed SslClientHelloHandler processes the record. It does not prove that the deployment's SniHandler mapping is correct or that the default context rejects an unauthenticated client.

Add an integration test with three outcomes:

• A valid client certificate and recognized SNI reach the protected route.
• A client without the required certificate is rejected.
• An absent or unknown SNI follows the documented fallback policy.

Configure the test server with the same ClientAuth modes as production. If the production default context is permissive and the application layer checks the certificate, test that second check as well. A TLS handshake alone may not exercise the authorization decision.

Compare fallback contexts

Record the client-auth mode of every SslContext used in the test and the deployed service. The advisory's impact depends on a per-SNI context requiring a certificate while the default context allows none or optional authentication. If those values differ from the expected policy, treat the test as a configuration finding regardless of the Netty patch.

Applications that do not use per-SNI client authentication still need the fixed library because the parser can enter the exception path. Their regression test can focus on correct ClientHello parsing and continued service availability, while the policy test remains relevant to any TLS listener that depends on certificate authentication.

Include upgrade and downgrade checks

Run the parser test against 4.1.137.Final or 4.2.17.Final in the same packaging format used in production. If the application shades Netty or loads it from a container layer, test the packaged artifact rather than a unit-test class path with a different dependency graph.

After deployment, perform a small canary. Compare handshake failures, certificate-authentication rejections and SNI selection errors with the baseline. A successful canary should preserve expected failures for untrusted clients. A drop in those failures needs investigation before the rollout expands.

Keep tests tied to the advisory

Store the CVE identifier, fixed version, test fixture, certificate policy and expected fallback behavior with the application record. When Netty changes again, the test can be rerun with the new release. The record also shows whether a future configuration change weakens the per-SNI gate.

ZoomEye Search app="Netty" returned 505 product fingerprints on 2026-10-31. The CVE Filter returned 0. These observations may prompt a public-asset review, but they cannot replace parser tests or certificate-policy verification inside the deployed service.

References

• Netty security advisory GHSA-c4c3-7fpv-j4q5
• Netty fixing commit 1b5abc6
• Red Hat CVE-2026-75595 record