Slopsquatting: gdy halucynacja AI staje się złośliwym pakietem

Asystenci AI do kodowania na stałe zagościli w edytorach, terminalach i przeglądarkach. Pytasz o skrypt, dostajesz gotowy kod z gotowymi importami. Problem w tym, że część tych importów odnosi się do pakietów, które nie istnieją — model po prostu je wymyślił, wygenerował nazwę wiarygodną na tle tysięcy importów, które widział podczas treningu. A tam, gdzie w rejestrze istnieje luka pod realistycznie brzmiącą nazwą, prędzej czy później pojawia się ktoś, kto ją wypełni złośliwym kodem. Ta technika nazywa się slopsquatting — termin ukuł badacz bezpieczeństwa Seth Larson jako nawiązanie do typosquattingu, tylko że błąd popełnia tym razem nie człowiek przy klawiaturze, tylko model.

Halucynacja z adresem zwrotnym

Modele językowe nie wyszukują pakietów w rejestrze — odgadują je. Kiedy programista prosi o kod do generowania plików PDF albo analizy danych, asystent wygeneruje import tak, jakby pakiet istniał, bo statystycznie tak wyglądają odpowiedzi na tego typu polecenia. Nazwa brzmi wiarygodnie, opis brzmi wiarygodnie, a programista — zwłaszcza ten, który przegląda kod pobieżnie — zakłada, że skoro model go polecał, to pakiet jest sprawdzony.

Atakujący nie musi nawet znać konkretnej rozmowy. Wystarczy, że uruchomi model tym samym asystentem, zbierze nazwy pakietów, które model wymyśla regularnie, a następnie zarejestruje je w PyPI albo npm. Publikuje pakiet o tej samej nazwie, z opisem sugerującym dokładnie tę funkcję, o którą chodziło w poleceniu. Od tej chwili każda kolejna osoba, której asystent wygeneruje ten import, może zainstalować złośliwy kod — często bez ani jednego ostrzeżenia.

Skala zjawiska

Halucynacje nazw pakietów to nie sporadyczna ciekawostka, tylko systemowa właściwość modeli do generowania kodu. Badania naukowców z University of Texas at San Antonio, Virginia Tech i University of Oklahoma, opublikowane w 2025 roku, objęły 576 tysięcy próbek kodu Pythona i JavaScriptu wygenerowanych przez szesnaście popularnych modeli. Wynik: 19,7 procent poleconych pakietów nie istniało. Open-source’owe modele halucynowały średnio w 21,7 procent przypadków, komercyjne — w 5,2 procent. Łącznie badacze zidentyfikowali ponad 205 tysięcy unikalnych, nieistniejących nazw pakietów. Halucynacje nie były też przypadkowe: w próbach, w których polecenia konsekwentnie wywoływały nieistniejące zależności, 43 procent takich nazw powtarzało się w podobnych zapytaniach — według badaczy z firmy Socket to właśnie powtarzalność czyni je niezawodnym celem dla atakujących.

Warto przy tym zachować poczucie proporcji. W 2023 roku badacz Bar Lanyado zarejestrował w PyPI wymyśloną przez modele nazwę „huggingface-cli” — jego pusta paczka zebrała ponad 30 tysięcy pobrań w ciągu trzech miesięcy, co dowodzi, że mechanizm działa. Do połowy 2026 roku nie odnotowano jednak jeszcze udokumentowanego ataku, w którym slopsquatting posłużyłby do rzeczywistego włamania. Skala ryzyka rośnie wraz z liczbą agentów, które instalują zależności automatycznie.

Dlaczego agenci zmieniają zasady gry

Przez lata obroną przed typosquattingiem i złośliwymi pakietami był człowiek w pętli: recenzent kodu, który spojrzał na diff pull requesta, inżynier, który przepuścił zależności przez narzędzie do analizy składu oprogramowania. Agenty programowanie tę barierę eliminuje. Asystent działający w trybie autonomicznym sam tworzy plan, sam instaluje zależności, sam uruchamia kod — a użytkownik patrzy na wynik, nie na każdy krok pośredni.

To otwiera drogę do ataku, którego nie da się powtórzyć przeciwko klasycznemu workflow. Złośliwy pakiet zainstalowany przez agenta wykonuje się w środowisku, które często ma dostęp do kluczy API, poświadczeń chmurowych i plików projektu. Skrypt instalacyjny nie musi nawet psuć budowania — wystarczy, że po cichu wyśle poświadczenia dalej. Podobne techniki są znane z klasycznych ataków na łańcuch dostaw oprogramowania, ale slopsquatting daje im nowy wektor: atakujący nie musi już wyobrażać sobie, jaką nazwę pakietu mógłby ktoś błędnie wpisać. Model robi to za niego — i robi to konsekwentnie.

Jak się bronić

Obrona nie wymaga rezygnacji z asystentów AI, tylko zmiany założeń: każdy import sugerowany przez model traktujemy jak kod niezaufany, nie jak rekomendację sprawdzonej biblioteki.

• Weryfikuj istnienie pakietu w rejestrze — zanim cokolwiek zainstalujesz, sprawdź, jak długo pakiet jest publikowany, kto go utrzymuje, ile ma pobrań. Pakiet zarejestrowany wczoraj, bez historii, to sygnał ostrzegawczy.
• Wymuszaj zatwierdzanie w agentach — wyłącz automatyczne instalowanie zależności. W narzędziach agentowych, które działają autonomicznie, instalacja pakietu powinna być jawnie potwierdzana przez człowieka.
• Przeglądaj zmiany zależności w diffach — narzędzie do przeglądu kodu powinno wyróżniać nowe zależności i świeżo opublikowane wersje, a nie tylko zmiany w kodzie własnym.
• Używaj analizy składu oprogramowania — narzędzia typu SCA wykrywają złośliwe pakiety i podejrzane metadane, w tym świeże publikacje podszywające się pod znane projekty.
• Zgłaszaj halucynowane nazwy — rejestrów PyPI i npm można ostrzegać o podejrzanych pakietach podszywających się pod nieistniejące projekty; to skraca czas życia złośliwej publikacji.

Oznaczenie treści AI

Ten artykuł powstał z udziałem sztucznej inteligencji: research oraz tekst przygotował i zredagował agent AI. Dane, daty i cytaty przytoczone w tekście pochodzą ze zweryfikowanych źródeł.