Psr7
Monthly
Host validation bypass in guzzlehttp/psr7 before 2.12.3 enables URI authority confusion attacks against PHP applications that rely on Uri::getHost() for security-critical decisions. The Uri::assertValidHost() method accepts host strings containing authority delimiters, embedded ports, or malformed IPv6 brackets, causing a semantic split where getHost() returns a sanitized value that disagrees with the actual URI authority used for routing - a classic CWE-436 interpretation conflict exploitable for SSRF allowlist bypass or host-based access control evasion. No public exploit has been identified at time of analysis; vendor-released patch version 2.12.3 resolves the issue.
CRLF injection in guzzlehttp/psr7 versions prior to 2.10.2 allows remote unauthenticated attackers to inject arbitrary HTTP headers into outbound requests by embedding carriage-return/line-feed sequences in a user-controlled URI host component. When a PSR-7 request is manually serialized into a raw HTTP/1.x message - for example via Message::toString() - the unvalidated host is copied verbatim into the Host header, enabling an attacker-supplied host like '"\r\nX-Injected: yes"' to append controlled headers to the serialized request. In deployments behind proxies, gateways, or load balancers with HTTP/1.1 connection reuse, this header injection can cascade into HTTP request smuggling or cache poisoning. No public exploit code has been identified at time of analysis, and exploitation through the standard Guzzle HTTP client API is explicitly not affected.
Host confusion in guzzlehttp/psr7 (all versions prior to 2.10.2) allows unauthenticated network attackers to supply a malformed Host header - such as `trusted.example@evil.example` - causing the library's URI construction logic to reinterpret the value as URI userinfo and a different host, silently replacing the parsed URI host with the attacker-controlled domain. Applications that rely on the resulting PSR-7 URI host for routing, allow-list enforcement, or forwarding decisions are at risk of sending requests and credentials to unintended destinations. No public exploit has been identified at time of analysis and no CISA KEV listing exists, but the conditional impact on forwarding gateways and API proxies built on psr7's server-request parsing functions is concrete.
Host validation bypass in guzzlehttp/psr7 before 2.12.3 enables URI authority confusion attacks against PHP applications that rely on Uri::getHost() for security-critical decisions. The Uri::assertValidHost() method accepts host strings containing authority delimiters, embedded ports, or malformed IPv6 brackets, causing a semantic split where getHost() returns a sanitized value that disagrees with the actual URI authority used for routing - a classic CWE-436 interpretation conflict exploitable for SSRF allowlist bypass or host-based access control evasion. No public exploit has been identified at time of analysis; vendor-released patch version 2.12.3 resolves the issue.
CRLF injection in guzzlehttp/psr7 versions prior to 2.10.2 allows remote unauthenticated attackers to inject arbitrary HTTP headers into outbound requests by embedding carriage-return/line-feed sequences in a user-controlled URI host component. When a PSR-7 request is manually serialized into a raw HTTP/1.x message - for example via Message::toString() - the unvalidated host is copied verbatim into the Host header, enabling an attacker-supplied host like '"\r\nX-Injected: yes"' to append controlled headers to the serialized request. In deployments behind proxies, gateways, or load balancers with HTTP/1.1 connection reuse, this header injection can cascade into HTTP request smuggling or cache poisoning. No public exploit code has been identified at time of analysis, and exploitation through the standard Guzzle HTTP client API is explicitly not affected.
Host confusion in guzzlehttp/psr7 (all versions prior to 2.10.2) allows unauthenticated network attackers to supply a malformed Host header - such as `trusted.example@evil.example` - causing the library's URI construction logic to reinterpret the value as URI userinfo and a different host, silently replacing the parsed URI host with the attacker-controlled domain. Applications that rely on the resulting PSR-7 URI host for routing, allow-list enforcement, or forwarding decisions are at risk of sending requests and credentials to unintended destinations. No public exploit has been identified at time of analysis and no CISA KEV listing exists, but the conditional impact on forwarding gateways and API proxies built on psr7's server-request parsing functions is concrete.