Skip to content

Update dependency guzzlehttp/guzzle to v7.12.1 [SECURITY]#5920

Open
renovate[bot] wants to merge 1 commit into
2.1.xfrom
renovate/packagist-guzzlehttp-guzzle-vulnerability
Open

Update dependency guzzlehttp/guzzle to v7.12.1 [SECURITY]#5920
renovate[bot] wants to merge 1 commit into
2.1.xfrom
renovate/packagist-guzzlehttp-guzzle-vulnerability

Conversation

@renovate

@renovate renovate Bot commented Jun 22, 2026

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
guzzlehttp/guzzle (source) 7.10.07.12.1 age confidence
guzzlehttp/guzzle (source) 7.8.07.12.1 age confidence

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.


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

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

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


Release Notes

guzzle/guzzle (guzzlehttp/guzzle)

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

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

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 these updates again.


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

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

@github-actions

Copy link
Copy Markdown
Contributor

Issue bot detected changes — view run:

Result of the code snippet from @pereorga in #11889 changed:

@@ @@
 PHP 8.0 – 8.4 (1 error)
 ==========
 
-12: Function get_cv_files() should return list<string> but returns array.
+12: Function get_cv_files() should return list<string> but returns list.
 
 PHP 7.2 – 7.4 (1 error)
 ==========
 
-12: Function get_cv_files() should return list<string> but returns array|false.
+12: Function get_cv_files() should return list<string> but returns list|false.
Full report

PHP 8.0 – 8.4 (1 error)

Line Error
12 Function get_cv_files() should return list<string> but returns list.

PHP 7.2 – 7.4 (1 error)

Line Error
12 `Function get_cv_files() should return list but returns list

Result of the code snippet from @staabm in #14768 changed:

@@ @@
+7: Expected type decimal-int-string, actual: lowercase-string&numeric-string&uppercase-string
 9: Expected type non-decimal-int-string, actual: string
Full report
Line Error
7 Expected type decimal-int-string, actual: lowercase-string&numeric-string&uppercase-string
9 Expected type non-decimal-int-string, actual: string

Result of the code snippet from @staabm in #14786 changed:

@@ @@
  7: Function doFoo() has no return type specified.
-10: Call to function is_int() with int will always evaluate to true.
+ 7: PHPDoc tag @param for parameter $s contains unresolvable type.
+ 8: Unary operation "+" on string results in an error.
Full report
Line Error
7 Function doFoo() has no return type specified.
7 PHPDoc tag @param for parameter $s contains unresolvable type.
8 Unary operation "+" on string results in an error.

Result of the code snippet from @staabm in #14786 changed:

@@ @@
 7: Function doFoo() has no return type specified.
-9: Expected type (float|int), actual: int
+7: PHPDoc tag @param for parameter $s contains unresolvable type.
+8: Unary operation "+" on string results in an error.
+9: Expected type (float|int), actual: *ERROR*
Full report
Line Error
7 Function doFoo() has no return type specified.
7 PHPDoc tag @param for parameter $s contains unresolvable type.
8 Unary operation "+" on string results in an error.
9 `Expected type (float

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants