chore(deps): update dependency guzzlehttp/guzzle to v7.14.2 [security]

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
guzzlehttp/guzzle (source)	7.9.2 → 7.14.2

---

guzzlehttp/guzzle: Silent HTTPS-Proxy Downgrade to Cleartext

CVE-2026-55568 / GHSA-wpwq-4j6v-78m3

More information

Details

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 http_proxy, https_proxy, HTTPS_PROXY, all_proxy, and ALL_PROXY.

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 security-relevant case is the silent downgrade on libcurl older than 7.50.2. An application is affected when it sends requests through one of the built-in cURL handlers, configures an https:// proxy expecting the proxy connection itself to be encrypted, and runs with libcurl older than 7.50.2.

In that configuration, traffic expected to be protected by TLS on the hop to the proxy is transmitted in cleartext. Proxy authentication credentials (the Proxy-Authorization header, proxy userinfo in the proxy URL, or CURLOPT_PROXYUSERPWD) are sent without encryption, and the CONNECT target host and port for tunneled HTTPS requests are exposed. For plain HTTP requests, request headers and bodies are also exposed on the proxy leg. End-to-end HTTPS requests tunneled through the proxy remain protected by their inner TLS session; the exposure is limited to the proxy negotiation and proxy credentials.

Applications that do not configure an https:// proxy are not affected. Installations running libcurl 7.52.0 or newer built with HTTPS-proxy support are not affected because HTTPS proxies work as intended. Installations running libcurl 7.50.2 through 7.51.x, or libcurl 7.52.0 or newer built without HTTPS-proxy support, are not exposed to the silent cleartext downgrade, but Guzzle now rejects those unsupported configurations up front as well. The built-in stream handler is not affected; the issue is specific to the cURL handlers' proxy handling. Low-level cURL options under the curl request option, such as CURLOPT_PROXY or CURLOPT_PROXYTYPE, are advanced custom configuration and remain the caller's responsibility.

Patches

The issue is patched in 7.12.1 and later. Starting in that release, the built-in cURL handlers detect whether the installed libcurl supports HTTPS proxies — requiring both libcurl 7.52.0 or newer and the CURL_VERSION_HTTPS_PROXY feature bit — and reject a request configured through Guzzle's first-class proxy handling with an https:// proxy up front by throwing a GuzzleHttp\Exception\RequestException. No request bytes reach the network when the proxy cannot be used securely. Versions before 7.12.1 are affected by the silent downgrade when run against libcurl older than 7.50.2.

Workarounds

If you cannot upgrade immediately, do not configure an https:// proxy on an installation whose libcurl lacks HTTPS-proxy support, and verify the capability in application code before using one. Remember to check proxy environment variables as well as any explicit proxy option:

$curl = \curl_version();
$httpsProxyBit = \defined('CURL_VERSION_HTTPS_PROXY') ? \CURL_VERSION_HTTPS_PROXY : (1 << 21);

if (\version_compare($curl['version'], '7.52.0', '<') || 0 === ($curl['features'] & $httpsProxyBit)) {
    throw new \RuntimeException('Installed libcurl does not support HTTPS proxies.');
}

Upgrading the system libcurl to 7.52.0 or newer built with HTTPS-proxy support also resolves the underlying unsupported-proxy behavior.

Severity

• CVSS Score: 5.9 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

References

• https://github.com/guzzle/guzzle/security/advisories/GHSA-wpwq-4j6v-78m3
• https://github.com/advisories/GHSA-wpwq-4j6v-78m3

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

guzzlehttp/guzzle: Dot-Only Cookie Domains Match All Hosts

CVE-2026-55767 / GHSA-cwxw-98qj-8qjx

More information

Details

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 trusted origins.

Applications that do not use Guzzle's cookie support, or that use separate cookie jars per origin or trust boundary, are not affected. This issue is distinct from public suffix list validation: dot-only domains contain no domain label and should not match unrelated hosts.

Patches

The issue is patched in 7.12.1 and later. Starting in that release, Guzzle rejects dot-only cookie Domain attributes and prevents an empty normalized cookie domain from matching any request host.

Workarounds

If you cannot upgrade immediately, do not reuse the same CookieJar instance across untrusted and trusted origins. Use separate cookie jars per origin or trust boundary, or disable cookie handling for requests to untrusted hosts.

Avoid using new Client(['cookies' => true]) for clients that may contact unrelated hosts with different trust levels, because that option creates one shared jar for the client.

Severity

• CVSS Score: 5.8 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N

References

