chore(deps): bump docker/scout-action from 1.18.2 to 1.20.3

[dependabot]

⚠️ Dependabot is rebasing this PR ⚠️

Rebasing might not happen immediately, so don't worry if this takes some time.

Note: if you make any changes to this PR yourself, they will take precedence over the rebase.

---

Bumps docker/scout-action from 1.18.2 to 1.20.3.

Release notes

Sourced from docker/scout-action's releases.

v1.20.3

What's Changed

• Improve retries of temporary and network errors @​chrispatrick
• Fix handling of dockerfiles included in provenance attestations @​chrispatrick
• Fix handling of cosign sig tags @​chrispatrick
• Use Docker Desktop HTTP proxy transport when available @​benja-M-1
• Escape mentions from CVE descriptions to prevent spam notifications @​benja-M-1

v1.20.2

What's Changed

• Fix binary download logic @​benja-M-1

Commits

• 8910519 Merge pull request #100 from docker/release/v1.20.3
• 0690e90 [BOT] Update assets for v1.20.3 release
• 1128f02 Merge pull request #99 from docker/release/v1.20.2
• d534164 [BOT] Update assets for v1.20.2 release
• 2c5ca4c Merge pull request #98 from docker/update-workflows-to-match-new-flow
• ddf8a10 update workflows to match new release flow better
• 75ec1d4 Merge pull request #96 from docker/release/v1.20.1
• 9baba47 remove node_modules
• b7d2477 [BOT] Update assets for v1.20.1 release
• 07724ea Merge pull request #95 from docker/remove-binaries-from-repo
• Additional commits viewable in compare view

[github-actions]

🔍 Vulnerabilities of liquibase/liquibase-secure:4516599d5052f43a88892fffa17434e938ae938a

📦 Image Reference liquibase/liquibase-secure:4516599d5052f43a88892fffa17434e938ae938a

digest	sha256:3303b72601457e9700362cbea4a3cc3d751bd850779d24fc7f1d18b1fdebf1a5
vulnerabilities
platform	linux/amd64
size	870 MB
packages	478

📦 Base Image eclipse-temurin:21-jre

also known as	21-jre-noble 21.0.10_7-jre 21.0.10_7-jre-noble a26beda5d3a48883a6c629ec04b95a1e91c223d1c8bbffef792214d0ea11ca36
digest	sha256:be2ed5af8104188957a9f8ba1e440cc357f4d0f6f5a5628e84c9b9c5843214e6
vulnerabilities

io.netty/netty-codec-http 4.1.130.Final (maven) pkg:maven/io.netty/netty-codec-http@4.1.130.Final Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') Affected range <4.1.132.Final Fixed version 4.1.132.Final CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N EPSS Score 0.029% EPSS Percentile 8th percentile Description Summary 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: https://w4ke.info/2025/06/18/funky-chunks.html https://w4ke.info/2025/10/29/funky-chunks-2.html 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 RFC 9110: HTTP Semantics (Sections 5.6.4, 7.1.1) Funky Chunks Research Funky Chunks 2 Research Attachments java_netty.zip

io.netty/netty-codec-http2 4.1.129.Final (maven) pkg:maven/io.netty/netty-codec-http2@4.1.129.Final Allocation of Resources Without Limits or Throttling Affected range <4.1.132.Final Fixed version 4.1.132.Final CVSS Score 8.7 CVSS Vector 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 EPSS Score 0.087% EPSS Percentile 25th percentile Description Summary 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.

io.netty/netty-codec-http 4.2.9.Final (maven) pkg:maven/io.netty/netty-codec-http@4.2.9.Final Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') Affected range >=4.2.0.Alpha1 <4.2.10.Final Fixed version 4.2.10.Final CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N EPSS Score 0.029% EPSS Percentile 8th percentile Description Summary 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: https://w4ke.info/2025/06/18/funky-chunks.html https://w4ke.info/2025/10/29/funky-chunks-2.html 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 RFC 9110: HTTP Semantics (Sections 5.6.4, 7.1.1) Funky Chunks Research Funky Chunks 2 Research Attachments java_netty.zip

io.netty/netty-codec-http2 4.1.130.Final (maven) pkg:maven/io.netty/netty-codec-http2@4.1.130.Final Allocation of Resources Without Limits or Throttling Affected range <4.1.132.Final Fixed version 4.1.132.Final CVSS Score 8.7 CVSS Vector 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 EPSS Score 0.087% EPSS Percentile 25th percentile Description Summary 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.

io.netty/netty-codec-http 4.1.129.Final (maven) pkg:maven/io.netty/netty-codec-http@4.1.129.Final Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') Affected range <4.1.132.Final Fixed version 4.1.132.Final CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N EPSS Score 0.029% EPSS Percentile 8th percentile Description Summary 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: https://w4ke.info/2025/06/18/funky-chunks.html https://w4ke.info/2025/10/29/funky-chunks-2.html 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 RFC 9110: HTTP Semantics (Sections 5.6.4, 7.1.1) Funky Chunks Research Funky Chunks 2 Research Attachments java_netty.zip

io.netty/netty-codec-http2 4.2.9.Final (maven) pkg:maven/io.netty/netty-codec-http2@4.2.9.Final Allocation of Resources Without Limits or Throttling Affected range >=4.2.0.Alpha1 <4.2.10.Final Fixed version 4.2.11.Final CVSS Score 8.7 CVSS Vector 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 EPSS Score 0.087% EPSS Percentile 25th percentile Description Summary 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.

[jnewton03]

@dependabot rebase

[dependabot]

Looks like this PR is already up-to-date with main! If you'd still like to recreate it from scratch, overwriting any edits, you can request @dependabot recreate.