Grahamcampbell

**Name of the Vulnerable Software and Affected Versions** guzzlehttp/guzzle versions prior to 7.14.2 **Description** The built-in cURL handlers (`CurlHandler` and `CurlMultiHandler`) fail to properly isolate `Proxy-Authorization` headers from origin servers. This occurs because the handlers place first-class request headers into the origin header list (`CURLOPT HTTPHEADER`) and only move them to the proxy-only list (`CURLOPT PROXYHEADER`) when an HTTP or HTTPS proxy is predicted. Consequently, proxy credentials may be sent to the origin server if the request is direct, bypassed via `no proxy` settings, sent through a SOCKS proxy, or redirected from a proxied hop to a non-proxied route. On systems with libcurl older than 7.37.0 or PHP cURL extensions lacking `CURLOPT PROXYHEADER`, `CURLOPT HEADEROPT`, and `CURLHEADER SEPARATE`, no proxy-only channel is available, leaving the header in the origin list for all routes. Additionally, the stream handler may expose credentials when combined with raw `stream context.http.proxy` overrides. An attacker controlling the origin server can capture these private credentials through access logs or tracing systems. This could allow the attacker to abuse access-controlled proxies or impersonate the proxy principal. **Recommendations** Update guzzlehttp/guzzle to version 7.14.2. As a temporary workaround, remove first-class `Proxy-Authorization` fields from requests, client defaults, and middleware, and instead provide proxy credentials via proxy URL userinfo (e.g., `http://user:pass@proxy.example:8080`) or use `CURLOPT PROXYUSERPWD` with cURL handlers. Avoid combining proxy URL userinfo with first-class fields or raw `stream context.http.proxy` overrides.

**Name of the Vulnerable Software and Affected Versions** guzzlehttp/guzzle versions prior to 7.15.1 **Description** The `CookieJar` component fails to preserve the host-only scope of response cookies that are set without a `Domain` attribute or with an empty one. Instead of marking these cookies as host-only, the software stores the request host in the `Domain` field. This behavior allows cookies intended exclusively for a parent host to be sent to child hosts if the same cookie jar is reused across different trust boundaries. An attacker controlling a child host could potentially intercept sensitive information, such as session identifiers and authorization tokens. This issue affects `FileCookieJar` and `SessionCookieJar` as well, as they persist the request host without recording the host-only state. The vulnerability is triggered when an application enables cookie support, reuses a built-in cookie jar, and makes requests to both a trusted parent host and a less-trusted child host. **Recommendations** Update guzzlehttp/guzzle to version 7.15.1 or later. As a temporary workaround, avoid reusing a single `CookieJar` instance across parent and child hosts with different trust levels. Use a separate cookie jar for each host or trust boundary. Disable cookie handling for requests made to less-trusted hosts. Avoid using `new Client(['cookies' => true])` for clients that contact both trusted parent hosts and less-trusted subdomains. Delete or rotate existing `FileCookieJar` and `SessionCookieJar` data that was written by versions prior to 7.15.1.

**Name of the Vulnerable Software and Affected Versions** guzzlehttp/guzzle versions prior to 7.15.1 **Description** An information disclosure issue exists in the `RedirectMiddleware` when the optional `allow redirects.referer` setting is enabled. During a same-scheme redirect (such as HTTPS to HTTPS), the middleware copies the URI fragment—the portion of the URI following the `#` symbol—into the generated `Referer` header. While URI fragments are typically handled locally by the client and not sent to the server in the initial request, this behavior allows a destination server controlling the redirect to read the fragment from the incoming header. This could lead to the disclosure of sensitive client data, such as access tokens, state values, or one-time login secrets. This issue affects both cURL and stream handlers. The `referer` setting is disabled by default. **Recommendations** Update guzzlehttp/guzzle to version 7.15.1 or later. As a temporary workaround, ensure the `allow redirects.referer` setting is set to `false`. Alternatively, disable automatic redirects and follow trusted destinations manually, or remove the fragment from the request URI before sending a request that may redirect.

**Name of the Vulnerable Software and Affected Versions** guzzlehttp/guzzle versions prior to 7.15.1 **Description** A denial of service issue exists in the `CookieJar` component. The system accepts an unlimited number of `Set-Cookie` header fields without size restrictions. A malicious server can return numerous large cookies, forcing the application to store excessive data in memory and generate oversized `Cookie` headers. This can lead to increased memory consumption, higher processing times, and request failures when the generated header exceeds the limits of a handler, HTTP implementation, proxy, or destination server. Additionally, a server on a sibling host can set parent-domain cookies that affect other sibling services using the same jar. This issue occurs when built-in cookie support is enabled and a jar is reused after receiving an attacker-controlled response. **Recommendations** Update guzzlehttp/guzzle to version 7.15.1 or later. As a temporary workaround, avoid enabling a shared built-in cookie jar for requests to untrusted origins. Use separate jars per host or trust boundary. Disable cookie handling for untrusted requests. Discard or clear the jar after receiving an untrusted response before it is reused. Implement a custom `CookieJarInterface` to enforce suitable limits if cookies from untrusted peers must be accepted.