• https://github.com/guzzle/guzzle/security/advisories/GHSA-cwxw-98qj-8qjx
• https://github.com/advisories/GHSA-cwxw-98qj-8qjx

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Guzzle: Proxy-Authorization headers can be sent to origin servers

GHSA-94pj-82f3-465w

More information

Details

Impact

In affected versions, the built-in cURL handlers (CurlHandler and CurlMultiHandler) put every first-class request header in cURL's origin header list (CURLOPT_HTTPHEADER). These handlers are the default when the PHP cURL extension is available. They move Proxy-Authorization to the proxy-only list (CURLOPT_PROXYHEADER) 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 CURLOPT_HTTPHEADER, CURLOPT_PROXYHEADER, or stream_context.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, no_proxy, or NO_PROXY match.
• sent through a SOCKS proxy, which does not use the HTTP proxy header channel.
• redirected from a safely proxied hop into any of those routes: redirect middleware re-evaluates the proxy per hop but, unlike Authorization and Cookie, does not strip Proxy-Authorization cross-origin.

On installations whose libcurl is older than 7.37.0, or whose PHP cURL extension lacks CURLOPT_PROXYHEADER, CURLOPT_HEADEROPT, and CURLHEADER_SEPARATE, no proxy-only channel is available, so cURL left the header in the origin list for every route. The stream handler also serialized first-class values before selecting a proxy. PHP removes only the first Proxy-Authorization line from CONNECT, so another first-class value or a URL-userinfo Basic line could reach the tunneled origin. A later raw stream_context.http.proxy override could instead reroute either credential directly to the origin.

The disclosed value is a private credential meant only for the proxy. RFC 9110 defines Proxy-Authorization as credentials for the next inbound proxy, and an origin is never an intended recipient. The flaw can silently give a working proxy credential to an unrelated third party. In the worst case, an attacker controls the origin and records the credential through access logs, tracing systems, or application logs. If it remains valid, the attacker can abuse a paid or access-controlled proxy, impersonate the proxy principal, or reach destinations the proxy is trusted to reach. A strong remote exploit is possible when an application sends a request to an attacker-controlled HTTP URL through a proxy with a default Proxy-Authorization header, then follows the attacker's redirect to an HTTPS or no-proxy destination that Guzzle reaches directly.

Using a first-class Proxy-Authorization header is a legitimate, documented configuration, so affected applications are not misusing the library. Guzzle does not create this field, so applications that never configure one are unaffected by the first-class-header flaw. Proxy URL userinfo is not affected on its own, but the stream handler could expose its Basic line when combined with a first-class field or a later raw stream_context.http.proxy override. CURLOPT_PROXYUSERPWD is unaffected. Literal lines supplied through raw CURLOPT_HTTPHEADER, CURLOPT_PROXYHEADER, or stream_context.http.header remain caller-controlled and outside the first-class-header guarantee.

Patches

The issue is fixed in 7.14.2. The cURL handlers keep first-class Proxy-Authorization values out of the origin header list. When proxy header separation is available, they pass the values through CURLOPT_PROXYHEADER with CURLHEADER_SEPARATE. An empty value uses cURL's semicolon form to suppress credentials from proxy URL userinfo. On older builds, Guzzle drops the field for direct, bypassed, and SOCKS routes, but fails before network I/O if the request might use an HTTP or HTTPS proxy.

The stream handler removes the field from origin headers before choosing a route. If it selects a proxy, it accepts one value, including empty, writes a validated proxy header, and gives that value precedence over proxy URL userinfo. Multiple values, line breaks, and raw proxy overrides that could reroute generated credentials fail before connection. Direct and bypassed requests drop the field. Versions before 7.14.2 are affected by these origin-bound credential paths.

Workarounds

If you cannot upgrade immediately, remove first-class Proxy-Authorization fields from requests, client defaults, and middleware. Supply proxy credentials instead through proxy URL userinfo, for example http://user:pass@proxy.example:8080, or use CURLOPT_PROXYUSERPWD with the cURL handlers. Do not combine proxy URL userinfo with a first-class field or a raw stream_context.http.proxy override. If a first-class field is unavoidable, use libcurl 7.37.0 or newer with CURLOPT_PROXYHEADER, CURLOPT_HEADEROPT, and CURLHEADER_SEPARATE, and ensure the field is never present on a client that can issue direct, bypassed, or SOCKS requests or follow redirects into those routes. A newer libcurl is necessary but does not fix Guzzle's route-dependent migration by itself, and disabling redirects reduces but does not eliminate exposure.

