guzzlehttp/psr7 CVE-2026-55766

Exploitation requires all three of the following conditions to be simultaneously true. First, attacker-controlled data must reach one of exactly three HTTP start-line fields - the request method, the HTTP protocol version string, or the response reason phrase; header fields are not affected because they had pre-existing validation. Second, the application must serialize the resulting PSR-7 object to raw HTTP/1.x bytes, either via Message::toString(), an equivalent serializer, or by reparsing a malformed raw message through Message::parseRequest()/Message::parseResponse() and then re-emitting it. Third, the serialized bytes must be consumed by a downstream HTTP/1.1 component that does not independently reject malformed start lines. The vendor explicitly states that applications using guzzlehttp/psr7 only through Guzzle's standard high-level HTTP client APIs are not expected to be affected, since those code paths do not expose start-line fields to untrusted input in the serialization pathway. Exploitation is therefore limited to custom transports, proxying, crawling, webhook delivery, raw message forwarding, or test harnesses - not typical application HTTP client usage. The CVSS AC:H metric reflects these compound preconditions.

The NVD-assigned CVSS 3.1 score of 4.8 (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N) is defensible: network-reachable without authentication, but AC:H correctly captures the multiple concurrent preconditions required for exploitation. Real-world risk is strongly deployment-context-dependent. Applications using only Guzzle's high-level HTTP client APIs are explicitly out of scope per vendor advisory, substantially limiting the affected population. The most exposed deployments are PHP-based reverse proxies, webhook relay services, crawlers, or test harnesses that accept external input into start-line fields and re-serialize PSR-7 messages. The potential downstream impacts - request smuggling and cache poisoning in particular - can be severe in those contexts and disproportionate to the moderate CVSS score. No EPSS score is available in the provided data, so exploitation probability cannot be quantified numerically. The vulnerability is not listed in CISA KEV, and no POC exploit code has been identified, indicating no confirmed active exploitation at time of analysis. The gap between raw CVSS and actual risk is primarily determined by whether an application's code touches the serialization pathway with untrusted start-line data.

An attacker targeting a PHP webhook relay service sends an HTTP request with a crafted method string such as GET X-Forwarded-For: attacker-host to an endpoint that stores the method in a PSR-7 Request object and then forwards it by calling Message::toString() over a keep-alive connection to an upstream server. The upstream HTTP/1.1 parser, processing the serialized bytes, interprets the injected CRLF as a header boundary and treats X-Forwarded-For: attacker-host as a legitimate header, enabling header spoofing or, in a shared-connection context, request smuggling that desynchronizes the upstream parser and poisons the request queue for subsequent users. No public exploit code has been identified at time of analysis, but the attack pattern is well-understood from prior CRLF injection research.