GNU Aspell: trzy CVE w słownikach i kompresowanych listach słów

6 października CERT Polska opisał trzy podatności GNU Aspell: CVE-2026-75818, CVE-2026-75819 i CVE-2026-75820. Obejmują wersje wcześniejsze niż 0.60.8.3. Komunikat wskazuje poprawki w kodzie oraz zapowiada ich wydanie w 0.60.8.3; samo istnienie zmian nie potwierdza dostępności poprawionego pakietu w danym środowisku.

Rekomendacja Breachroad: sprawdź, czy Aspell występuje w używanych aplikacjach lub procesach przetwarzania tekstu, skąd pochodzą ładowane słowniki i kto odpowiada za aktualizację zależności. Nie zakładaj, że każda aplikacja sprawdzająca pisownię używa tego komponentu.

Trzy problemy, różne wejścia

CVE-2026-75818 dotyczy dekompresora prezip-bin. Przetworzenie odpowiednio przygotowanego pliku skompresowanego może prowadzić do uszkodzenia pamięci sterty i awarii procesu. Scenariusz wymaga przekonania użytkownika do przetworzenia pliku.

CVE-2026-75819 obejmuje ładowanie binarnych słowników .rws. Nieprawidłowa walidacja offsetów może spowodować ujawnienie pamięci sterty lub odmowę usługi przez awarię aplikacji po wczytaniu przygotowanego słownika.

CVE-2026-75820 dotyczy obsługi osobistych list słów. Obcięcie długości słowa zapisywanej w jednym bajcie może powodować uszkodzenie sterty i odmowę usługi po załadowaniu przygotowanej listy.

Te opisy pochodzą z rekordów CVE. Nie rozszerzamy ich na potwierdzone wykonanie dowolnego kodu. Wspólny praktyczny temat to granica zaufania do pliku, który trafia do komponentu słownikowego.

Ustal, gdzie komponent rzeczywiście działa

Nasza propozycja dla administratorów i deweloperów: zacznij od inwentaryzacji zależności aplikacji, obrazów kontenerowych i narzędzi używanych do obróbki tekstu. Dla każdego znalezionego przypadku zapisz właściciela, pochodzenie pakietu, wersję oraz sposób dostarczania aktualizacji.

Następnie sprawdź, czy proces przyjmuje słowniki, listy słów lub skompresowane pliki z zewnętrznego źródła. Materiał przesłany przez użytkownika, kontrahenta albo pobrany z serwisu wymaga osobnej oceny od pliku utrzymywanego we własnym repozytorium. W naszej ocenie ta różnica pomaga ustalić kolejność działań.

Jeśli komponent nie występuje w danej aplikacji, udokumentuj wynik sprawdzenia. Jeżeli występuje, powiąż go z konkretnym procesem i kontem. Sama obecność biblioteki na dysku nie pokazuje jeszcze, czy aplikacja ją ładuje i jakie dane może do niej dotrzeć.

Poprawka potrzebuje dowodu wdrożenia

CERT Polska wskazuje zmiany naprawiające wszystkie trzy problemy i planowane wydanie. Przed zamknięciem zadania uzyskaj potwierdzenie od opiekuna aplikacji lub dostawcy pakietu, że używana kompilacja zawiera odpowiednie poprawki. Dostawca może przenieść je do własnego pakietu; w takim przypadku zachowaj jego komunikat wraz z identyfikatorem wydania.

Zalecamy też sprawdzić uruchomioną aplikację lub faktycznie wdrożony obraz. Zaktualizowany katalog zależności nie jest dowodem, że każdy działający proces korzysta już z nowej biblioteki. W razie oczekiwania na pakiet wyznacz właściciela wyjątku, termin ponownego sprawdzenia i ograniczenia dla przyjmowanych plików.

Ograniczenie nieufnych wejść, izolacja przetwarzania i minimalne uprawnienia to nasze propozycje zmniejszenia ekspozycji. Nie przedstawiamy ich jako zamiennika poprawki ani dowodu usunięcia podatności.

Przykład dla zespołu redakcyjnego i IT

Wyobraźmy sobie redakcję otrzymującą od zewnętrznego współpracownika „słownik branżowy”. W tym przykładowym scenariuszu pracownik przekazuje plik do wyznaczonej osoby, zamiast samodzielnie podłączać go do narzędzia. IT ustala, czy aplikacja korzysta z Aspell, potwierdza stan poprawek i dopiero wtedy rozpatruje użycie materiału w uzgodnionym procesie.

To przykład organizacyjny Breachroad, nie incydent opisany przez CERT Polska. Pokazuje, że nazwa pliku i deklaracja nadawcy nie zastępują sprawdzenia jego pochodzenia oraz odbiorcy technicznego. Podobne decyzje można przećwiczyć na szkoleniu cyberbezpieczeństwa dla organizacji, łącząc zasady pracowników z odpowiedzialnością zespołu IT za zależności i aktualizacje.