<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-21T21:28:33.751564+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/cve-2026-92388</id>
    <title>CVE-2026-92388 — FTP wildcard write callback mixup</title>
    <updated>2026-10-21T21:28:33.754714+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> curl</p>
<p>When an FTP wildcard `LIST` operation fails, libcurl omits the restoration
path meant for successful listings, leaving the write callback set to the
internal listing parser and the write callback data pointing directly to the
easy handle. Subsequent reuse of this handle triggers an immediate crash, and
cloning it via `curl_easy_duphandle()` copies this corrupted state into the
duplicate. If the original handle is subsequently freed, executing a transfer
on the cloned handle causes a heap use-after-free read against the dangling
handle reference; alternatively, reusing the original or cloned handle while
changing only  `CURLOPT_WRITEDATA` (and omitting `CURLOPT_WRITEFUNCTION`)
results in type confusion, forcing the internal parser to interpret incoming
server response bytes into memory at the application-supplied write data
pointer.</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/cve-2026-92388"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/usn-8927-1</id>
    <title>USN-8927-1 — curl vulnerabilities</title>
    <updated>2026-10-21T21:28:33.754786+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Ubuntu:26.04:LTS: curl</p>
<p>It was discovered that curl, when built with GnuTLS support, had an
out-of-bounds read in the WebSocket send path. An attacker could
possibly use this issue to obtain sensitive information.
(CVE-2026-107928)</p>
<p>Maksim discovered that curl did not correctly include the interface
binding in connection reuse decisions when CURLOPT_INTERFACE was used.
An attacker could possibly use this issue to cause connections to go
out from an unintended source address. (CVE-2026-107929)</p>
<p>Stanislav Fort discovered that curl did not properly clear AWS SigV4
authentication state when CURLOPT_AWS_SIGV4 was set to NULL. An
attacker could possibly use this issue to obtain sensitive information.
(CVE-2026-86409)</p>
<p>Stanislav Fort discovered that the curl command line tool did not set
SSH host verification options when following redirects to SFTP or SCP
URLs. An attacker could possibly use this issue to perform
machine-in-the-middle attacks. (CVE-2026-86410)</p>
<p>Stanislav Fort discovered that curl did not properly handle cookie jar
entries that could not be reloaded. An attacker could possibly use this
issue to cause a denial of service. (CVE-2026-86412)</p>
<p>Stanislav Fort discovered that an HTTP proxy could trick libcurl into
sending credentials to the proxy itself by responding to a CONNECT
request with an unexpected authentication challenge. An attacker could
possibly use this issue to obtain sensitive information.
(CVE-2026-86414)</p>
<p>Stanislav Fort discovered that curl did not correctly handle HSTS
entries…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/usn-8927-1"/>
  </entry>
</feed>
