CVE-2026-48998: guzzlehttp/psr7 Host Header Validation Bypass (CVSS 5.3)

Technical summary

CVE-2026-48998 involves improper validation of the Host header in guzzlehttp/psr7 versions before 2.10.2. When parsing raw HTTP request messages via `GuzzleHttp\Psr7\Message::parseRequest()` or the legacy `parse_request()` function, or when constructing server requests from untrusted server variables, the library fails to reject Host headers containing URI authority delimiters (specifically userinfo markers such as `@`). This allows an attacker-controlled Host header to be reinterpreted during URI construction: the substring before the delimiter may be treated as userinfo rather than a hostname component, causing the derived URI host to diverge from the original Host header value. The vulnerability is rooted in CWE-20 (improper input validation) and CWE-918 (server-side request forgery), though the latter applies when the misrouted request reaches an external destination.

Business impact

Applications most at risk are those that use guzzlehttp/psr7 to parse untrusted HTTP request data or build server requests from user-supplied variables, then depend on the resulting URI host for security decisions. High-risk scenarios include: API gateways or reverse proxies that forward requests based on the Host header; microservice routing that relies on parsed Host values for access control; and forwarding proxies or load balancers that need to route to the correct backend. A successful exploit could result in credential leakage (if the application forwards authentication tokens to the wrong host), unauthorized access to internal or partner services (via SSRF-like behavior), or cache poisoning if the application caches responses keyed by Host. The impact is most severe in infrastructure and integration layers rather than monolithic applications.

Affected systems

Any PHP application using guzzlehttp/psr7 versions prior to 2.10.2 is affected if it processes attacker-controlled HTTP requests or server variables and makes routing or security decisions based on the parsed Host. Version 1.x of guzzlehttp/psr7 is end-of-life and will not receive a patch, leaving those users to implement workarounds. Applications using only the library for client-side HTTP requests (outbound calls) are at lower risk unless they also parse inbound requests.

Exploitability

The vulnerability has a CVSS 3.1 score of 5.3 (MEDIUM severity) with a network-based, unauthenticated attack vector requiring no user interaction. This reflects the straightforward nature of the exploit: an attacker simply needs to send a malformed Host header to an affected application. However, exploitation impact depends on application architecture. Applications that blindly trust the parsed Host for routing or forwarding are vulnerable immediately; those with additional validation layers (e.g., DNS resolution, certificate pinning, or allow-list enforcement) may be partially protected. The vulnerability is not currently listed on CISA's Known Exploited Vulnerabilities catalog.

Remediation

Upgrade guzzlehttp/psr7 to version 2.10.2 or later. Applications on version 1.x must either migrate to version 2.x (which will be updated) or implement the recommended workaround: validate the Host header as a valid `uri-host` optionally followed by a port before passing raw requests to `Message::parseRequest()` or `parse_request()`. Specifically, reject any Host value containing userinfo delimiters (`@`), path delimiters (`/`), query delimiters (`?`), or fragment delimiters (`#`). This validation should occur before the Host is used for any routing, allow-listing, or forwarding decision.

Patch guidance

Update guzzlehttp/psr7 to version 2.10.2 via Composer: `composer update guzzlehttp/psr7`. Verify the update in your lock file. If you are on version 1.x, evaluate the effort and risk of upgrading to 2.x versus implementing host-header validation as a workaround. Test the patch in a staging environment to ensure no legitimate requests (e.g., with unusual but valid Host formats) are rejected by your application's Host validation logic.

Detection guidance

Monitor application logs and HTTP request logs for Host headers containing the `@` character, especially in patterns like `hostname@otherhostname`. If your application runs behind a proxy or load balancer, check upstream logs as well. Review routing and forwarding decisions to see if any requests have been sent to unexpected destinations. Inspect API gateway and reverse-proxy configurations to confirm they do not rely solely on the Host header without additional validation. If you parse raw HTTP requests, audit code paths that use `Message::parseRequest()` or `parse_request()` on untrusted input.

Why prioritize this

This vulnerability should be prioritized if your organization operates API gateways, reverse proxies, microservice routers, or other forwarding infrastructure that depends on the Host header for routing decisions. It is also relevant if you accept raw HTTP requests from untrusted sources. The MEDIUM CVSS score reflects the need for specific application patterns to be exploitable, but the potential impact in infrastructure contexts justifies prompt patching. Organizations running stateless, single-tenant, or client-only HTTP applications may deprioritize this, but should still patch as part of routine maintenance.

Risk score, explained

The CVSS 3.1 base score of 5.3 (MEDIUM) is driven by a network-based attack vector with low complexity and no privileges or user interaction required (AV:N/AC:L/PR:N/UI:N). The impact vector (S:U/C:L/I:N/A:N) indicates low confidentiality impact (credentials or sensitive data may be leaked) with no integrity or availability impact. The score reflects the fact that exploitation depends on the application's trust model and architecture, not on the vulnerability being universally exploitable. High-risk deployments (gateways, proxies) should treat this as higher priority despite the MEDIUM baseline.

Frequently asked questions