CVE-2026-49214: guzzlehttp/psr7 HTTP Header Injection via Untrusted URLs

Technical summary

The vulnerability exists in PSR-7 `Uri` and `Request` classes, which do not validate or reject ASCII control characters, whitespace, or DEL characters in the host component. When a malicious host string contains CRLF (`\r\n`), tab, NUL, or other header-unsafe characters, the library does not strip or escape them. If the application later serializes this request and sends it via an HTTP client that also lacks independent validation, the control characters cause the `Host` header to span multiple lines, enabling header injection. The root cause is insufficient input validation at the URI parsing layer (CWE-20) combined with improper neutralization of CRLF sequences (CWE-93) that could be exploited for HTTP response splitting and header injection (CWE-113).

Business impact

Applications relying on user-controlled URLs for outbound requests—including API gateways, webhook dispatchers, web crawlers, URL forwarding services, and proxy layers—can be compromised. An attacker gains the ability to inject arbitrary HTTP headers into requests your application sends on behalf of users or business logic. This can lead to cache poisoning (injecting malicious content into shared caches), request smuggling (causing upstream servers to misinterpret request boundaries), authentication bypass (spoofing headers like `Authorization` or `X-Forwarded-For`), or exfiltration of sensitive data. In supply-chain scenarios where your application forwards third-party requests, the risk extends beyond your infrastructure to downstream systems.

Affected systems

guzzlehttp/psr7 versions 2.10.1 and earlier are vulnerable. The 1.x branch is end-of-life and will not receive a patch. Any PHP application using psr7 to construct or manipulate HTTP requests from untrusted input is at risk. Common frameworks and libraries that depend on psr7 (such as Guzzle, Symfony HTTP Client, or Laravel) may inherit this vulnerability if they do not apply the patch or implement their own input validation. Organizations should audit their dependency trees to identify all affected packages.

Exploitability

Exploitation requires that an application accepts a user-controlled URL and uses it to build a PSR-7 request object without prior validation. The attack vector is network-based, requires no special privileges, and does not depend on user interaction. However, the vulnerability is not automatically weaponized; the attacker must find a vulnerable code path in a real application. Once identified, the exploit is straightforward: inject CRLF or other control characters into the host parameter. The downstream impact depends on whether the HTTP client or proxy infrastructure also validates headers; many modern HTTP clients do include protections, but older or misconfigured systems may be vulnerable to request smuggling or cache poisoning.

Remediation

Upgrade guzzlehttp/psr7 to version 2.10.2 or later immediately. If upgrading is not possible in the short term, implement strict input validation on all user-supplied URLs before constructing PSR-7 `Uri` or `Request` objects. Reject any URL that contains ASCII control characters (0x00–0x1F), DEL (0x7F), CRLF, tab, space, or other whitespace in the host component. Additionally, ensure that your HTTP client and any intermediate proxies or load balancers independently validate and reject malformed requests before they are transmitted. Review all code paths that accept untrusted URLs—particularly in webhook handlers, forwarding services, and crawler configurations—and add explicit validation layers.

Patch guidance

Apply guzzlehttp/psr7 version 2.10.2 or later. Verify the patch is available in your package manager (Composer for PHP) and test thoroughly in a staging environment before deploying to production. If your application uses a framework or library that depends on psr7, check that the parent package has also been updated; you may need to update Guzzle, Symfony, Laravel, or other dependent packages as well. The 1.x branch will not receive a patch, so users on that version should plan a migration to 2.x as part of their remediation strategy.

Detection guidance

Monitor logs for HTTP requests with unusual or suspicious `Host` headers that contain CRLF, control characters, or unexpected header-like patterns (e.g., strings containing `\r\n` or `X-` followed by header names). If your application logs serialized HTTP requests before transmission, look for requests where the `Host` header spans multiple lines or is followed by additional headers injected via the host parameter. Web application firewalls (WAFs) and HTTP proxies should reject requests with malformed `Host` headers. Additionally, review source code for calls to `Uri` or `Request` constructors that accept unsanitized user input, and check dependency versions using tools like `composer audit` or SBOM analysis.

Why prioritize this

This vulnerability merits prompt but measured attention. The CVSS score of 5.3 (MEDIUM) reflects that exploitation requires a vulnerable application code path and is not automatically critical. However, the attack vector is network-accessible and requires no authentication. Organizations that operate URL-based services, proxies, gateways, or webhook platforms should prioritize patching, as should those in regulated industries where request integrity and non-repudiation are important. Applications that only accept URLs from trusted internal sources face lower risk, but those accepting user or third-party URLs should patch within 30 days. The lack of KEV designation suggests active in-the-wild exploitation has not yet been widely reported, but the vulnerability is trivial to exploit once identified.

Risk score, explained

The CVSS 3.1 score of 5.3 assigns MEDIUM severity because the attack is network-accessible and requires no user interaction, but the impact is limited to integrity (header injection) with no direct confidentiality loss or availability impact in most deployments. The score does not account for downstream amplification (request smuggling, cache poisoning) that may occur in multi-tier HTTP infrastructures; your actual risk may be higher if you operate proxies, load balancers, or shared caches. The attack complexity is low (AC:L), meaning an attacker does not need to overcome special conditions, but the vulnerability requires a vulnerable application code pattern, not a flaw in psr7 alone.

Frequently asked questions