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
14 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact In affected versions, Guzzle gives a transport the request URI as text and supplies the Host header separately. The cURL handlers set CURLOPTURL to the URI exactly as written and push that Host into CURLOPTHTTPHEADER; StreamHandler does the same through fopen(). libcurl then parses the authority itself, percent-decoding it and, on an IDN-capable build, applying IDNA mapping, and uses the result to resolve, connect, name the TLS peer and address a proxy CONNECT, while the supplied Host suppresses the aligned one it would have generated. In http://127.0.0.%31/ the URI host is one filtervar() rejects as an IP literal, yet libcurl decodes it to 127.0.0.1 and reaches loopback with no DNS lookup while the server receives Host: 127.0.0.%31. An attacker who influences a fetched URI can therefore reach a host the application's checks excluded and read whatever it exposes of the response. The same divergence moves Guzzle's own decisions onto a spelling the transport does not use:…
Recommended action: Upgrade to 8.0.1 or 7.15.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact SetCookie::matchesDomain() gives every subdomain of a cookie Domain that cookie unless it recognizes the Domain as an IP literal or a numeric host, and it decides that from the domain's own text, so two spellings a transport reads as an address keep subdomain scope. On 7.15, hexadecimal and mixed-base forms such as 0x7f000001 and 0177.0.0.0x1 go unrecognized while libcurl 8.21.0 reads both as 127.0.0.1, so closing them completes the rule GHSA-g446-98w2-8p5w (CVE-2026-59883) set out to establish, which cited the WHATWG IPv4 parser and so already admitted a 0x part. A percent-escaped Domain keeps that scope on both branches for a different reason: percent-decoding sits above numeric parsing, so 192.168.0.%31 and 127.0.0.1%2e are registered names in the URI grammar rather than address literals, and no numeric rule in any base classifies them, while libcurl decodes the host before it resolves and reads them as 192.168.0.1 and 127.0.0.1. The escape must fall in the rightmost label…
Recommended action: Upgrade to 8.0.1 or 7.15.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When the optional referer redirect setting is enabled, affected versions of RedirectMiddleware can copy the fragment from the referring request URI into a generated Referer header. A URI fragment is the part after #. It is handled locally by the client and is not part of the HTTP request target, so the server handling the original request does not receive it. A generated Referer tells the redirect destination which URI led to the request. Guzzle correctly removes user information from that value, but retains the fragment when it follows a redirect to the same scheme, such as HTTPS to HTTPS. For example, an initial URI ending in #secret is sent without the fragment, but the redirect destination can receive a Referer ending in #secret. This behavior affects both the cURL and stream handlers. An attacker who controls the redirect destination can read the fragment from the incoming header, including through request logs or application code. If the fragment contains a one-time…
Recommended action: Upgrade to 7.15.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In affected versions, CookieJar does not preserve whether a response cookie was set without a Domain attribute or with an empty one. A cookie without Domain is host-only and must be returned only to the exact host that set it. Under current cookie processing rules, an empty Domain value is also host-only. Guzzle instead stores the request host in the cookie's Domain field and later applies ordinary domain matching, as though the server had supplied a valid domain. For example, a host-only sid=secret cookie set by example.com can subsequently be sent to child.example.com. FileCookieJar and SessionCookieJar also persist the request host without recording the host-only state, so reloading a jar preserves the widened scope. An attacker who controls or can observe a child host can therefore receive cookies that were intended only for its parent host. Depending on the cookie, this can disclose session identifiers, authorization tokens, or other sensitive state. Exploitation requires…
Recommended action: Upgrade to 7.15.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In affected versions, Guzzle's built-in CookieJar accepts any number of Set-Cookie header fields from one response, with no limit on the size of each field. When a later request matches the stored cookies, Guzzle places every match into one generated Cookie header without limiting the number of cookies or the total header length. A malicious or compromised server can therefore return many large cookies, causing Guzzle to store attacker-controlled data in memory and copy it into later request headers. This can increase memory use and processing time. It can also make later requests fail when the generated header exceeds a limit in a handler, HTTP implementation, proxy, or destination server. A server on one sibling host, such as attacker.example.com, can also set parent-domain cookies that are later selected for another sibling, such as service.example.com. The denial can therefore affect a different service that uses the same jar. An application is affected when it enables the…
Recommended action: Upgrade to 7.15.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact CookieJar does not restrict a cookie scoped to an IP address to the exact host that set it. When a stored cookie's Domain attribute is an IPv4 literal (Domain=192.168.0.1), a bracketed IPv6 literal (Domain=[::1]), or a bare numeric value that denotes an IPv4 address (Domain=1, which is 0.0.0.1), SetCookie::matchesDomain() applies ordinary subdomain (suffix) matching to it instead of requiring an exact host. The IP-address check inside matchesDomain() is applied only to the request host and never to the cookie's own domain, and response cookies that carry an explicit Domain attribute are stored as suffix-matchable. As a result Guzzle sends such a cookie to any host whose name ends in that value as a trailing label, for example sending a Domain=192.168.0.1 cookie to evil.192.168.0.1, or a Domain=1 cookie to evil.1. The same flaw lets a look-alike host store a cookie that Guzzle then sends to the bare IP address. Depending on how the receiving service interprets the cookie, the…
Recommended action: Upgrade to 7.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 In affected versions, the built-in cURL handlers (CurlHandler and CurlMultiHandler) put every first-class request header in cURL's origin header list (CURLOPTHTTPHEADER). These handlers are the default when the PHP cURL extension is available. They move Proxy-Authorization to the proxy-only list (CURLOPTPROXYHEADER) only when Guzzle predicts an HTTP or HTTPS proxy. A "first-class" header is part of the normal request message and can be set on a PSR-7 request, through client headers defaults, the headers request option, or middleware. It does not include a literal line supplied through raw CURLOPTHTTPHEADER, CURLOPTPROXYHEADER, or streamcontext.http.header controls. Because that migration follows Guzzle's prediction rather than the route libcurl actually takes, the credential stays in the origin list and is sent to the origin server when a request is: - direct, including proxy set to '' to disable proxying. - bypassed by a no, noproxy, or NOPROXY match. - sent through a SOCKS…
Recommended action: Upgrade to 7.14.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact CookieJar incorrectly accepts cookies with a dot-only Domain attribute, such as Domain=., Domain=.., Domain=..., and whitespace-padded variants such as Domain= . . In affected versions, SetCookie::matchesDomain() removes leading dots from the cookie domain, normalizing dot-only values to the empty string; SetCookie::validate() only rejected a strictly empty domain, so these cookies could be stored and the empty normalized domain was treated as matching any request host. An attacker-controlled origin that an application requests with a shared cookie jar can therefore set a cookie that Guzzle later sends to unrelated hosts using the same jar. This may allow cookie injection or session fixation against downstream services, depending on how those services interpret the injected cookie. Applications are affected when they use Guzzle's cookie support, for example new Client(['cookies' = true]) or an explicit shared CookieJar, and reuse the same jar across attacker-controlled and…
Recommended action: Upgrade to 7.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 The built-in cURL handlers (GuzzleHttp\Handler\CurlHandler and GuzzleHttp\Handler\CurlMultiHandler, used by default whenever the PHP cURL extension is available) accept an https:// proxy — a proxy reached over a TLS-encrypted connection — through the proxy request option, client-level proxy defaults, or proxy environment variables such as httpproxy, httpsproxy, HTTPSPROXY, allproxy, and ALLPROXY. When the installed libcurl does not support HTTPS proxies, behavior depends on the libcurl version/build: - libcurl older than 7.50.2 silently treats an https:// proxy as a plaintext http:// proxy. The TLS connection to the proxy is never established, and the proxy leg is cleartext with no error or warning. - libcurl 7.50.2 through 7.51.x rejects the unsupported proxy scheme at connect time, so no cleartext exposure occurs, but the failure is late and opaque. - libcurl 7.52.0 or newer builds without HTTPS-proxy support also fail at connect time rather than downgrading. The…
Recommended action: Upgrade to 7.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 Authorization and Cookie headers on requests are sensitive information. On making a request which responds with a redirect to a URI with a different port, if we choose to follow it, we should remove the Authorization and Cookie headers from the request, before containing. Previously, we would only consider a change in host or scheme downgrade. Now, we consider any change in host, port or scheme to be a change in origin. Patches Affected Guzzle 7 users should upgrade to Guzzle 7.4.5 as soon as possible. Affected users using any earlier series of Guzzle should upgrade to Guzzle 6.5.8 or 7.4.5. Workarounds An alternative approach would be to use your own redirect middleware, rather than ours, if you are unable to upgrade. If you do not require or expect redirects to be followed, one should simply disable redirects all together. References RFC9110 Section 15.4 CVE-2022-27776 For more information If you have any questions or comments about this advisory, please get in touch with us…
Recommended action: Upgrade to 7.4.5 or 6.5.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Authorization headers on requests are sensitive information. When using our Curl handler, it is possible to use the CURLOPTHTTPAUTH option to specify an Authorization header. On making a request which responds with a redirect to a URI with a different origin, if we choose to follow it, we should remove the CURLOPTHTTPAUTH and CURLOPTUSERPWD options before continuing, stopping curl from appending the Authorization header to the new request. Previously, we would only consider a change in host. Now, we consider any change in host, port or scheme to be a change in origin. Patches Affected Guzzle 7 users should upgrade to Guzzle 7.4.5 as soon as possible. Affected users using any earlier series of Guzzle should upgrade to Guzzle 6.5.8 or 7.4.5. Note that a partial fix was implemented in Guzzle 7.4.2, where a change in host would trigger removal of the curl-added Authorization header, however this earlier fix did not cover change in scheme or change in port. Workarounds If you do…
Recommended action: Upgrade to 7.4.5 or 6.5.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Cookie headers on requests are sensitive information. On making a request using the https scheme to a server which responds with a redirect to a URI with the http scheme, or on making a request to a server which responds with a redirect to a a URI to a different host, we should not forward the Cookie header on. Prior to this fix, only cookies that were managed by our cookie middleware would be safely removed, and any Cookie header manually added to the initial request would not be stripped. We now always strip it, and allow the cookie middleware to re-add any cookies that it deems should be there. Patches Affected Guzzle 7 users should upgrade to Guzzle 7.4.4 as soon as possible. Affected users using any earlier series of Guzzle should upgrade to Guzzle 6.5.7 or 7.4.4. Workarounds An alternative approach would be to use your own redirect middleware, rather than ours, if you are unable to upgrade. If you do not require or expect redirects to be followed, one should simply…
Recommended action: Upgrade to 7.4.4 or 6.5.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Authorization headers on requests are sensitive information. On making a request using the https scheme to a server which responds with a redirect to a URI with the http scheme, we should not forward the Authorization header on. This is much the same as to how we don't forward on the header if the host changes. Prior to this fix, https to http downgrades did not result in the Authorization header being removed, only changes to the host. Patches Affected Guzzle 7 users should upgrade to Guzzle 7.4.4 as soon as possible. Affected users using any earlier series of Guzzle should upgrade to Guzzle 6.5.7 or 7.4.4. Workarounds An alternative approach would be to use your own redirect middleware, rather than ours, if you are unable to upgrade. If you do not require or expect redirects to be followed, one should simply disable redirects all together. References RFC9110 Section 15.4 For more information If you have any questions or comments about this advisory, please get in touch with…
Recommended action: Upgrade to 7.4.4 or 6.5.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Previous version of Guzzle contain a vulnerability with the cookie middleware. The vulnerability is that it is not checked if the cookie domain equals the domain of the server which sets the cookie via the Set-Cookie header, allowing a malicious server to set cookies for unrelated domains. For example an attacker at www.example.com might set a session cookie for api.example.net, logging the Guzzle client into their account and retrieving private API requests from the security log of their account. Note that our cookie middleware is disabled by default, so most library consumers will not be affected by this issue. Only those who manually add the cookie middleware to the handler stack or construct the client with ['cookies' = true] are affected. Moreover, those who do not use the same Guzzle client to call multiple domains and have disabled redirect forwarding are not affected by this vulnerability. Patches Affected Guzzle 7 users should upgrade to Guzzle 7.4.3 as soon as…
Recommended action: Upgrade to 7.4.3 or 6.5.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.