AI łączy drobne podatności w poważne ataki. Dlaczego „niskie” CVE przestają być bezpieczne

Działy bezpieczeństwa od lat naprawiają najpierw podatności krytyczne, a drobne odkładają na później. Igor Seletskiy, szef firmy TuxCare, ostrzega, że odkąd ataki wspiera AI, to podejście staje się niebezpieczne. Modele AI zaczynają łączyć kilka błędów o niskiej i średniej wadze w łańcuchy, których człowiek by nie zauważył. Osobno żaden z tych błędów nie wymagał pilnej reakcji. Razem dają pełne przejęcie systemu.

Jak dziś ocenia się podatności

Każda publicznie znana podatność dostaje identyfikator CVE i zwykle ocenę w skali CVSS od 0 do 10:

Seletskiy nie kwestionuje samej skali, tylko sposób jej użycia. Problem zaczyna się, gdy ocena CVSS służy jako bramka decydująca, co w ogóle zostanie naprawione. Skala nie uwzględnia łączenia błędów. Trzy drobne podatności, na przykład wyciek informacji, błąd pamięci i słaba izolacja, mogą razem dać pełne przejęcie systemu, choć żadna z nich osobno nie jest krytyczna.

Przykład: trzy drobne błędy, jedno przejęcie serwera

Seletskiy opisuje scenariusz oparty na błędach, które zapracowane zespoły bezpieczeństwa typowo odkładają:

1. Wyciek informacji o niskiej wadze. Rozbudowany komunikat błędu ujawnia adres w pamięci.
2. Luka w kontroli dostępu lub SSRF o średniej wadze. Pozwala użytkownikowi z niskimi uprawnieniami dotrzeć do wewnętrznej usługi, która nie powinna być dostępna z zewnątrz. SSRF (server-side request forgery) to błąd, przez który serwer można zmusić do wysłania zapytania tam, gdzie wskaże atakujący.
3. Błąd uszkodzenia pamięci w tej wewnętrznej usłudze. Wszyscy uznali go za „praktycznie niemożliwy do wykorzystania”, bo mechanizm ASLR losowo rozmieszcza dane w pamięci, a bez znajomości tego układu atak jest zawodny.

Po połączeniu sytuacja wygląda zupełnie inaczej. Pierwszy błąd zdradza układ pamięci, więc trzeci staje się niezawodny. Drugi daje drogę do podatnej usługi. Efekt: zdalne wykonanie kodu i przejęcie serwera.

Seletskiy podkreśla, że wkład AI nie polega na znalezieniu któregokolwiek z tych błędów. Polega na rozpoznaniu, że wyciek to brakujący składnik, który sprawia, że błąd pamięci zaczyna działać, choć zespół analizował te elementy w różnych dniach i zamknął jako mało ważne. Maszyna nie musi się zatrzymać na trzech ogniwach. Bez problemu zbuduje łańcuch z dziesięciu czy dwudziestu, którego żaden człowiek nie prześledziłby ręcznie.

Liczba otwartych błędów to osobne ryzyko

Najważniejsza teza Seletskiego jest taka: zagrożeniem nie jest ocena CVSS pojedynczego błędu, tylko to, ile błędów firma ma otwartych. Każda niezałatana podatność to kolejne ogniwo, które może połączyć się z pozostałymi, a liczba możliwych łańcuchów rośnie wykładniczo wraz z liczbą błędów, a nie liniowo. 200 odłożonych drobnych podatności to nie 200 małych problemów, tylko materiał na ogromną liczbę możliwych łańcuchów.

Dlatego zamiast liczyć krytyczne CVE, które, jak mówi, opisują to, co wyprodukował świat, a nie twoje ryzyko, proponuje śledzić cztery wskaźniki:

• Czas od wykrycia do załatania całej floty serwerów, także dla błędów niskich i średnich. Liczy się cały zegar, łącznie z czasem, jaki dostawca potrzebuje na wydanie poprawki. Jeśli producent wydaje łatkę po pół roku, szybkość twojego wdrożenia nie ma znaczenia.
• Wielkość zaległości: surowa liczba otwartych podatności.
• Wiek zaległości: jak długo błędy pozostają otwarte. Łańcuch potrzebuje tylko tego, żeby jego ogniwa były otwarte wystarczająco długo.
• Koniec z założeniem „nieosiągalne znaczy bezpieczne”. Błąd, do którego dziś nie da się dotrzeć, staje się osiągalny w chwili, gdy inne ogniwo otworzy do niego drogę.

Dlaczego nie da się wygrać, przewidując łańcuchy

Naturalnym pomysłem wydaje się użycie AI po stronie obrony do wyszukania wszystkich możliwych łańcuchów i naprawienia najgroźniejszych. Seletskiy uważa to za pułapkę. Atakujący potrzebuje znaleźć tylko jeden działający łańcuch, a obrońca musiałby zmapować wszystkie, a ich liczba rośnie wykładniczo. To wyścig, którego nie da się wygrać.

Skuteczniej jest zmniejszyć liczbę elementów, które w ogóle da się połączyć. Skoro ryzyko rośnie wykładniczo z liczbą błędów, każdy usunięty błąd usuwa nieproporcjonalnie dużą część ryzyka. Seletskiy wskazuje dwa priorytety:

1. Mniej nowych błędów: bezpieczne praktyki programistyczne, języki chroniące pamięć (np. Rust), ograniczanie powierzchni ataku i prawdziwa izolacja usług.
2. Szybkie usuwanie istniejących błędów, w tym tych o niskiej wadze.

Co to oznacza dla małej firmy i właściciela strony

Ten sam mechanizm dotyczy zwykłej strony na WordPressie czy małego sklepu internetowego. Ujawniona wersja CMS-a, lista nazw użytkowników dostępna z zewnątrz, nieaktualna wtyczka z „drobnym” błędem i słabe hasło administratora. Każda z tych rzeczy osobno wydaje się niegroźna, a razem tworzą gotową ścieżkę ataku. W praktyce:

• usuwaj nieużywane wtyczki i motywy zamiast je tylko wyłączać. Mniej kodu to mniej ogniw,
• włącz automatyczne aktualizacje tam, gdzie to bezpieczne, i nie odkładaj „drobnych” wydań,
• ogranicz ujawnianie informacji: komunikaty błędów, wersje oprogramowania, listy użytkowników,
• stosuj unikalne, silne hasła i drugi składnik dla kont administracyjnych.

Sprawdzisz to w naszych narzędziach: detektorze wersji WordPressa, detektorze enumeracji użytkowników WordPress i detektorze mieszanej treści HTTP/HTTPS. Każde z tych zgłoszeń osobno wygląda niewinnie i właśnie dlatego warto je naprawić.

Najczęściej zadawane pytania

Źródło: Jack M. Germain, „AI Makes Low-Severity Vulnerabilities More Dangerous”, TechNewsWorld, 16 lipca 2026. Rozmówca: Igor Seletskiy, TuxCare.