slopsquatting

Slopsquatting to atak na łańcuch dostaw (supply chain attack), w którym przestępca rejestruje w publicznym repozytorium, takim jak npm czy PyPI, pakiet o nazwie zmyślonej przez model językowy. Modele generujące kod podają czasem nazwy bibliotek, które nie istnieją; OWASP zalicza takie sugestie do ryzyka niebezpiecznego generowania kodu ^[2]. Programista albo agent AI, który zaufa podpowiedzi i zainstaluje taką zależność, pobiera kod atakującego. Termin przypisuje się Sethowi Larsonowi z Python Software Foundation, a prasa branżowa opisywała go w kwietniu 2025 roku ^[4]; łączy ona słowo „slop”, czyli bylejakie treści generowane przez AI, z typosquattingiem.

Jak działa

Atak wykorzystuje halucynacje modeli językowych. Model poproszony o kod dopisuje instrukcję instalacji pakietu, który brzmi wiarygodnie, ale nigdy nie został opublikowany. Jeśli ta sama zmyślona nazwa powtarza się w odpowiedziach, atakujący może ją przewidzieć i zająć wcześniej.

OWASP opisuje ten scenariusz wprost: atakujący testują popularnych asystentów programowania, szukają często zmyślanych nazw pakietów i publikują pod nimi złośliwe pakiety w popularnych repozytoriach ^[2]. Programiści polegający na podpowiedziach włączają je potem do swojego oprogramowania ^[2]. Atakujący nie musi przeglądać logów rozmów ani zgadywać nazw na ślepo; wystarczy, że obserwuje zachowanie modeli ^[4].

Przebieg ataku pokazuje schemat poniżej.

RYS. 1Slopsquatting krok po kroku

Ryzyko rośnie przy vibe coding i przy agentach AI, które same uruchamiają polecenia instalacji. Wtedy żaden człowiek nie sprawdza nazwy pakietu przed jego pobraniem; zob. excessive agency.

Odmiany i pokrewne ataki

Slopsquatting należy do rodziny ataków na nazwy pakietów. MITRE ATT&CK opisuje technikę kompromitacji zależności oprogramowania, w tym typosquatting, czyli wybór nazw podobnych do popularnych bibliotek, oraz przejmowanie nazw porzuconych pakietów ^[6].

W WordPressie

Współczesne wtyczki i motywy WordPressa korzystają z tych samych menedżerów pakietów co reszta świata PHP i JavaScriptu. Pakiety edytora bloków są publikowane w npm w przestrzeni nazw @wordpress, na przykład @wordpress/block-editor ^[7]. Budowanie bloku zaczyna się więc często od npm install, a zaplecze wtyczki od Composera.

Model poproszony o blok albo wtyczkę może zaproponować pakiet, który tylko wygląda na oficjalny. Prawdziwe pakiety projektu mają w npm przedrostek zakresu @wordpress/ ^[7]; nazwa podobna, ale bez zakresu, wymaga sprawdzenia. To samo dotyczy nazw wtyczek z katalogu WordPress.org podawanych przez czat AI: przed instalacją warto otworzyć stronę wtyczki w katalogu i porównać autora, datę aktualizacji i liczbę instalacji. Złośliwy kod w zależności wtyczki działa z uprawnieniami całej strony, podobnie jak fałszywa wtyczka.

Zagrożenia i skutki

Pakiet zainstalowany przez slopsquatting może zawierać dowolne złośliwe oprogramowanie (malware). Kod pakietu działa z uprawnieniami programisty albo potoku budowania, który go zainstalował i uruchomił. OWASP wymienia jako skutki nieuprawniony dostęp, wstrzyknięcie złośliwego kodu i utworzenie tylnych furtek (backdoor) ^[2]. Typowy cel to eksfiltracja kluczy API, haseł do baz i innych sekretów ze środowiska programisty.

Badanie Spracklena i współautorów, przedstawione na USENIX Security 2025, objęło 576 tysięcy próbek kodu z 16 popularnych modeli ^[1]. Autorzy znaleźli 205 474 unikalne zmyślone nazwy pakietów ^[1]. Średni odsetek zmyślonych pakietów wyniósł co najmniej 5,2% dla modeli komercyjnych i 21,7% dla modeli otwartych ^[1].

Kluczowa dla atakującego jest powtarzalność. W tym samym badaniu 43% zmyślonych nazw pojawiło się we wszystkich 10 powtórzeniach zapytania, a 39% nie powtórzyło się ani razu ^[1]. W 58% przypadków zmyślona nazwa wróciła więcej niż raz na 10 prób ^[1]. Halucynacja nie jest więc przypadkowym szumem, tylko przewidywalnym celem.

Jak się bronić

• Sprawdzaj każdą nową zależność. OWASP zaleca weryfikację sugerowanych pakietów w zaufanych repozytoriach przed użyciem oraz szkolenie programistów z ograniczeń LLM ^[2]. Pakiet bez historii, z jedną wersją i bez repozytorium kodu jest sygnałem ostrzegawczym.
• Blokuj wersje. MITRE zaleca przypinanie zależności do konkretnych wersji zamiast pobierania najnowszej przy każdym budowaniu ^[6]. Plik blokady (package-lock.json, composer.lock) trzeba przeglądać przy każdej zmianie.
• Wewnętrzne repozytorium. MITRE wymienia też korzystanie z wewnętrznych repozytoriów ze sprawdzonymi pakietami zamiast źródeł zewnętrznych ^[6].
• Ograniczenia agentów. Agent AI nie powinien instalować pakietów bez zatwierdzenia przez człowieka; instalację lepiej wykonywać w piaskownicy (sandbox) albo w środowisku testowym (staging).
• Inwentaryzacja. Wykaz komponentów, czyli SBOM (wykaz komponentów oprogramowania), pozwala szybko sprawdzić, czy zgłoszony złośliwy pakiet jest w projekcie.

Autorzy badania sprawdzili także środki po stronie modeli. Najlepsze wyniki dało połączenie generowania wspomaganego wyszukiwaniem, samokorekty i dostrajania; samo dostrajanie obniżyło odsetek halucynacji modelu DeepSeek o 83%, kosztem jakości kodu ^[1]. Trzy z czterech badanych modeli rozpoznawały własne zmyślone nazwy z trafnością powyżej 75% ^[1].

Historia i przykłady

Zjawisko opisano, zanim dostało nazwę. W kwietniu 2024 roku Sekurak relacjonował pomysł badaczy wykorzystania halucynacji modeli językowych do ataków na łańcuch dostaw, obejmujący npm, PyPI i obrazy w Docker Hub ^[5]. Badacze Lasso Security opublikowali w PyPI pusty pakiet huggingface-cli, którego nazwę zmyślały modele; w ciągu trzech miesięcy pobrano go ponad 30 tysięcy razy ^[3]. Instrukcję instalacji tego pakietu znaleźli w pliku README repozytorium z badaniami firmy Alibaba ^[3]. Ten sam zespół zadał czterem modelom 47 803 pytania i odnotował odsetek halucynacji od 22,2% dla GPT-3.5 do 64,5% dla Gemini ^[3].