References

• https://www.rfc-editor.org/rfc/rfc9110.html#section-11.7.2
• https://curl.se/libcurl/c/CURLOPT_PROXYHEADER.html
• https://curl.se/libcurl/c/CURLOPT_HEADEROPT.html
• https://curl.se/libcurl/c/CURLOPT_HTTPHEADER.html

Severity

• CVSS Score: 5.3 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

References

• https://github.com/guzzle/guzzle/security/advisories/GHSA-94pj-82f3-465w
• https://github.com/guzzle/guzzle/pull/3876
• https://github.com/guzzle/guzzle/commit/9e4580d4b9981e903dc6323fe37f50a96e85b05e
• https://github.com/guzzle/guzzle/releases/tag/7.14.2
• https://github.com/advisories/GHSA-94pj-82f3-465w

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Guzzle: Cookie Disclosure and Injection via IP-Address Domains

CVE-2026-59883 / GHSA-g446-98w2-8p5w

More information

Details

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 impact is cross-host cookie disclosure, cookie injection, or session fixation.

You are affected if your application uses Guzzle's cookie support, for example new Client(['cookies' => true]) or an explicit CookieJar, reuses one cookie jar across more than one host or trust boundary, and that jar can hold a cookie scoped to an IP-address or bare-numeric host. To actually leak a cookie the application must also resolve and connect to a look-alike host whose name ends in the IP-address label, such as evil.192.168.0.1. Such names are not publicly registrable, so in practice an attacker needs some influence over name resolution, which is realistic on private, split-horizon, container, or development networks. You are not affected if you do not use Guzzle's cookie support, if you use a separate cookie jar per host or trust boundary, or if your jars never hold cookies scoped to IP-address or bare-numeric hosts. This issue is independent of public suffix list validation. Per RFC 6265, an IP-address cookie domain must match only the exact host that set it and must never match a subdomain.

Patches

The issue is patched in 7.12.3 and later. Starting in that release, Guzzle matches an IPv4 literal, a bracketed IPv6 literal, or a bare-numeric cookie Domain only against the exact request host, and no longer applies subdomain suffix matching to them.

Workarounds

If you cannot upgrade immediately, do not reuse one CookieJar instance across untrusted and trusted origins. Use a separate cookie jar per host or trust boundary, or disable cookie handling for requests to untrusted hosts, and avoid scoping cookies to IP-address or bare-numeric hosts. In particular, avoid new Client(['cookies' => true]) for any client that may contact unrelated hosts at different trust levels, because that option creates a single shared jar for the whole client.

References

• https://datatracker.ietf.org/doc/html/rfc6265#section-5.1.3
• https://datatracker.ietf.org/doc/html/rfc6265#section-5.3
• https://url.spec.whatwg.org/#concept-ipv4-parser

Severity

• CVSS Score: 4.7 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N

References

• https://github.com/guzzle/guzzle/security/advisories/GHSA-g446-98w2-8p5w
• https://nvd.nist.gov/vuln/detail/CVE-2026-59883
• https://github.com/guzzle/guzzle/pull/3694
• https://github.com/guzzle/guzzle/commit/b9944c161b12d9ee9c9334cfc5b9659ecd7451f8
• https://github.com/guzzle/guzzle/releases/tag/7.12.3
• https://github.com/advisories/GHSA-g446-98w2-8p5w

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Release Notes

guzzle/guzzle (guzzlehttp/guzzle)

v7.14.2

Compare Source

Security

• Prevent first-class and proxy URL credentials from reaching origins (GHSA-94pj-82f3-465w)

v7.14.1

Compare Source

Changed

• Adjusted guzzlehttp/psr7 version constraint to ^2.12.5

Fixed

