GHSA-q7qq-6mhp-9rc4: Medium severity pip/twisted vulnerability
Summary
An incomplete header-value validation (CWE-444) in the Twisted HTTP server lets a bare carriage return or line feed in a header value hide a following header from the parser. twisted.web.http.HTTPChannel.headerReceived rejects a NUL byte in a header value but not a bare CR or LF, even though RFC 9110 section 5.5 requires a recipient to reject all three. Because the channel splits requests only on CRLF, a value carrying a bare LF and a second header arrives as one line, so the second header is folded into the value and the request is framed with no body. A front-end that treats the bare LF as a line terminator frames the request differently, and the disagreement lets an attacker smuggle a request past it. This is an incomplete fix of the earlier Twisted request-smuggling advisories, which guarded the NUL sibling of this exact check.
Details
headerReceived splits a header line on the first colon, strips space and tab from the value, and validates it with a single test that rejects only NUL:
python twisted/web/http.py HTTPChannel.headerReceived data = data.strip(b" \t") if b"\x00" in data: # NUL rejected; a bare CR or LF is not self.respondToBadRequestAndDisconnect() return False
The channel delimiter is CRLF, so Foo: x\nContent-Length: 39 is one line: the split yields name Foo and value x\nContent-Length: 39, strip leaves the LF, and the NUL check passes. maybeChooseTransferDecoder is then called with Foo, never sees a Content-Length, and installs no body decoder, so the request is framed with an empty body. The header name and request line already reject CR and LF, so the value is the only gap.
Affected product: Twisted, twisted.web.http.HTTPChannel Affected versions: 26.4.0 and earlier
PoC
Feed one connection a request whose header value carries a bare LF and a Content-Length, followed by a second request in the bytes after it: POST /public HTTP/1.1\r\nHost: v\r\nFoo: x\nContent-Length: 44\r\n\r\nGET /admin HTTP/1.1\r\nHost: internal\r\n\r\n. Twisted parses two requests and serves both, so the smuggled GET /admin returns the /admin response body even though the visible request was only POST /public. The bare CR variant behaves identically, and a NUL in the value is rejected, which isolates the missing CR and LF checks.
Behind a front-end that treats the bare LF as a line terminator, the front-end frames one POST /public and forwards a body while Twisted frames a second GET /admin; the extra response then poisons the shared connection, so a later victim receives the attacker's GET /admin response.
Impact
This is an HTTP request-smuggling exposure (CWE-444) from inconsistent interpretation of a request (CWE-436). Through a front-end that accepts a bare CR or LF as a line terminator, an attacker can smuggle a request the front-end never sees, bypassing front-end access controls, poisoning a shared connection so a later victim receives the attacker's response, and poisoning a cache. Twisted is the strict endpoint that frames the request without a body, so it is realized only behind such a proxy, and there is no code execution.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/Twistedto a version that resolves this vulnerability.Fixed in 26.10.0rc1
Event History
Frequently Asked Questions
Which deployments are realistically exposed to request smuggling?
Deployments where a front-end HTTP component treats a bare LF as a header-line terminator while the Twisted HTTP server does not are exposed to parser disagreement. The issue depends on that differing request framing behavior between the front end and Twisted.
What does an attacker need to exploit this issue?
An attacker needs network access to send a crafted HTTP request containing a bare carriage return or line feed in a header value, followed by another header. No privileges or user interaction are required, but the attack complexity is rated high.
How can I assess whether a request may have been crafted to exploit this behavior?
Inspect HTTP request data handled by the affected server or its front end for header values containing bare CR or LF characters, particularly where a subsequent header appears after that character. Such input can cause the front end and Twisted to frame the same request differently.