<?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>Tue, 06 Oct 2026 22:59:16 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-67607 — LightFTP 2.3.1 Race Condition DoS via worker_thread_cleanup</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2026-67607</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; hfiref0x LightFTP&lt;/p&gt;
&lt;p&gt;LightFTP 2.3.1 contains a residual race condition vulnerability (an incomplete fix for CVE-2024-11144) in the worker_thread_cleanup() function of ftpserv.c that allows remote unauthenticated attackers to destabilize or crash the daemon by triggering unsynchronized access to shared per-connection state without holding the required mutex lock. Attackers can send a data-transfer command such as LIST followed immediately by ABOR to exploit the missing synchronization on shared context and detached thread id reuse, resulting in daemon destabilization or crash which can lead to a denial of service. The 2.3.1 patch only narrowed the timing window (an extra re-check and reordered cleanup), it never added the missing lock, so the underlying race remains.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; hfiref0x LightFTP&lt;/p&gt;
&lt;p&gt;LightFTP 2.3.1 contains a residual race condition vulnerability (an incomplete fix for CVE-2024-11144) in the worker_thread_cleanup() function of ftpserv.c that allows remote unauthenticated attackers to destabilize or crash the daemon by triggering unsynchronized access to shared per-connection state without holding the required mutex lock. Attackers can send a data-transfer command such as LIST followed immediately by ABOR to exploit the missing synchronization on shared context and detached thread id reuse, resulting in daemon destabilization or crash which can lead to a denial of service. The 2.3.1 patch only narrowed the timing window (an extra re-check and reordered cleanup), it never added the missing lock, so the underlying race remains.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2026-67607</guid>
    </item>
  </channel>
</rss>
