guzzlehttp/psr7 CVE-2026-49214

Exploitation requires all of the following specific conditions to be present simultaneously: (1) the application accepts a user-controlled URL as input (e.g., webhook target, proxy destination, crawl URL, forwarded request); (2) that URL is used to construct a PSR-7 Uri or Request object via guzzlehttp/psr7 version < 2.10.2; (3) the PSR-7 request is serialized into a raw HTTP/1.x byte stream - specifically through GuzzleHttp\Psr7\Message::toString() or a functionally equivalent custom serializer - and no explicit Host header is set before serialization; and (4) the downstream component receiving the serialized request does not independently validate or reject the malformed host. Applications using only Guzzle's standard HTTP client stack (GuzzleHttp\Client::request(), etc.) are explicitly excluded by the vendor as not expected to be vulnerable. The attack is limited to PHP applications with outbound request dispatch flows that manually serialize PSR-7 objects. No special attacker authentication is required; the attacker only needs the ability to supply a URL that the application will use for an outbound request.

The NVD-assigned CVSS 3.1 vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N scores 5.3 (Medium), but this assessment warrants scrutiny on two metrics. First, AC:L overstates ease of exploitation: the vulnerable code path requires manual PSR-7 serialization, a non-default usage pattern explicitly called out in the advisory as distinct from the standard Guzzle client stack. Applications using only Guzzle's standard HTTP client APIs are explicitly not expected to be affected. This substantially narrows the affected population and argues for AC:H in a realistic model. Second, S:U (Unchanged scope) is conservative - the advisory explicitly notes that this malformed request can contribute to request smuggling and cache poisoning in proxy chains, which affects systems beyond the vulnerable application, suggesting a Scope:Changed scenario in those deployments. There is no CISA KEV entry and no confirmed public exploit code, so exploitation probability is currently theoretical. EPSS data was not provided in the input - exploitation likelihood cannot be quantified from available signals. The realistic priority is moderate for applications that manually serialize PSR-7 requests with user-supplied URLs; it is low-to-negligible for the majority of Guzzle users operating through the standard client API.

An attacker submitting a webhook URL or crawl target to a PHP application sends a crafted URL with a host component containing '\r\nX-Forwarded-For: 127.0.0.1\r\nX-Internal-Auth: true'. The application constructs a PSR-7 Request from this URL without sanitizing the host, then serializes it with Message::toString() or a custom transport that writes raw HTTP/1.x to a backend proxy. The proxy interprets the injected CRLF as header boundaries, receiving a request that appears to carry attacker-fabricated headers, enabling cache poisoning of shared responses or bypassing IP-based access controls in multi-tier architectures. No public exploit code has been identified at time of analysis, but the attack primitive is well-understood and reproducible from the advisory description alone.