GHSA-fccg-mwvh-qqg4
Netty: Fragmented ClientHello records trigger quadratic pre-handshake reassembly in default SNI parsing
Quick fix
GHSA-fccg-mwvh-qqg4 — io.netty:netty-handler: upgrade to the fixed version with the command below.
# pom.xml: bump <version>4.2.17.Final</version> for io.netty:netty-handlerDetails
### 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 constructors - `io.netty.handler.ssl.SslClientHelloHandler` — pre-handshake ClientHello aggregation path
### Vulnerable Code Locations
- `handler/src/main/java/io/netty/handler/ssl/SniHandler.java:85` - `handler/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 `SniHandler` for 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/
Are you affected?
Enter the version of the package you're using.
Affected packages
4.2.0.FinalFixed in: 4.2.17.Final# pom.xml: bump <version>4.2.17.Final</version> for io.netty:netty-handler0Fixed in: 4.1.137.Final# pom.xml: bump <version>4.1.137.Final</version> for io.netty:netty-handlerReferences
- https://github.com/netty/netty/security/advisories/GHSA-fccg-mwvh-qqg4[WEB]
- https://nvd.nist.gov/vuln/detail/CVE-2026-75596[ADVISORY]
- https://github.com/netty/netty/pull/17213[WEB]
- https://github.com/netty/netty/pull/17217[WEB]
- https://github.com/netty/netty/commit/1b5abc6443b63726c72cdd285af2feb7ddbb8ff7[WEB]
- https://github.com/netty/netty/commit/9e0519239108a69b7e9bbc5e9182ee139a0d7961[WEB]
- https://github.com/netty/netty[PACKAGE]
- https://github.com/netty/netty/releases/tag/netty-4.1.137.Final[WEB]
- https://github.com/netty/netty/releases/tag/netty-4.2.17.Final[WEB]