Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact guzzlehttp/psr7 did not reject URI host components containing authority delimiters (/, ?, #, @, or \), an embedded port such as host:8080, or IPv6 brackets that do not frame the host (such as [::1 or ::1]). Uri::assertValidHost() rejected only control characters, so these malformed hosts were accepted both when parsing a URI string — including through new Uri(), an absolute-form request target passed to Message::parseRequest(), and the synthetic SERVERNAME or SERVERADDR fallback used by ServerRequest::fromGlobals() — and when setting a host with Uri::withHost(). Because the stored host was not validated, Uri::getHost() could return a value that does not agree with the URI's authority or with the host that is actually used on the wire. For example, Uri::withHost('good.com@evil.com') is accepted, and new Uri('http://[gggg::1]/') produces a getHost() of 'gggg:' while getAuthority() returns '[gggg::1'. You are affected if your application builds a Uri or calls Uri::withHost()…
Recommended action: Upgrade to 2.12.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact guzzlehttp/psr7 did not reject CR/LF characters in certain first-party HTTP start-line fields: the request method, protocol version, and response reason phrase. If an application placed attacker-controlled data into one of those fields and later serialized the PSR-7 message as raw HTTP/1.x, for example with Message::toString() or an equivalent serializer, the serialized message could contain attacker-controlled header lines. The issue can also be reached through Message::parseRequest() or Message::parseResponse() when malformed raw messages are parsed into first-party PSR-7 objects and then serialized again. Creating or modifying a Request, Response, or other PSR-7 object alone is not sufficient. The issue requires the malformed message to be serialized and written to the network, forwarded, replayed, or otherwise processed by software that does not independently reject the malformed start line. This is not the normal request-sending path used by guzzlehttp/guzzle;…
Recommended action: Upgrade to 2.12.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact guzzlehttp/psr7 improperly interpreted malformed Host header values when constructing request URIs from inbound request data. This issue concerns inbound request parsing and server request construction. It does not require serializing a PSR-7 request, and it is not part of the normal outbound request-sending path used by guzzlehttp/guzzle. A vulnerable flow is: 1. An attacker controls a raw HTTP request or server variable containing a Host value. 2. The Host value contains URI authority delimiters, such as trusted.example@evil.example. 3. guzzlehttp/psr7 uses that value to construct a URI. 4. The URI parser treats the portion before @ as userinfo and the portion after @ as the URI host. 5. The resulting PSR-7 request URI host differs from the original Host header value. For example, Host: trusted.example@evil.example can result in a PSR-7 URI whose host is evil.example, while the original Host header value remains trusted.example@evil.example. Applications are affected if they…
Recommended action: Upgrade to 2.10.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact guzzlehttp/psr7 did not reject ASCII control characters, whitespace, or DEL in first-party URI host components. The issue requires a PSR-7 request to be serialized into a raw HTTP/1.x message, for example with GuzzleHttp\Psr7\Message::toString() or an equivalent custom serializer. Creating a Uri, Request, or other PSR-7 object alone is not sufficient. The malformed host must be copied into the serialized Host header without further validation. A vulnerable flow is: 1. An application accepts a user-controlled URL. 2. The URL is used to construct a PSR-7 Uri or Request. 3. The host component contains CRLF or another header-unsafe character. 4. The request is serialized into a raw HTTP/1.x message without an explicit Host header. 5. The host is copied into the serialized Host header. 6. The serialized request is written to the network or otherwise processed by software that does not independently reject the malformed host. In that flow, an attacker can cause the serialized…
Recommended action: Upgrade to 2.10.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Improper header parsing. An attacker could sneak in a newline (\n) into both the header names and values. While the specification states that \r\n\r\n is used to terminate the header list, many servers in the wild will also accept \n\n. Patches The issue is patched in 1.9.1 and 2.4.5. Workarounds There are no known workarounds. References https://www.rfc-editor.org/rfc/rfc7230#section-3.2.4
Recommended action: Upgrade to 2.4.5 or 1.9.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Improper header parsing. An attacker could sneak in a carriage return character (\r) and pass untrusted values in both the header names and values. Patches The issue is patched in 1.8.4 and 2.1.1. Workarounds There are no known workarounds. References https://www.rfc-editor.org/rfc/rfc7230#section-3.2.4
Recommended action: Upgrade to 2.1.1 or 1.8.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.