CVE-2026-67607
ŚrednieCVSS 5.9Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 22 - wyżej niż 22% wszystkich znanych CVE
Streszczenie
LightFTP 2.3.1 zawiera niekompletną poprawkę dla CVE-2024-11144, pozostawiając podatność na wyścig w funkcji worker_thread_cleanup(). Zdalny nieuwierzytelniony atakujący może wysłać polecenie LIST, a następnie ABOR, powodując niestabilność lub crash demona (odmowa usługi).
Ocena ryzyka
Atakujący może zdalnie spowodować awarię serwera FTP, co prowadzi do przerwania usługi i potencjalnej utraty dostępności plików.
Rekomendacja
Zastosuj poprawkę od producenta lub rozważ użycie innego serwera FTP. Tymczasowo ogranicz dostęp do serwera FTP tylko dla zaufanych hostów.
Inne podatności w LightFTP
Zobacz wszystkie- CVE-2017-1000218Krytyczne
LightFTP w wersji 1.1 jest podatny na przepełnienie bufora w funkcji 'writelogentry', co może prowadzić do odmowy usługi lub zdalnego wykonania kodu.
- CVE-2026-70637Średnie
LightFTP (do wersji 2.4) zawiera wiele podatności na wyścigi (data race) w pliku ftpserv.c, które pozwalają anonimowym atakującym na wywołanie niezdefiniowanego zachowania poprzez wysłanie poleceń LIST i ABOR bez uwierzytelnienia. Wątek kontrolny zamyka deskryptory data_socket i file_fd, podczas gdy wątki robocze równocześnie operują na tych samych polach w worker_thread_cleanup, co pozwala na ponowne przypisanie nieaktualnych deskryptorów przez system operacyjny i ich użycie przez wątki robocze na niezwiązanych zasobach, co może prowadzić do odmowy usługi.
Oryginalny opis (angielski, źródło NVD)
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.