<?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://vulnerability.circl.lu</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>Mon, 28 Sep 2026 19:44:32 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-1965 — bad reuse of HTTP Negotiate connection</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-1965</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; curl&lt;/p&gt;
&lt;p&gt;libcurl can in some circumstances reuse the wrong connection when asked to do
an Negotiate-authenticated HTTP or HTTPS request.&lt;/p&gt;
&lt;p&gt;libcurl features a pool of recent connections so that subsequent requests can
reuse an existing connection to avoid overhead.&lt;/p&gt;
&lt;p&gt;When reusing a connection a range of criterion must first be met. Due to a
logical error in the code, a request that was issued by an application could
wrongfully reuse an existing connection to the same server that was
authenticated using different credentials. One underlying reason being that
Negotiate sometimes authenticates *connections* and not *requests*, contrary
to how HTTP is designed to work.&lt;/p&gt;
&lt;p&gt;An application that allows Negotiate authentication to a server (that responds
wanting Negotiate) with `user1:password1` and then does another operation to
the same server also using Negotiate but with `user2:password2` (while the
previous connection is still alive) - the second request wrongly reused the
same connection and since it then sees that the Negotiate negotiation is
already made, it sends the request over that connection thinking it uses
the user2 credentials when it is in fact still using the connection
authenticated for user1...&lt;/p&gt;
&lt;p&gt;The set of authentication methods to use is set with `CURLOPT_HTTPAUTH`.&lt;/p&gt;
&lt;p&gt;Applications can disable libcurl&amp;#39;s reuse of connections and thus mitigate this
problem, by using one of the following libcurl options to alter how
connections are or are not reused: `CURLOPT_FRESH_CONNECT`,
`CURLO…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; curl&lt;/p&gt;
&lt;p&gt;libcurl can in some circumstances reuse the wrong connection when asked to do
an Negotiate-authenticated HTTP or HTTPS request.&lt;/p&gt;
&lt;p&gt;libcurl features a pool of recent connections so that subsequent requests can
reuse an existing connection to avoid overhead.&lt;/p&gt;
&lt;p&gt;When reusing a connection a range of criterion must first be met. Due to a
logical error in the code, a request that was issued by an application could
wrongfully reuse an existing connection to the same server that was
authenticated using different credentials. One underlying reason being that
Negotiate sometimes authenticates *connections* and not *requests*, contrary
to how HTTP is designed to work.&lt;/p&gt;
&lt;p&gt;An application that allows Negotiate authentication to a server (that responds
wanting Negotiate) with `user1:password1` and then does another operation to
the same server also using Negotiate but with `user2:password2` (while the
previous connection is still alive) - the second request wrongly reused the
same connection and since it then sees that the Negotiate negotiation is
already made, it sends the request over that connection thinking it uses
the user2 credentials when it is in fact still using the connection
authenticated for user1...&lt;/p&gt;
&lt;p&gt;The set of authentication methods to use is set with `CURLOPT_HTTPAUTH`.&lt;/p&gt;
&lt;p&gt;Applications can disable libcurl&amp;#39;s reuse of connections and thus mitigate this
problem, by using one of the following libcurl options to alter how
connections are or are not reused: `CURLOPT_FRESH_CONNECT`,
`CURLO…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-1965</guid>
    </item>
    <item>
      <title>USN-8084-1 — curl vulnerabilities</title>
      <link>https://vulnerability.circl.lu/vuln/usn-8084-1</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:22.04:LTS: curl, Ubuntu:24.04:LTS: curl, Ubuntu:25.10: curl&lt;/p&gt;
&lt;p&gt;Zhicheng Chen discovered that curl could incorrectly reuse the wrong
connection for Negotiate-authenticated HTTP or HTTPS requests. This could
result in the use of credentials from a different connection, contrary to
expectations. (CVE-2026-1965)&lt;/p&gt;
&lt;p&gt;It was discovered that curl incorrectly leaked OAuth2 bearer tokens when
following a redirect. This could result in tokens being sent to the wrong
host, contrary to expectations. (CVE-2026-3783)&lt;/p&gt;
&lt;p&gt;Muhamad Arga Reksapati discovered that curl incorrectly reused existing
HTTP proxy connections even if the request used different credentials. This
could result in the use of incorrect credentials, contrary to expectations.
(CVE-2026-3784)&lt;/p&gt;
&lt;p&gt;Daniel Wade discovered that curl incorrectly handled certain memory
operations when doing a second SMB request to the same host. An attacker
could use this issue to cause curl to crash, resulting in a denial of
service, or possibly execute arbitrary code. This issue only affected
Ubuntu 25.10. (CVE-2026-3805)&lt;/p&gt;
&lt;p&gt;Yihang Zhou discovered that curl incorrectly reused .netrc file credentials
when following redirects. This could result in the use of credentials for
a different host, contrary to expectations. This issue only affected Ubuntu
22.04 LTS and Ubuntu 24.04 LTS. (CVE-2025-0167)&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:22.04:LTS: curl, Ubuntu:24.04:LTS: curl, Ubuntu:25.10: curl&lt;/p&gt;
&lt;p&gt;Zhicheng Chen discovered that curl could incorrectly reuse the wrong
connection for Negotiate-authenticated HTTP or HTTPS requests. This could
result in the use of credentials from a different connection, contrary to
expectations. (CVE-2026-1965)&lt;/p&gt;
&lt;p&gt;It was discovered that curl incorrectly leaked OAuth2 bearer tokens when
following a redirect. This could result in tokens being sent to the wrong
host, contrary to expectations. (CVE-2026-3783)&lt;/p&gt;
&lt;p&gt;Muhamad Arga Reksapati discovered that curl incorrectly reused existing
HTTP proxy connections even if the request used different credentials. This
could result in the use of incorrect credentials, contrary to expectations.
(CVE-2026-3784)&lt;/p&gt;
&lt;p&gt;Daniel Wade discovered that curl incorrectly handled certain memory
operations when doing a second SMB request to the same host. An attacker
could use this issue to cause curl to crash, resulting in a denial of
service, or possibly execute arbitrary code. This issue only affected
Ubuntu 25.10. (CVE-2026-3805)&lt;/p&gt;
&lt;p&gt;Yihang Zhou discovered that curl incorrectly reused .netrc file credentials
when following redirects. This could result in the use of credentials for
a different host, contrary to expectations. This issue only affected Ubuntu
22.04 LTS and Ubuntu 24.04 LTS. (CVE-2025-0167)&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/usn-8084-1</guid>
    </item>
  </channel>
</rss>
