54 z 55 zgłoszonych podatności było fałszywych. Jedna dostała 10.0 w skali CVE

👁 145 przeczytań

Firma JFrog ujawniła, że jedno nowe konto na GitHubie zgłosiło 55 podatności w ciągu zaledwie kilku dni, z czego 54 były całkowicie zmyślone - wygenerowane przez model językowy i nieodzwierciedlające żadnych realnych błędów w oprogramowaniu.

Wśród sfabrykowanych wpisów znalazły się rzekome krytyczne luki w SQLite, bibliotece obrazów libraw oraz dekoderze audio Arduino. Raporty opisywały poważne błędy pamięciowe z ocenami sięgającymi 9.8, lecz wskazywane funkcje nie istniały w cytowanych wersjach, a dołączony kod proof-of-concept uruchamiał się bez żadnych błędów. Narzędzie GPTZero potwierdziło maszynowe pochodzenie tekstów. Jedyna prawdziwa podatność w tej paczce była obudowana fałszywymi metadanymi.

Czytasz Promptowego częściej? Dodaj go do preferowanych źródeł w Google, a nowe teksty będą wyżej w Twoich wynikach.

Jak fikcja stała się oficjalnym rekordem

Fałszywe wpisy nie zatrzymały się na GitHubie. Trafiły do Narodowej Bazy Podatności (NVD) - rządowego rejestru USA traktowanego jako autorytatywne źródło przez skanery bezpieczeństwa na całym świecie. Red Hat przyznał jednemu ze sfabrykowanych wpisów dotyczących SQLite ocenę 10.0, by później obniżyć ją do 7.6. SQLite dodał wspomnianą funkcję dopiero w 2025 roku - rok po wersji, którą rzekomo miała uszkadzać.

System działa na zaufaniu: każdy może zgłosić podatność przez publiczny formularz MITRE, a ciała przydzielające identyfikatory CVE w dużej mierze przyjmują słowo zgłaszającego. Jak zauważył inżynier Oracle Alan Coopersmith:

„CNA często nie jest w stanie samodzielnie zweryfikować zgłoszenia.”

NIST, który dawał gwarancję ręcznej weryfikacji każdego wpisu, zawiesił głębszą analizę na początku 2024 roku pod presją rosnącej liczby zgłoszeń. Zaległość przekroczyła 27 000 niezweryfikowanych raportów do końca 2025 roku.

Jak wskazuje badacz JFrog Afek Berger, asymetria jest fundamentalna: wygenerowanie przekonującego fałszywego raportu kosztuje dziś niemal nic, a jego weryfikacja - przeczytanie kodu źródłowego, zbudowanie wersji, uruchomienie PoC - kosztuje tyle samo co zawsze.

Najpoważniejszy scenariusz to nie sam fałszywy wpis, lecz to, że kolejny system AI może przeczytać go i zacząć „łatać” kod, który nigdy nie był zepsuty.

// czytaj dalejFałszywe alarmy detektorów AI: od konstytucji USA po sprawy studentówArtykułyFałszywy alert RCB: jak odróżnić prawdziwy SMS od oszustwaArtykułyGumloop w praktyce: research leadów, sortowanie zgłoszeń i raporty z wielu źródełArtykuły