**Name of the Vulnerable Software and Affected Versions** guzzlehttp/psr7 versions prior to 2.12.3 **Description** The `Uri::assertValidHost()` function fails to reject URI host components that contain authority delimiters, embedded ports, or malformed IPv6 brackets. This discrepancy allows `Uri::getHost()` to return a value that differs from the URI authority used for routing or security decisions. **Recommendations** Update to version 2.12.3.

**Name of the Vulnerable Software and Affected Versions** Guzzle versions prior to 7.12.3 **Description** The `CookieJar` component fails to restrict cookies scoped to IP addresses or bare-numeric Domain values to the specific host that issued them. This occurs because the `matchesDomain()` function applies ordinary suffix matching to domains such as `192.168.0.1`, `[::1]`, or `1`. This behavior can lead to session fixation, cookie injection, or cross-host cookie disclosure. **Recommendations** Update to version 7.12.3.

**Name of the Vulnerable Software and Affected Versions** Guzzle versions prior to 7.12.1 **Description** In certain configurations, traffic intended to be protected by TLS on the hop to the proxy is transmitted in cleartext. This occurs when an application uses the built-in cURL handlers (`GuzzleHttpHandlerCurlHandler` and `GuzzleHttpHandlerCurlMultiHandler`) with an `https://` proxy while running on libcurl versions older than 7.50.2, which silently treat HTTPS proxies as plaintext HTTP proxies. Consequently, proxy authentication credentials—including the `Proxy-Authorization` header, proxy userinfo in the proxy URL, or `CURLOPT PROXYUSERPWD`—are sent without encryption. Additionally, the `CONNECT` target host and port for tunneled HTTPS requests are exposed, and for plain HTTP requests, both headers and bodies are exposed on the proxy leg. **Recommendations** Update Guzzle to version 7.12.1 or later. As a temporary workaround, do not configure an `https://` proxy on installations where libcurl lacks HTTPS-proxy support and verify the capability in application code before use. Upgrade the system libcurl to version 7.52.0 or newer built with HTTPS-proxy support.

**Name of the Vulnerable Software and Affected Versions** Laminas Diactoros versions 2.18.0 and prior, 2.19.0, 2.20.0, 2.21.0, 2.22.0, 2.23.0, 2.24.0, and 2.25.0 **Description** The issue is related to improper header parsing, where an attacker could sneak in a newline into both the header names and values, potentially leading to denial of service vectors or application errors. This can occur when users create HTTP requests or responses using laminas/laminas-diactoros and provide a newline at the start or end of a header key or value, causing an invalid message. **Recommendations** For versions 2.18.0 and prior, 2.19.0, 2.20.0, 2.21.0, 2.22.0, 2.23.0, 2.24.0, and 2.25.0, update to the patched versions 2.18.1, 2.19.1, 2.20.1, 2.21.1, 2.22.1, 2.23.1, 2.24.1, and 2.25.1 respectively. As a temporary workaround, validate HTTP header keys and/or values, and if using user-supplied values, filter them to strip off leading or trailing newline characters before calling `withHeader()`.

**Name of the Vulnerable Software and Affected Versions** slim/psr7 versions prior to 1.6.1 **Description** The issue allows an attacker to sneak in a newline (` `) into both the header names and values. Although the specification states that `r r ` is used to terminate the header list, many servers also accept ` `. This could enable an attacker to craft invalid messages, potentially causing application errors or invalid HTTP requests being sent out with a PSR-18 HTTP client. The latter might present a denial of service vector if a remote service's web application firewall bans the application due to the receipt of malformed requests. **Recommendations** For versions prior to 1.6.1, upgrade to version 1.6.1 to resolve the issue. As a temporary workaround, consider restricting the input of header names to prevent the introduction of newlines (` `) until the upgrade is applied.

**Name of the Vulnerable Software and Affected Versions** Guzzle versions prior to 6.5.8 Guzzle versions prior to 7.4.5 **Description** Guzzle, an extensible PHP HTTP client, has a issue where `Authorization` and `Cookie` headers on requests are sensitive information. In affected versions, when making a request that responds with a redirect to a URI with a different port, if the redirect is followed, the `Authorization` and `Cookie` headers should be removed from the request before proceeding. Previously, only changes in host or scheme would trigger this removal. **Recommendations** For Guzzle 7 users, upgrade to version 7.4.5 as soon as possible. For users of any earlier series of Guzzle, upgrade to version 6.5.8 or 7.4.5. As a temporary workaround, consider using your own redirect middleware instead of the default one if you are unable to upgrade. If redirects are not required or expected, consider disabling redirects altogether.

**Name of the Vulnerable Software and Affected Versions** guzzlehttp/psr7 versions prior to 1.9.1 guzzlehttp/psr7 versions prior to 2.4.5 **Description** The issue concerns improper header parsing, allowing an attacker to sneak in a newline (` `) into both the header names and values. Many servers will also accept ` ` to terminate the header list, which is not in line with the specification that states `r r ` should be used. This could potentially lead to application errors or invalid HTTP requests being sent out, possibly causing a denial of service vector if a remote service's web application firewall bans the application due to the receipt of malformed requests. **Recommendations** For guzzlehttp/psr7 versions prior to 1.9.1, upgrade to version 1.9.1 or later. For guzzlehttp/psr7 versions prior to 2.4.5, upgrade to version 2.4.5 or later. As a temporary workaround, consider validating HTTP header keys and/or values, and if using user-supplied values, filter them to strip off leading or trailing newline characters before processing.