<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sat, 03 Oct 2026 16:47:00 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-329274</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-329274</link>
      <description>EUVD-2026-329274</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-329274</guid>
    </item>
    <item>
      <title>fkie_cve-2026-55568</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-55568</link>
      <description>&lt;p&gt;Guzzle is an extensible PHP HTTP client. Prior to 7.12.1, in certain configurations, 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. 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. 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. 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. This vulnerability is fixed in 7.12.1.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Guzzle is an extensible PHP HTTP client. Prior to 7.12.1, in certain configurations, 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. 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. 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. 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. This vulnerability is fixed in 7.12.1.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-55568</guid>
    </item>
    <item>
      <title>GHSA-wpwq-4j6v-78m3 — guzzlehttp/guzzle: Silent HTTPS-Proxy Downgrade to Cleartext</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-wpwq-4j6v-78m3</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Packagist: guzzlehttp/guzzle&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;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`.&lt;/p&gt;
&lt;p&gt;When the installed libcurl does not support HTTPS proxies, behavior depends on the libcurl version/build:&lt;/p&gt;
&lt;p&gt;- 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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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` h…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Packagist: guzzlehttp/guzzle&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;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`.&lt;/p&gt;
&lt;p&gt;When the installed libcurl does not support HTTPS proxies, behavior depends on the libcurl version/build:&lt;/p&gt;
&lt;p&gt;- 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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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` h…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-wpwq-4j6v-78m3</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-55568</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-55568</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:24.04:LTS: guzzle, Ubuntu:25.10: guzzle, Ubuntu:26.04:LTS: guzzle&lt;/p&gt;
&lt;p&gt;Guzzle is an extensible PHP HTTP client. Prior to 7.12.1, in certain configurations, 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. 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. 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. 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. This vulnerability is fixed in 7.12.1.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:24.04:LTS: guzzle, Ubuntu:25.10: guzzle, Ubuntu:26.04:LTS: guzzle&lt;/p&gt;
&lt;p&gt;Guzzle is an extensible PHP HTTP client. Prior to 7.12.1, in certain configurations, 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. 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. 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. 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. This vulnerability is fixed in 7.12.1.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-55568</guid>
    </item>
  </channel>
</rss>
