Neste gang en AI-assistent anbefaler en pakke å installere, skal du sjekke om den faktisk finnes? De fleste utviklere gjør ikke det. Det er i gapet mellom forslag og verifisering at slopsquatting-angrep begynner, og på mindre enn tre år har trusselen utviklet seg fra en forskers konseptbevis til ekstern kodekjøring i autonome kodeagenter. Denne artikkelen sporer slopsquatting-utviklingen og hva hvert trinn betyr for AppSec- og DevSecOps-team.
Ny her? Start med vår innføring i Hva slopsquatting er og hvordan man kan forsvare seg mot det, og kom deretter tilbake for tidslinjen.
Et slopskvattangrep i ett avsnitt
Et slopskvattangrep registrerer en ondsinnet pakke under et navn som AI-modeller forutsigbart hallusinerer. Der typosquatting utnytter en menneskelig skrivefeil forespørsler forum forespørsler, slopsquatting utnytter selve modellen ved å finne opp et plausibelt navn som ikke finnes i noe register, og deretter krever en angriper det nøyaktige navnet før noen legitime gjør det. Begrepet ble laget av Seth Larson, sikkerhetsutvikler ved Python Software Foundation, og popularisert av Andrew Nesbitt. Det som gjør mønsteret verdt å spore, er hvor raskt det har modnet.
Sloppsquatting-evolusjon
2023: det første varselskiltet
Sikkerhetsforsker Bar Lanyado la merke til at flere LLM-er fortsatte å anbefale en pakke kalt klemmeansikt-kli, som ikke finnes (det virkelige verktøyet installeres med pip install -U “huggingface_hub[cli]”). For å demonstrere risikoen lastet han opp en tom pakke under det hallusinerte navnet. Innen tre måneder hadde den blitt lastet ned mer enn 30 000 ganger, uten null markedsføring, og det falske navnet dukket til og med opp i README-filen til et arkiv knyttet til forskning fra et stort teknologiselskap. Pakken var ufarlig. Lærdommen var ikke: et hallusinert navn trenger bare å være konsistent nok til at noen kan gjøre det til et våpen.
2024: fra blogginnlegg til vanlig dekning
I mars 2024 rapporterte The Register om AI-modeller som selvsikkert fant opp navn på programvarepakker som utviklere deretter lastet ned, noen potensielt forgiftet med skadelig programvare. Dekningen betydde mindre hva den avslørte teknisk sett enn hva den signaliserte: klemmeansikt-kli var ikke lenger en engangs kuriositet, men det første tegnet på et mønster som var alvorlig nok til at mainstream tech-presse kunne flagge, før den storstilte studien som skulle bekrefte omfanget et år senere.
2025: den første grundige målingen
USENIX Security 2025-artikkelen «Vi har en pakke for deg!» (Spracklen et al.) testet 16 kodegenereringsmodeller, kommersielle og åpen kildekode, på tvers av 576 000 Python- og JavaScript-eksempler. Den flyttet slopsquatting fra anekdote til data:
- 19.7 % av de anbefalte pakkene eksisterte ikke.
- Åpen kildekode-modeller hallusinerte langt oftere (21.7 % i gjennomsnitt) enn kommersielle (5.2 %).
- De verste synderne, CodeLlama 7B og 34B, hallusinerte i mer enn en tredjedel av resultatene sine.
- På tvers av alle modellene registrerte forskerne over 205 000 unike hallusinerte navn, et basseng stort nok til å drive vedvarende kampanjer på tvers av økosystemer.
Studien kategoriserte også hvordan forfalskningene dannes: 38 % var sammensmeltninger som slår sammen to ekte pakkenavn (nøyaktig det mønsteret som senere produserte reagere-kodeskift fra jscodeshift og react-codemod), 13 % var skrivefeillignende varianter av ekte pakker, og 51 % var rene oppspinn som er plausible, men fullstendig oppfunnet. Den første gruppen er viktigst for forsvaret, fordi et navn som er sydd sammen av to ekte verktøy er det vanskeligste å få øye på ved første øyekast.
Det viktigste funnet for angripere: hallusinasjoner er ikke tilfeldige og endres ikke ved hvert forsøk. Da forskere kjørte identiske oppgaver ti ganger hver gang, dukket 43 % av de hallusinerte navnene opp ved hver kjøring, og 58 % dukket opp mer enn én gang. En angriper trenger ikke å gjette. De observerer modellatferd, noterer navnene som stadig dukker opp, og registrerer dem først. Denne repeterbarheten er det som gjør en engangshallusinasjon til et skalerbart angrep.
2026: fra isolerte pakker til autonome agenter
I år kom det hittil klareste beviset på at slopsquatting ikke lenger er begrenset til at en utvikler kopierer og limer inn et foreslått npm installasjon.
I januar 2026 fant sikkerhetsforsker Charlie Eriksen en hallusinert npm-pakke, reagere-kodeskift, at AI-genererte agentinstruksjoner allerede hadde spredt seg over 237 repositorier via forks, med agenter som fortsatt forsøkte å installere dem daglig. Det oppsto i en enkelt commit av AI-skrevne agentferdighetsfiler som ingen mennesker hadde gjennomgått. Eriksen registrerte navnet selv, defensivt, før en angriper kunne utnytte det til et våpen.
Separat, en genuint ondsinnet pakke kalt ubrukte importer, hallusinert i stedet for det legitime eslint-plugin-ubrukt-import, fortsatte å tegne installasjoner selv etter at npm plasserte den under sikkerhetssperre, noe som viser hvor lenge et slopquatting-angrep kan fortsette å finne ofre etter at det har blitt flagget.
I juli 2026 beskrev forskere så en relatert teknikk kalt «HalluSquatting» som kjeder en hallusinasjon med en rask injeksjon: en AI-kodingsagent som henter en hallusinert ressurs på vegne av en bruker kan kapres til å kjøre angriperlevert kode. Dette utvider slopsquatting-utviklingen fra en passiv installasjonsrisiko til en aktiv vektor for ekstern kodekjøring i agentutviklingsarbeidsflyter.
Hvorfor «vibe-koding» utvidet angrepsflaten
Slopsquatting ville ikke ha spilt så stor rolle hvis AI-generert kode var en nisje. Det gjør det ikke. Fremveksten av kodeassistenter, autonome agenter og «vibe coding»-arbeidsflyter, der utviklere gjennomgår mindre av koden før de kjører den, har endret angrepsflaten på to konkrete måter.
For det første er ikke lenger inngangspunktet bare utvikleren. Et typosquatting-angrep var avhengig av at én person skrev feil. Nå oppstår feilen inne i modellen og forplanter seg til hundrevis av utviklere som stiller lignende spørsmål og får den samme hallusinerte anbefalingen.
For det andre flyttet angrepsflaten seg oppover i kjeden. Det er ikke lenger nok å se på koden et menneske skriver. Team må se på avhengighetene en AI-assistent foreslår, MCP-serverne den kobler seg til, og agentene som installerer pakker uten at noen er med i løkken. Tradisjonell AppSec, bygget for å gjennomgå databaser og menneskelige data. commits, ble aldri designet for å observere den interaksjonen mellom utvikler, AI og register, som er akkurat der slopquatting nå skjuler seg.
Hva dette betyr for forebygging
Ingenting av dette gjør generativ AI iboende usikker. Det introduserer en risiko i forsyningskjeden som tradisjonelle verktøy ikke ble bygget for å fange opp, og det krever verifiseringsprinsippene vi allerede bruker på enhver ekstern avhengighet: ikke stol på som standard, bekreft kilden, og automatiser denne verifiseringen i stedet for å stole på hver utviklers minne. Den fullstendige defensive strategiboken finnes i vår guide til AI-forsyningskjedesikkerhet, men kortversjonen er at manuell verifisering, selv om den fortsatt er nødvendig, slutter å skaleres i det øyeblikket et hallusinert navn kan nå tusenvis av utviklere samtidig, eller en agent kan installere det uten menneskelig gjennomgang i det hele tatt.
Stopp hallusinerte pakker før en agent installerer dem
Tilfellene i 2026 har én fellestrekk: den farlige installasjonen skjer uten et menneske involvert. Det er det nøyaktige gapet. Xygeni Shield er bygget for. Shield er en lettvektsagent på utviklerens endepunkt som blokkerer skadelige pakker ved installasjonstidspunktet, ved hjelp av Tidlig varsling om skadelig programvare (MEW) dommer som fungerer før noen signatur finnes. Når en AI-assistent eller autonom agent prøver å installere en hallusinert, nylig registrert pakke, Shield evaluerer den når den hentes og blokkerer den, slik at installasjonsskriptet aldri kjører, enten et menneske så på eller ikke. Hver blokk flyter inn i den samme Xygeni konsoll som kode-, bygge- og kjøretidsfunn, og Shield kjører ved siden av din eksisterende EDR i stedet for mot den.
Start gratis. Xygenis utviklerplan koster €0: 10 arkiver, 200 skanninger i måneden, opptil 5 bidragsytere, ingen kredittkort. Sign up with GitHub, GitLab eller Google, og kjør din første skanning på under 10 minutter; Shield Endepunktbeskyttelse kommer snart til utviklerabonnementet.
FAQ
Kan en pakkebehandler forhindre slopsquatting på egenhånd?
Ikke helt. npms kollisjonsdeteksjon blokkerer navn som er for like eksisterende pakker, noe som hjelper mot typosquatting, men et hallusinert navn er en helt ny streng uten kollisjon å oppdage. Hvis en angriper registrerer den hallusinerte pakken før en utvikler installerer den, fullføres installasjonen uten feil fordi pakken faktisk eksisterer. Forebygging trenger verifisering av pakkens opprinnelse og oppførsel, ikke bare registerets egne kontroller.
Hva gjør agentsakene i 2026 annerledes enn tidligere slopsquatting-saker?
Tidligere hendelser var avhengige av at et menneske kopierte og limte inn en foreslått installasjonskommando. I 2026-tilfellene installerte eller forsøkte autonome agenter å installere hallusinerte pakker uten at et menneske gjennomgikk trinnet, og HalluSquatting-teknikken gikk lenger ved å kjede en hallusinasjon med en umiddelbar injeksjon for å oppnå ekstern kodekjøring i agentens arbeidsflyt.
