CVE-2026-75596 — netty-handler
Fix: netty/netty@1b5abc6CVE-2026-75596 is a CWE-407 vulnerability in io.netty:netty-handler. A fix is available for io.netty:netty-handler — see the affected versions and patch details below.
Netty: Fragmented ClientHello records trigger quadratic pre-handshake reassembly in default SNI parsing
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-75596.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
io.netty:netty-handler☕io.netty:netty-handlerReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
Summary
Netty's default SNI entrypoint reparses and recopies previously received ClientHello fragments on every additional TLS handshake record. A remote peer can send a small first record that advertises a large ClientHello length and then drip the body in many tiny records, causing superlinear (quadratic) CPU work before the handshake completes. With 4095 one-byte fragments, the handler recopies 8,386,560 bytes from only 24,579 bytes on the wire — a 341× amplification ratio.
Affected Entrypoints
io.netty.handler.ssl.SniHandler— default constructorsio.netty.handler.ssl.SslClientHelloHandler— pre-handshake ClientHello aggregation path
Vulnerable Code Locations
handler/src/main/java/io/netty/handler/ssl/SniHandler.java:85handler/src/main/java/io/netty/handler/ssl/SslClientHelloHandler.java:75(decode entry)handler/src/main/java/io/netty/handler/ssl/SslClientHelloHandler.java:165(handshakeBuffer.clear)handler/src/main/java/io/netty/handler/ssl/SslClientHelloHandler.java:174(writeBytes re-copy)codec-base/src/main/java/io/netty/handler/codec/ByteToMessageDecoder.java:294(cumulation retention)
Exploit Path
1. TCP connection → SniHandler → SslClientHelloHandler.decode
2. First record: TLS handshake header declaring large ClientHello length (e.g., 4096 bytes)
3. Attacker sends thousands of tiny follow-on handshake records (1 byte each)
4. On each fragment: handshakeBuffer.clear() + writeBytes() re-copies ALL accumulated body bytes
5. Total bytes copied = n*(n+1)/2 where n = number of body bytes → quadratic
6. Event-loop CPU exhausted before SslHandler takes over
Impact
- Vulnerability Type: Inefficient Algorithmic Complexity
- An unauthenticated network attacker can drive disproportionate CPU consumption on the Netty event loop
- Affects all Netty deployments using
SniHandlerfor TLS termination (the default SNI path) - No privileges, user interaction, or special configuration required
- Can degrade or stall TLS connection handling for all clients on the affected event loop
- The attack requires only modest bandwidth (~25 KB) to trigger significant CPU work
Credits
Found by a security research team from the University of Sydney, focusing on detecting open source software vulnerabilities. Liyi Zhou: https://lzhou1110.github.io/ Ziyue Wang: https://zyy0530.github.io/ Strick: https://str1ckl4nd.github.io/ Maurice: https://maurice.busystar.org/ Chenchen Yu: https://7thparkk.github.io/
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | io.netty:netty-handler | ≥ 4.2.0.Final&&< 4.2.17.Final | 4.2.17.Finalio.netty:netty-handler:4.2.17.Final |
| ☕Maven | io.netty:netty-handler | all versions | 4.1.137.Finalio.netty:netty-handler:4.1.137.Final |
Affected Products
nettynettyDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for io.netty:netty-handler, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update io.netty:netty-handler to 4.2.17.Final or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-75596 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Frequently Asked Questions
Is CVE-2026-75596 in your dependencies?
Find it across Maven, including transitive dependencies.