• Fail closed when a proxy tunnel isolation cURL option cannot be applied
• Normalize Stringable proxy credential values before computing connection-reuse section signatures
• Restore conservative credential redaction for unparseable proxies with multiple @ separators
• Redact request URI credentials from the stream handler connection error message
• Reject enabled response streaming (stream => true) on cap-configured stream handlers
• Distinguish CurlMultiHandler and StreamHandler outcomes in connection-cap custom-handler guidance
• Reject raw cURL options that conflict with explicit multiplexing guarantees
• Stop explicit multiplexing conflict checks faulting on non-array cURL multi options values
• Reject required multiplexing when the final CURLOPT_HTTPAUTH mask permits NTLM
• Require an integer CURLMOPT_PIPELINING when combined with explicit multiplexing
• Check the required multiplexing cleartext proxy rule against the final cURL configuration
• Bound cURL multi handler blocking selects by the earliest pending request delay
• Stop synchronous cURL multi handler waits blocking on other transfers once the target has settled
• Stop cURL multi completion processing double-settling promises canceled from completion callbacks
• Run ready promise queue tasks before sleeping for delayed cURL multi requests
• Avoid integer overflow in cURL multi delay timing on 32-bit platforms
• Roll back failed cURL multi handle attachment instead of leaving requests pending
• Release the cURL easy handle when the on_stats callback throws
• Normalize response trailer field names to lowercase with values in wire order
• Retain response trailers only when an on_trailers callback is configured
• Validate the on_trailers callback before starting a cURL transfer
• Reject the on_trailers request option on the stream handler, which cannot observe trailers
• Match cookies, proxy schemes, auth types, and header names with locale-independent ASCII folding
• Reject proxy option values that Guzzle cannot classify identically to ext-curl

v7.14.0

Compare Source

Added

• Added the on_trailers request option to expose parsed HTTP response trailers
• Added the multiplex request option with Multiplexing::* modes to control or require HTTP/2 multiplexing
• Added rejection of explicit multiplex requests when CURLMOPT_PIPELINING disables multiplexing
• Added the max_host_connections and max_total_connections client and cURL multi handler options

Changed

• Redirects that discard the request body no longer require it to be rewindable
• Synchronous cURL multi handler requests no longer wait for other queued transfers
• Section SOCKS proxy connections by credentials on libcurl before 7.69.0
• Reject request-level CURLOPT_SHARE when combined with authenticated SOCKS proxy configuration
• Redact proxy userinfo containing raw control bytes in cURL errors
• Check linked curl/libcurl NTLM support before applying NTLM auth
• Clarify that NTLM is deprecated by both Guzzle and curl/libcurl
• Remove deprecation for the raw cURL CURLOPT_CERTINFO option
• Warn when a cURL multi option cannot be applied

Deprecated

• Deprecate the raw CURLOPT_PIPEWAIT cURL option in favour of the multiplex request option
• Deprecate unknown handler constructor options
• Deprecate invalid select_timeout cURL multi handler option values
• Deprecate raw cURL multi connection cap options in favour of the named options

v7.13.3

Compare Source

Changed

• Adjusted guzzlehttp/promises version constraint to ^2.5.1
• Adjusted guzzlehttp/psr7 version constraint to ^2.12.4
• Pass explicit trim characters ahead of the PHP 8.6 trim default change

Fixed

• Stop matching cookie domains against hosts with a trailing newline
• Reject HTTP status codes and certificate type extensions with a trailing newline
• Treat PCRE engine failures as invalid cookie names during cookie validation
• Report PCRE engine failures when formatting log messages
• Report PCRE engine failures when splitting no_proxy values

v7.13.2

Compare Source

Fixed

• Stop the cURL multi handler busy-waiting on request delays shorter than one second
• Stop cURL HEAD requests with request bodies hanging on responses that declare a content length
• The cURL handler no longer transmits request bodies on HEAD requests
• Preserve response headers when a response includes HTTP trailers
• Harden cURL response header block detection when HTTP trailers are received
• Corrected the PSR-7 class names in the Pool iterator exception
• Redirect body rewind failures no longer leak a bare RuntimeException

v7.13.1

Compare Source

Fixed

• Allow middleware to rewrite partial URIs before transports validate them

v7.13.0

Compare Source

Added

• Added the crypto_method_max request option to cap the maximum TLS protocol version
• Added HTTP QUERY redirect support, preserving method and body on 301 and 302

Changed

• Section proxy tunnel connection reuse by credential so distinct credentials never share a tunnel
• Isolate concurrent foreign cURL proxy tunnels added while another owner's tunnel is active
• Route credentialed HTTP(S) proxy Proxy-Authorization headers through cURL proxy header handling
• Reject request-level CURLOPT_SHARE when combined with authenticated HTTP/HTTPS proxy tunnel configuration
• Remove deprecation for raw cURL CURLOPT_PREREQFUNCTION callbacks when defined by PHP cURL
• Route TLS 1.2 crypto_method requests to the stream handler when cURL cannot select TLS 1.2
• Reject final request URIs missing a scheme or host before transfer

Deprecated

• Deprecate invalid protocols, force_ip_resolve, delay, cookies, and allow_redirects values

v7.12.3

Compare Source

Changed

• Adjusted guzzlehttp/psr7 version constraint to ^2.12.3

