GHSA-fccg-mwvh-qqg4: Maven/io.netty:netty-handler vulnerability

Published Sep 8, 2026
·
Updated

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/

Affected Software

2 affected componentsFixes available
maven/io.netty:netty-handler<=4.1.136.Final
4.1.137.Final
maven/io.netty:netty-handler>=4.2.0.Final<=4.2.16.Final
4.2.17.Final

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade maven/io.netty:netty-handler to a version that resolves this vulnerability.

    Fixed in 4.1.137.Final
  2. Upgrade

    Upgrade maven/io.netty:netty-handler to a version that resolves this vulnerability.

    Fixed in 4.2.17.Final

Event History

Sep 8, 2026
Advisory Published
via GitHub·06:14 PM
Data Sourced
via GitHub·06:14 PM
DescriptionWeaknessAffected Software

Frequently Asked Questions

1

Which Netty configurations are exposed?

Applications using io.netty.handler.ssl.SniHandler through its default constructors are affected. The pre-handshake ClientHello aggregation path in io.netty.handler.ssl.SslClientHelloHandler is also affected.

2

What access does an attacker need to trigger the CPU amplification?

A remote peer must be able to send TLS handshake records to the affected entrypoint. The peer can advertise a large ClientHello length in a small initial record and deliver the remaining body in many tiny records before the handshake completes.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203