EUVD-2026-38458
GHSA-vm85-hxw5-5432
Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
Network-reachable without authentication (AV:N/PR:N), but AC:H reflects three mandatory concurrent preconditions; integrity and confidentiality limited to header-level manipulation with no availability impact.
Primary rating from Vendor (https://github.com/guzzle/psr7).
CVSS VectorVendor: https://github.com/guzzle/psr7
Lifecycle Timeline
2DescriptionCVE.org
Impact
guzzlehttp/psr7 did not reject CR/LF characters in certain first-party HTTP start-line fields: the request method, protocol version, and response reason phrase. If an application placed attacker-controlled data into one of those fields and later serialized the PSR-7 message as raw HTTP/1.x, for example with Message::toString() or an equivalent serializer, the serialized message could contain attacker-controlled header lines. The issue can also be reached through Message::parseRequest() or Message::parseResponse() when malformed raw messages are parsed into first-party PSR-7 objects and then serialized again.
Creating or modifying a Request, Response, or other PSR-7 object alone is not sufficient. The issue requires the malformed message to be serialized and written to the network, forwarded, replayed, or otherwise processed by software that does not independently reject the malformed start line. This is not the normal request-sending path used by guzzlehttp/guzzle; applications using guzzlehttp/psr7 only through Guzzle's standard HTTP client APIs are not expected to be affected.
Applications are most likely to be affected when they manually serialize PSR-7 messages, forward raw HTTP messages, or use custom transports, proxying, crawling, webhook delivery, testing, or similar code. Depending on how downstream HTTP/1.1 components parse the serialized message, this may lead to header injection, response splitting, request smuggling, or cache poisoning.
Patches
The issue is patched in 2.12.1 and later. Starting in that release, guzzlehttp/psr7 rejects CR/LF characters in HTTP method, protocol version, and response reason phrase values before storing them in first-party message objects.
Workarounds
If you cannot upgrade immediately, reject CR/LF in untrusted method, protocol version, and reason phrase values before constructing or modifying PSR-7 messages.
Applications that parse, forward, replay, or serialize raw HTTP messages cannot work around the parser entry points by validating only after parsing. They should validate the raw start line before calling Message::parseRequest() or Message::parseResponse(), avoid reparsing untrusted raw messages, or upgrade. If an application runs with attacker-controlled synthetic $_SERVER values, validate REQUEST_METHOD and SERVER_PROTOCOL before calling ServerRequest::fromGlobals().
AnalysisAI
CRLF injection in guzzlehttp/psr7 (all versions prior to 2.12.1) enables header injection, response splitting, request smuggling, or cache poisoning when attacker-controlled data reaches the HTTP start-line fields - request method, protocol version, or response reason phrase - and the resulting PSR-7 object is serialized to raw HTTP/1.x. The vulnerability is confined to the serialization pathway: standard Guzzle HTTP client usage is explicitly not affected, but proxies, crawlers, webhook delivery systems, and custom transports that call Message::toString(), Message::parseRequest(), or Message::parseResponse() and re-emit the raw bytes are at direct risk. No public exploit has been identified at time of analysis, and the vendor has released a confirmed patch in version 2.12.1.
Technical ContextAI
CWE-93 (Improper Neutralization of CRLF Sequences) describes the root cause: HTTP/1.x uses bare CR (\r) and LF (\n) as structural delimiters between headers and between the start line and header block, so permitting these characters inside a start-line field allows an attacker to synthesize additional header lines in the serialized output. The affected package is guzzlehttp/psr7 (Composer package pkg:composer/guzzlehttp_psr7), a widely-deployed PHP implementation of the PSR-7 HTTP Message Interface standard. Prior to 2.12.1, the library applied CR/LF validation to header name and value fields but omitted equivalent checks for three start-line components: the HTTP method, the protocol version string, and the response reason phrase. The flaw surfaces through both construction paths (new Request(...), new Response(...)) and parse paths (Message::parseRequest(), Message::parseResponse()), as well as ServerRequest::fromGlobals() when $_SERVER values are attacker-influenced.
RemediationAI
Upgrade guzzlehttp/psr7 to version 2.12.1 or later via composer update guzzlehttp/psr7; this is the vendor-confirmed fix that rejects CR/LF characters in HTTP method, protocol version, and reason phrase before storing them in PSR-7 message objects (vendor advisory: https://github.com/guzzle/psr7/security/advisories/GHSA-vm85-hxw5-5432). If immediate upgrade is not feasible, apply input sanitization at every entry point: strip or reject CR (\r) and LF (\n) from untrusted method, protocol version, and reason phrase values before passing them to PSR-7 constructors or setter methods. For raw-message parse paths, validate the raw HTTP start line before calling Message::parseRequest() or Message::parseResponse() - post-parse validation is insufficient because injected bytes are already embedded in the object. If the application uses ServerRequest::fromGlobals(), validate $_SERVER['REQUEST_METHOD'] and $_SERVER['SERVER_PROTOCOL'] for CR/LF before that call. The workaround requires covering all code paths that accept external data into start-line fields; missing a single path leaves the injection surface open, so upgrade is strongly preferred over relying solely on workarounds.
Same technique Code Injection
View allShare
External POC / Exploit Code
Leaving vuln.today