Security

• Treat IP and numeric cookie domains as exact-match-only (GHSA-g446-98w2-8p5w)

v7.12.2

Compare Source

Fixed

• Clamp out-of-range Max-Age so a very large value no longer overflows to an already-expired timestamp
• Use strict comparison in CookieJar conflict resolution so distinct numeric-string names don't overwrite
• Store a cookie whose Domain has a trailing dot on the origin host instead of silently discarding it
• Fix StreamHandler hard-failing on bracketed IPv6 literal hosts when force_ip_resolve is set
• Use strict cookie Path comparison so CookieJar::clear() with a numeric path keeps a distinct-path cookie
• Fixed cookie handling for falsey Domain, Max-Age, path, and name values
• Fixed decode_content handling for falsey string values
• Fixed deprecated request option values reaching built-in handlers before normalization

v7.12.1

Compare Source

Changed

• Adjusted guzzlehttp/psr7 version constraint to ^2.12.1

Fixed

• Reject proxy URLs with a malformed scheme in the cURL handlers instead of letting libcurl mishandle them

Security

• Reject HTTPS proxies when the installed libcurl lacks HTTPS-proxy support (GHSA-wpwq-4j6v-78m3)
• Reject dot-only cookie Domain attributes as match-all (GHSA-cwxw-98qj-8qjx)

v7.12.0

Compare Source

Added

• Added RequestOptions constants for curl, retries, and stream_context

Changed

• Adjusted guzzlehttp/psr7 version constraint to ^2.12
• Constrain cURL transport sharing to safe libcurl DNS and SSL session support
• Resolve proxy environment variables in the cURL handlers; libcurl no longer reads the environment itself
• Ignore proxy environment variables when the proxy request option makes a decision
• Disable proxy environment variables on Windows SAPIs other than CLI (httpoxy hardening)
• Redact proxy credentials from cURL handler error messages, following Psr7\Utils::redactUserInfo()
• Normalize no-proxy domain and IP literal matching across the cURL and stream handlers

Deprecated

• Deprecated the request-level handler option, which will be ignored in 8.0
• Deprecated raw cURL request options outside the built-in cURL handlers' allow-list
• Deprecated the CURLOPT_PROXYTYPE cURL request option; set the proxy type via a scheme-prefixed proxy URL
• Deprecated PHP stream context options outside the built-in stream handler allow-list
• Deprecated passing ntlm as a built-in auth type
• Deprecated Utils::describeType()
• Deprecated non-finite floats in the query and form_params options; 8.0 rejects them
• Deprecated non-string scalar values in the body option; 8.0 rejects them

Fixed

• Fix cURL TLS and HTTP/2 capability detection using libcurl feature checks
• Fix proxy no list matches being re-proxied through environment-configured proxies by libcurl
• Fix no list and NO_PROXY matching to support IP CIDR ranges, matching libcurl
• Fix the stream handler not applying scheme-less proxies and their credentials

v7.11.2

Compare Source

Fixed

• Fixed non-finite float values emitting coercion warnings on PHP 8.5

v7.11.1

Compare Source

Fixed

• Ignore request-level transport_sharing, matching other unknown request options

v7.11.0

Compare Source

Added

• Added support for providing the proxy request option's no value as a comma-delimited string
• Added the protocols request option to restrict allowed URI schemes for request transfers
• Added cert_type and ssl_key_type request options for TLS certificate and private-key file types
• Added PHP stream handler support for the ssl_key request option
• Added transport sharing via the transport_sharing client and cURL handler options

Changed

• Adjusted guzzlehttp/promises version constraint to ^2.5
• Adjusted guzzlehttp/psr7 version constraint to ^2.11
• Allowed domainless SetCookie instances to be stored without wildcard request matching
• Changed no-proxy matching to respect request ports for host-and-port rules
• Prevented CurlMultiHandler destructors from throwing during cleanup
• Improved invalid response handling across handlers

Deprecated

• Deprecated non-iterable Pool request collections, which will be rejected in 8.0
• Deprecated non-uppercase easy request methods; 8.0 preserves method casing
• Deprecated non-string headers request option values, which will be rejected in 8.0
• Deprecated empty headers request option value arrays, which will be rejected in 8.0
• Deprecated empty and malformed request protocol versions, which will be rejected in 8.0
• Deprecated conflicting raw cURL request options, including CURLOPT_SHARE, which will be rejected in 8.0
• Deprecated scalar-coerced idn_conversion request option values, which will be rejected in 8.0
• Deprecated invalid documented request option value types, which will be rejected in 8.0
• Deprecated selected request options ignored by incompatible built-in handlers, which will be rejected in 8.0
• Deprecated RequestException::wrapException(), which will be removed in 8.0
• Deprecated RetryMiddleware::exponentialDelay(), which will be removed in 8.0

