Vulnerable Library - guzzlehttp/guzzle-7.5.0
Guzzle is a PHP HTTP client library
Library home page: https://api.github.com/repos/guzzle/guzzle/zipball/b50a2a1251152e43f6a37f0fa053e730a67d25ba
Found in HEAD commit: 76912645301fd298ea1c90c624e716dd8de2f669
Vulnerabilities
| Vulnerability |
Severity |
 CVSS |
Dependency |
Type |
Fixed in (guzzlehttp/guzzle version) |
Remediation Possible** |
| CVE-2026-55568 |
 Medium |
5.9 |
guzzlehttp/guzzle-7.5.0 |
Direct |
guzzlehttp/guzzle - 7.12.1 |
❌ |
| CVE-2026-55767 |
Medium |
5.8 |
guzzlehttp/guzzle-7.5.0 |
Direct |
guzzlehttp/guzzle - 7.12.1 |
❌ |
| CVE-2026-49214 |
Medium |
5.3 |
guzzlehttp/psr7-2.5.0 |
Transitive |
N/A* |
❌ |
| CVE-2026-48998 |
Medium |
5.3 |
guzzlehttp/psr7-2.5.0 |
Transitive |
N/A* |
❌ |
| CVE-2026-55766 |
Medium |
4.8 |
guzzlehttp/psr7-2.5.0 |
Transitive |
N/A* |
❌ |
*For some transitive vulnerabilities, there is no version of direct dependency with a fix. Check the "Details" section below to see if there is a version of transitive dependency where vulnerability is fixed.
**In some cases, Remediation PR cannot be created automatically for a vulnerability despite the availability of remediation
Details
CVE-2026-55568
Vulnerable Library - guzzlehttp/guzzle-7.5.0
Guzzle is a PHP HTTP client library
Library home page: https://api.github.com/repos/guzzle/guzzle/zipball/b50a2a1251152e43f6a37f0fa053e730a67d25ba
Dependency Hierarchy:
- ❌ guzzlehttp/guzzle-7.5.0 (Vulnerable Library)
Found in HEAD commit: 76912645301fd298ea1c90c624e716dd8de2f669
Found in base branch: develop
Vulnerability 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.
Publish Date: 2026-06-19
URL: CVE-2026-55568
CVSS 3 Score Details (5.9)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: High
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: High
- Integrity Impact: None
- Availability Impact: None
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Origin: GHSA-cwxw-98qj-8qjx
Release Date: 2026-06-19
Fix Resolution: guzzlehttp/guzzle - 7.12.1
Step up your Open Source Security Game with Mend here
CVE-2026-55767
Vulnerable Library - guzzlehttp/guzzle-7.5.0
Guzzle is a PHP HTTP client library
Library home page: https://api.github.com/repos/guzzle/guzzle/zipball/b50a2a1251152e43f6a37f0fa053e730a67d25ba
Dependency Hierarchy:
- ❌ guzzlehttp/guzzle-7.5.0 (Vulnerable Library)
Found in HEAD commit: 76912645301fd298ea1c90c624e716dd8de2f669
Found in base branch: develop
Vulnerability 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.
Publish Date: 2026-06-19
URL: CVE-2026-55767
CVSS 3 Score Details (5.8)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Changed
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: Low
- Availability Impact: None
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Origin: GHSA-cwxw-98qj-8qjx
Release Date: 2026-06-19
Fix Resolution: guzzlehttp/guzzle - 7.12.1
Step up your Open Source Security Game with Mend here
CVE-2026-49214
Vulnerable Library - guzzlehttp/psr7-2.5.0
PSR-7 message implementation that also provides common utility methods
Library home page: https://api.github.com/repos/guzzle/psr7/zipball/b635f279edd83fc275f822a1188157ffea568ff6
Dependency Hierarchy:
- guzzlehttp/guzzle-7.5.0 (Root Library)
- ❌ guzzlehttp/psr7-2.5.0 (Vulnerable Library)
Found in HEAD commit: 76912645301fd298ea1c90c624e716dd8de2f669
Found in base branch: develop
Vulnerability Details
guzzlehttp/psr7 is a PSR-7 HTTP message library implementation in PHP. Versions prior to 2.10.2 did not reject ASCII control characters, whitespace, or DEL in first-party URI host components. A vulnerable flow is: First, an application accepts a user-controlled URL. Second, the URL is used to construct a PSR-7 "Uri" or "Request". Third, the host component contains CRLF or another header-unsafe character. Fourth, the host is copied into the PSR-7 "Host" header when no explicit "Host" header is provided. Finally, the request is serialized or sent by an HTTP client that does not independently reject the malformed host. In that flow, an attacker can cause the serialized request to contain additional attacker-controlled header lines. For example, a host containing ""\r\nX-Injected: yes"" can cause the generated "Host" header to span multiple HTTP header lines. Applications are affected when they use user-controlled URLs for outbound HTTP requests, URL forwarding, proxying, crawling, webhook delivery, or similar request-dispatch flows. In deployments involving HTTP/1.1 connection reuse, proxies, gateways, or load balancers, this malformed request may also contribute to request smuggling or cache poisoning, depending on how downstream components parse the request. The issue is patched in "2.10.2" and later. "1.x" is end-of-life and will not receive a patch. As a workaround, validate and reject all untrusted URI strings before constructing PSR-7 "Uri" or "Request" instances. Reject input containing ASCII control characters, whitespace, or DEL, including CRLF, tab, space, NUL, or DEL characters. Applications that forward requests should also ensure the final HTTP client or serializer rejects invalid URI and header data before writing requests to the network.
Publish Date: 2026-06-11
URL: CVE-2026-49214
CVSS 3 Score Details (5.3)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: Low
- Availability Impact: None
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Origin: GHSA-hq7v-mx3g-29hw
Release Date: 2026-06-11
Fix Resolution: guzzlehttp/psr7 - 2.10.2
Step up your Open Source Security Game with Mend here
CVE-2026-48998
Vulnerable Library - guzzlehttp/psr7-2.5.0
PSR-7 message implementation that also provides common utility methods
Library home page: https://api.github.com/repos/guzzle/psr7/zipball/b635f279edd83fc275f822a1188157ffea568ff6
Dependency Hierarchy:
- guzzlehttp/guzzle-7.5.0 (Root Library)
- ❌ guzzlehttp/psr7-2.5.0 (Vulnerable Library)
Found in HEAD commit: 76912645301fd298ea1c90c624e716dd8de2f669
Found in base branch: develop
Vulnerability Details
guzzlehttp/psr7 is a PSR-7 HTTP message library implementation in PHP. Versions prior to 2.10.2 contain improper Host header validation when parsing raw HTTP request messages and when deriving a server request URI from server variables. An attacker can provide a malformed Host header containing URI authority delimiters, such as "trusted.example@evil.example". When the Host value is used to construct a URI, the malformed value can be reinterpreted as URI userinfo and host. This can cause the PSR-7 request URI host to differ from the original Host header value. Applications are affected if they parse attacker-controlled raw HTTP requests with "GuzzleHttp\Psr7\Message::parseRequest()" or the legacy 1.x "GuzzleHttp\Psr7\parse_request()" function, or if they build server requests from attacker-controlled server variables, then rely on the resulting URI host for routing, allow-list checks, or forwarding decisions. In affected forwarding or gateway scenarios, this may cause requests or credentials to be sent to an unintended host. The issue is patched in "2.10.2". "1.x" is end-of-life and will not receive a patch. Some workarounds are available. Validate the "Host" header as "uri-host [ ":" port ]" before calling "Message::parseRequest()" or legacy "parse_request()" on untrusted HTTP request data, or before deriving routing and forwarding decisions from a parsed request URI. Reject Host values containing userinfo, path, query, or fragment delimiters.
Publish Date: 2026-06-11
URL: CVE-2026-48998
CVSS 3 Score Details (5.3)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: Low
- Integrity Impact: None
- Availability Impact: None
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Origin: GHSA-34xg-wgjx-8xph
Release Date: 2026-06-11
Fix Resolution: guzzlehttp/psr7 - 2.10.2
Step up your Open Source Security Game with Mend here
CVE-2026-55766
Vulnerable Library - guzzlehttp/psr7-2.5.0
PSR-7 message implementation that also provides common utility methods
Library home page: https://api.github.com/repos/guzzle/psr7/zipball/b635f279edd83fc275f822a1188157ffea568ff6
Dependency Hierarchy:
- guzzlehttp/guzzle-7.5.0 (Root Library)
- ❌ guzzlehttp/psr7-2.5.0 (Vulnerable Library)
Found in HEAD commit: 76912645301fd298ea1c90c624e716dd8de2f669
Found in base branch: develop
Vulnerability Details
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"; applications using "guzzlehttp/psr7" only through Guzzle's standard HTTP client APIs are not expected to be affected. Applications are most likely to be affected when they manually serialize PSR-7 messages, forward raw HTTP messages, or use custom transports, proxying, crawling, webhook delivery, testing, or similar code. Depending on how downstream HTTP/1.1 components parse the serialized message, this may lead to header injection, response splitting, request smuggling, or cache poisoning. Patches The issue is patched in "2.12.1" and later. Starting in that release, "guzzlehttp/psr7" rejects CR/LF characters in HTTP method, protocol version, and response reason phrase values before storing them in first-party message objects. Workarounds If you cannot upgrade immediately, reject CR/LF in untrusted method, protocol version, and reason phrase values before constructing or modifying PSR-7 messages. Applications that parse, forward, replay, or serialize raw HTTP messages cannot work around the parser entry points by validating only after parsing. They should validate the raw start line before calling "Message::parseRequest()" or "Message::parseResponse()", avoid reparsing untrusted raw messages, or upgrade. If an application runs with attacker-controlled synthetic "$_SERVER" values, validate "REQUEST_METHOD" and "SERVER_PROTOCOL" before calling "ServerRequest::fromGlobals()".
Publish Date: 2026-06-19
URL: CVE-2026-55766
CVSS 3 Score Details (4.8)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: High
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: Low
- Integrity Impact: Low
- Availability Impact: None
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Origin: GHSA-cwxw-98qj-8qjx
Release Date: 2026-06-19
Fix Resolution: guzzlehttp/psr7 - 2.12.1
Step up your Open Source Security Game with Mend here
Guzzle is a PHP HTTP client library
Library home page: https://api.github.com/repos/guzzle/guzzle/zipball/b50a2a1251152e43f6a37f0fa053e730a67d25ba
Found in HEAD commit: 76912645301fd298ea1c90c624e716dd8de2f669
Vulnerabilities
*For some transitive vulnerabilities, there is no version of direct dependency with a fix. Check the "Details" section below to see if there is a version of transitive dependency where vulnerability is fixed.
**In some cases, Remediation PR cannot be created automatically for a vulnerability despite the availability of remediation
Details
Vulnerable Library - guzzlehttp/guzzle-7.5.0
Guzzle is a PHP HTTP client library
Library home page: https://api.github.com/repos/guzzle/guzzle/zipball/b50a2a1251152e43f6a37f0fa053e730a67d25ba
Dependency Hierarchy:
Found in HEAD commit: 76912645301fd298ea1c90c624e716dd8de2f669
Found in base branch: develop
Vulnerability 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.
Publish Date: 2026-06-19
URL: CVE-2026-55568
CVSS 3 Score Details (5.9)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: High
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: High
- Integrity Impact: None
- Availability Impact: None
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Origin: GHSA-cwxw-98qj-8qjx
Release Date: 2026-06-19
Fix Resolution: guzzlehttp/guzzle - 7.12.1
Step up your Open Source Security Game with Mend here
Vulnerable Library - guzzlehttp/guzzle-7.5.0
Guzzle is a PHP HTTP client library
Library home page: https://api.github.com/repos/guzzle/guzzle/zipball/b50a2a1251152e43f6a37f0fa053e730a67d25ba
Dependency Hierarchy:
Found in HEAD commit: 76912645301fd298ea1c90c624e716dd8de2f669
Found in base branch: develop
Vulnerability 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.
Publish Date: 2026-06-19
URL: CVE-2026-55767
CVSS 3 Score Details (5.8)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Changed
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: Low
- Availability Impact: None
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Origin: GHSA-cwxw-98qj-8qjx
Release Date: 2026-06-19
Fix Resolution: guzzlehttp/guzzle - 7.12.1
Step up your Open Source Security Game with Mend here
Vulnerable Library - guzzlehttp/psr7-2.5.0
PSR-7 message implementation that also provides common utility methods
Library home page: https://api.github.com/repos/guzzle/psr7/zipball/b635f279edd83fc275f822a1188157ffea568ff6
Dependency Hierarchy:
Found in HEAD commit: 76912645301fd298ea1c90c624e716dd8de2f669
Found in base branch: develop
Vulnerability Details
guzzlehttp/psr7 is a PSR-7 HTTP message library implementation in PHP. Versions prior to 2.10.2 did not reject ASCII control characters, whitespace, or DEL in first-party URI host components. A vulnerable flow is: First, an application accepts a user-controlled URL. Second, the URL is used to construct a PSR-7 "Uri" or "Request". Third, the host component contains CRLF or another header-unsafe character. Fourth, the host is copied into the PSR-7 "Host" header when no explicit "Host" header is provided. Finally, the request is serialized or sent by an HTTP client that does not independently reject the malformed host. In that flow, an attacker can cause the serialized request to contain additional attacker-controlled header lines. For example, a host containing ""\r\nX-Injected: yes"" can cause the generated "Host" header to span multiple HTTP header lines. Applications are affected when they use user-controlled URLs for outbound HTTP requests, URL forwarding, proxying, crawling, webhook delivery, or similar request-dispatch flows. In deployments involving HTTP/1.1 connection reuse, proxies, gateways, or load balancers, this malformed request may also contribute to request smuggling or cache poisoning, depending on how downstream components parse the request. The issue is patched in "2.10.2" and later. "1.x" is end-of-life and will not receive a patch. As a workaround, validate and reject all untrusted URI strings before constructing PSR-7 "Uri" or "Request" instances. Reject input containing ASCII control characters, whitespace, or DEL, including CRLF, tab, space, NUL, or DEL characters. Applications that forward requests should also ensure the final HTTP client or serializer rejects invalid URI and header data before writing requests to the network.
Publish Date: 2026-06-11
URL: CVE-2026-49214
CVSS 3 Score Details (5.3)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: Low
- Availability Impact: None
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Origin: GHSA-hq7v-mx3g-29hw
Release Date: 2026-06-11
Fix Resolution: guzzlehttp/psr7 - 2.10.2
Step up your Open Source Security Game with Mend here
Vulnerable Library - guzzlehttp/psr7-2.5.0
PSR-7 message implementation that also provides common utility methods
Library home page: https://api.github.com/repos/guzzle/psr7/zipball/b635f279edd83fc275f822a1188157ffea568ff6
Dependency Hierarchy:
Found in HEAD commit: 76912645301fd298ea1c90c624e716dd8de2f669
Found in base branch: develop
Vulnerability Details
guzzlehttp/psr7 is a PSR-7 HTTP message library implementation in PHP. Versions prior to 2.10.2 contain improper Host header validation when parsing raw HTTP request messages and when deriving a server request URI from server variables. An attacker can provide a malformed Host header containing URI authority delimiters, such as "trusted.example@evil.example". When the Host value is used to construct a URI, the malformed value can be reinterpreted as URI userinfo and host. This can cause the PSR-7 request URI host to differ from the original Host header value. Applications are affected if they parse attacker-controlled raw HTTP requests with "GuzzleHttp\Psr7\Message::parseRequest()" or the legacy 1.x "GuzzleHttp\Psr7\parse_request()" function, or if they build server requests from attacker-controlled server variables, then rely on the resulting URI host for routing, allow-list checks, or forwarding decisions. In affected forwarding or gateway scenarios, this may cause requests or credentials to be sent to an unintended host. The issue is patched in "2.10.2". "1.x" is end-of-life and will not receive a patch. Some workarounds are available. Validate the "Host" header as "uri-host [ ":" port ]" before calling "Message::parseRequest()" or legacy "parse_request()" on untrusted HTTP request data, or before deriving routing and forwarding decisions from a parsed request URI. Reject Host values containing userinfo, path, query, or fragment delimiters.
Publish Date: 2026-06-11
URL: CVE-2026-48998
CVSS 3 Score Details (5.3)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: Low
- Integrity Impact: None
- Availability Impact: None
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Origin: GHSA-34xg-wgjx-8xph
Release Date: 2026-06-11
Fix Resolution: guzzlehttp/psr7 - 2.10.2
Step up your Open Source Security Game with Mend here
Vulnerable Library - guzzlehttp/psr7-2.5.0
PSR-7 message implementation that also provides common utility methods
Library home page: https://api.github.com/repos/guzzle/psr7/zipball/b635f279edd83fc275f822a1188157ffea568ff6
Dependency Hierarchy:
Found in HEAD commit: 76912645301fd298ea1c90c624e716dd8de2f669
Found in base branch: develop
Vulnerability Details
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"; applications using "guzzlehttp/psr7" only through Guzzle's standard HTTP client APIs are not expected to be affected. Applications are most likely to be affected when they manually serialize PSR-7 messages, forward raw HTTP messages, or use custom transports, proxying, crawling, webhook delivery, testing, or similar code. Depending on how downstream HTTP/1.1 components parse the serialized message, this may lead to header injection, response splitting, request smuggling, or cache poisoning. Patches The issue is patched in "2.12.1" and later. Starting in that release, "guzzlehttp/psr7" rejects CR/LF characters in HTTP method, protocol version, and response reason phrase values before storing them in first-party message objects. Workarounds If you cannot upgrade immediately, reject CR/LF in untrusted method, protocol version, and reason phrase values before constructing or modifying PSR-7 messages. Applications that parse, forward, replay, or serialize raw HTTP messages cannot work around the parser entry points by validating only after parsing. They should validate the raw start line before calling "Message::parseRequest()" or "Message::parseResponse()", avoid reparsing untrusted raw messages, or upgrade. If an application runs with attacker-controlled synthetic "$_SERVER" values, validate "REQUEST_METHOD" and "SERVER_PROTOCOL" before calling "ServerRequest::fromGlobals()".
Publish Date: 2026-06-19
URL: CVE-2026-55766
CVSS 3 Score Details (4.8)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: High
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: Low
- Integrity Impact: Low
- Availability Impact: None
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Origin: GHSA-cwxw-98qj-8qjx
Release Date: 2026-06-19
Fix Resolution: guzzlehttp/psr7 - 2.12.1
Step up your Open Source Security Game with Mend here