CVE-2026-59674

Suricata przed wersjami 8.0.3 i 7.0.14 zawiera podatność polegającą na przepełnieniu liczby całkowitej bez znaku, co może prowadzić do użycia po zwolnieniu (use-after-free) w pamięci sterty podczas generowania nadmiernej liczby alertów dla pojedynczego pakietu. Problem został naprawiony w wersjach 8.0.3 i 7.0.14.

Suricata, silnik systemu wykrywania i zapobiegania włamaniom sieciowym, może ulec awarii z powodu przepełnienia stosu. Podatność dotyczy wersji od 8.0.0 do 8.0.2, a wersja 8.0.3 zawiera poprawkę.

Suricata przed wersjami 8.0.3 i 7.0.14 ma podatność na nadmierne zużycie pamięci podczas parsowania ruchu DNP3. Specjalnie spreparowany ruch może spowolnić proces i doprowadzić do wyczerpania pamięci, co może skutkować zabiciem procesu przez OOM killer.

Suricata przed wersjami 8.0.3 i 7.0.14 ma podatność na wyczerpanie pamięci przez spreparowany ruch DCERPC, co może doprowadzić do zabicia procesu. Problem dotyczy DCERPC przez UDP, a prawdopodobnie także przez TCP i SMB. Łatka jest dostępna w wersjach 8.0.3 i 7.0.14.

W Suricata przed wersją 4.x istniała możliwość wywołania wielu zbędnych sprawdzeń zawartości spreparowanego ruchu sieciowego z powodu błędu w DetectEngineContentInspection. Silnik wyszukiwania nie zatrzymywał się, gdy nie znaleziono dopasowania, co prowadziło do przekroczenia limitu rekurencji inspekcji.

Suricata przed wersją 3.2.1 ma problem z ewakuacją defragmentacji IPv4 spowodowany brakiem sprawdzenia protokołu IP podczas dopasowywania fragmentów.

W Suricata przed wersją 6.0.13, przeciwnik kontrolujący zewnętrzne źródło reguł Lua może być w stanie wykonać kod Lua. Problem ten został rozwiązany w wersji 6.0.13 poprzez wyłączenie Lua, chyba że opcja allow-rules jest ustawiona na true w sekcji konfiguracji bezpieczeństwa Lua.

Funkcja MemcmpLowercase w Suricata przed wersją 2.0.6 niewłaściwie pomija pierwszy bajt podczas porównań, co może umożliwić zdalnym atakującym obejście funkcji zapobiegania włamaniom za pomocą spreparowanego żądania HTTP.

W Suricata przed wersją 6.0.13, złośliwy podmiot kontrolujący zewnętrzne źródło reguł może wykorzystać nazwę pliku zestawu danych do wywołania przejścia katalogu, co prowadzi do możliwości zapisu na lokalnym systemie plików. Problem ten został rozwiązany w wersji 6.0.13 poprzez wprowadzenie wymogu użycia opcji allow-absolute-filenames oraz allow-write w konfiguracji reguł zestawów danych.