v7.10.6

Compare Source

Fixed

• CurlMultiHandler now rejects the promise when CurlFactory::finish() throws, preserving sibling transfers
• SetCookie now normalizes unparseable Expires values to null instead of false
• Fix stream handler decoded gzip/deflate truncation by dropping invalid Content-Length

v7.10.5

Compare Source

Fixed

• Defer cURL multi cancellation cleanup until after progress callbacks return
• Classify additional stream handler connection failures as ConnectException

v7.10.4

Compare Source

Fixed

• Fix IPv6 literal matching in no-proxy rules
• Handle cURL multi completion messages without handles after cancelled transfers
• Fix magic client request methods such as options() to uppercase inferred HTTP methods

v7.10.3

Compare Source

Fixed

• Fail clearly when an HTTP response header line is invalid
• Remove middleware by name when the name is also a callable string
• Treat empty request protocol versions as HTTP/1.1

v7.10.2

Compare Source

Fixed

• Normalize HTTP version request options before applying them to PSR-7 requests
• Use string values for headers generated by request preparation and response decoding

v7.10.1

Compare Source

Fixed

• Fail clearly when cURL options cannot be applied
• Fail clearly when the certificate option is malformed
• Fail clearly when JSON decode depth is invalid
• Fail clearly when session cookie data is malformed
• Fail clearly when the stream progress option is not callable
• Prevent response creation failures from exposing stale cURL responses

v7.10.0

Compare Source

Added

• Support for PHP 8.5

Changed

• Adjusted guzzlehttp/promises version constraint to ^2.3
• Adjusted guzzlehttp/psr7 version constraint to ^2.8

v7.9.3

Compare Source

Changed

• Remove explicit content-length header for GET requests
• Improve compatibility with bad servers for boolean cookie values

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[renovate]

⚠️ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

• any of the package files in this branch needs updating, or
• the branch becomes conflicted, or
• you click the rebase/retry checkbox if found above, or
• you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: composer.lock

Command failed: composer update guzzlehttp/guzzle:7.14.2 --with-dependencies --ignore-platform-req=ext-* --ignore-platform-req=lib-* --no-ansi --no-interaction --no-scripts --no-autoloader --no-plugins --minimal-changes
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires guzzlehttp/guzzle ^7.0, found guzzlehttp/guzzle[7.0.0, ..., 7.15.1] but these were not loaded, because they are affected by security advisories ("PKSA-fy2t-3c5f-827y", "PKSA-qxvb-2bpp-dnk6", "PKSA-bbs6-q5q9-f3t4", "PKSA-bcdd-5xc7-gwfb", "PKSA-pwsk-hy21-4gby", "PKSA-93qv-9n9h-6k6p", "PKSA-k22t-f949-t9g6", "PKSA-yfw5-9gnj-n2c7", "PKSA-k1b4-kshy-xgbh", "PKSA-2z36-j4q9-rsfy", "PKSA-fvw5-9t6n-nwvr", "PKSA-6d8m-6kgw-18zr"). Go to https://packagist.org/security-advisories/ to find advisory details. To ignore the advisories, add their IDs to the "policy.advisories.ignore-id" config or add the package to "policy.advisories.ignore". To turn the feature off entirely, you can set "policy.advisories.block" to false.
  Problem 2
    - illuminate/http is locked to version v11.46.0 and an update of this package was not requested.
    - illuminate/http v11.46.0 requires guzzlehttp/guzzle ^7.8.2 -> found guzzlehttp/guzzle[7.8.2, ..., 7.15.1] but these were not loaded, because they are affected by security advisories ("PKSA-fy2t-3c5f-827y", "PKSA-qxvb-2bpp-dnk6", "PKSA-bbs6-q5q9-f3t4", "PKSA-bcdd-5xc7-gwfb", "PKSA-pwsk-hy21-4gby", "PKSA-93qv-9n9h-6k6p", "PKSA-k22t-f949-t9g6"). Go to https://packagist.org/security-advisories/ to find advisory details. To ignore the advisories, add their IDs to the "policy.advisories.ignore-id" config or add the package to "policy.advisories.ignore". To turn the feature off entirely, you can set "policy.advisories.block" to false.

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.