Problemet i én setning
Neste gang en AI-assistent anbefaler en pakke å installere, skal du faktisk sjekke om den pakken finnes? De fleste utviklere har ikke det. Det er nettopp det gapet mellom forslag og verifisering som starter med slopsquatting-angrep, og det er derfor det å forstå både utviklingen av slopsquatting og praktisk forebygging av slopsquatting har blitt en reell prioritet for AppSec- og DevSecOps-team.
Hva er et slopsquatting-angrep?
Et slopquatting-angrep er en variant av Typosquatting (praksisen med å registrere et domene- eller pakkenavn som etterligner et legitimt navn gjennom en vanlig stavefeil, for eksempel forespørsler istedenfor forespørsler(i håp om at brukerens egen skrivefeil fører dem rett dit), men med en viktig forskjell i hvor feilen stammer fra. Typosquatting utnytter menneskelige skrivefeil. Et slopsquatting-angrep utnytter feilene store språkmodeller gjør: en LLM «hallusinerer» et pakkenavn som høres helt legitimt ut, men som ikke finnes i noe offentlig register, og en angriper kommer dit først ved å registrere det nøyaktige navnet før noen med gode intensjoner gjør det.
Mekanismen bak et typisk slopsquatting-angrep er enkel, og det er nettopp denne enkelheten som gjør det effektivt:
- En utvikler ber en AI-assistent om hjelp til å løse et kodeproblem.
- Modellen genererer en løsning som importerer eller anbefaler å installere en pakke som aldri har eksistert.
- En angriper som har lagt merke til at flere modeller gjentar det samme hallusinerte navnet, registrerer den pakken på npm, PyPI eller et annet offentlig register, med skadelig kode inni. Dette er øyeblikket hallusinasjonen blir til et faktisk slopquatting-angrep.
- Den neste utvikleren som får det samme forslaget og ikke bekrefter det, installerer den nå ekte pakken, som er en bakdør inn til miljøet deres.
Begrepet «slopsquatting» ble myntet av Seth Larson, sikkerhetsutvikler ved Python Software Foundation, og popularisert av Andrew Nesbitt, for å beskrive nettopp dette mønsteret: en «pakkehallusinasjon» forvandlet til en angrepsvektor.
Sloppy squatting evolusjon: hvordan en forskningsnysgjerrighet vokste til en reell trussel
Det som er bemerkelsesverdig med utviklingen av slopsquatting er ikke bare konseptet; det er hvor raskt det gikk fra en forskningsobservasjon til en dokumentert, målbar angrepsklasse.
2023: Det første varseltegnet. Sikkerhetsforsker Bar Lanyado la merke til at flere LLM-er gjentatte ganger anbefalte en pakke kalt klemmeansikt-kli, som ikke finnes (den virkelige pakken er installert med pip install -U “huggingface_hub[cli]”For å demonstrere risikoen lastet han opp en tom versjon av pakken til et offentlig register. Innen tre måneder hadde den mottatt over 30 000 nedlastinger, uten null markedsføring. Det hallusinerte navnet dukket til og med opp i README-filen til et arkiv knyttet til forskning fra Alibaba, noe som tidlig viste hvordan disse «falske» navnene kunne lekke inn i ekte dokumentasjon og legge grunnlaget for de slopquatting-angrepene som ville følge.
2024: Risikoen flyttes fra en forskers blogginnlegg til vanlig teknologidekning. I mars 2024, Registeret rapporterte om hvordan AI-modeller selvsikkert oppfant navn på programvarepakker som utviklere deretter lastet ned, noen av dem potensielt forgiftet med skadelig programvare. Denne dekningen spilte mindre rolle for hva den avslørte teknisk og mer for hva den signaliserte: huggingface-cli-saken var ikke lenger en engangs kuriositet; det var det første tegnet på et mønster alvorlig nok til at mainstream teknologipresse ville flagge, før den storstilte akademiske studien som skulle bekrefte omfanget et år senere.
2025: Den første grundige målingen av problemet i stor skala. Avisen «Vi har en pakke for deg! En omfattende analyse av pakkehallusinasjoner fra kodegenererende LLM-er» (Spracklen et al., presentert på USENIX Sikkerhet Symposium) testet 16 kodegenereringsmodeller, både kommersielle (GPT-4, GPT-3.5) og åpen kildekode (CodeLlama, DeepSeek, WizardCoder, Mistral), på tvers av 576 000 Python- og JavaScript-kodeeksempler. Funnene markerer et tydelig punkt i utviklingen av slopsquatting, og flytter det fra anekdote til data:
- 19.7% av pakkene som ble anbefalt av modellene eksisterte ikke.
- Åpen kildekode-modeller hallusinerte mye oftere (21.7% i gjennomsnitt) enn kommersielle modeller (5.2%).
- De verste synderne, CodeLlama 7B og CodeLlama 34B, hallusinerte i mer enn en tredjedel av resultatene sine.
- På tvers av alle testede modeller logget forskerne over 205 000 unike hallusinerte pakkenavn, et basseng stort nok til å gi næring til vedvarende slopquatting-angrep på tvers av flere økosystemer.
- Én detalj som er spesielt relevant for forebygging: omtrent 38% av hallusinerte navn lignet sterkt på ekte pakker, noe som reduserer sjansen for at noen oppdager dem med et raskt blikk.
En kritisk detalj fra studien, og sannsynligvis grunnen til at utviklingen av slopsquatting har akselerert snarere enn å forsvinne, er at hallusinerte navn ikke er tilfeldige, og de endres ikke ved hvert forsøk. De samme modellene har en tendens til å gjenta de samme oppfunnede navnene når de får lignende prompter, noe som betyr at en angriper ikke trenger å gjette. De trenger bare å observere modellens atferd, identifisere navnene som stadig dukker opp, og registrere dem før en ekte utvikler gjør det. Oppfølgingsanalyse av denne repeterbarheten fant at da forskere kjørte identiske prompter ti ganger hver, dukket 43 % av de hallusinerte pakkenavnene opp ved hver eneste kjøring, og 58 % gjentok seg mer enn én gang, noe som beviser at de fleste hallusinasjoner er repeterbare artefakter snarere enn engangsstøy. Denne repeterbarheten er det som gjør en engangshallusinasjon til et skalerbart slopsquatting-angrep.
2026: Fra isolerte pakker til autonome agenter. Dette året har gitt det klareste beviset hittil på at slopsquatting ikke lenger er begrenset til at en utvikler kopierer og limer inn et foreslått pip installasjon or npm installasjon kommando. I januar 2026, forsker Charlie Eriksen hos Aikido Security fant de ut at AI-kodingsagenter allerede hadde spredt instruksjoner som refererte til en hallusinert npm-pakke, reagere-kodeskift (et navn som plausibelt blander sammen to virkelige verktøy, jscodeshift og react-codemod), på tvers av 237 repositorier, med agenter som fortsatt prøver å installere det daglig. Eriksen registrerte navnet selv, defensivt, før en angriper kunne bevæpne det. Separat, en virkelig ondsinnet pakke kalt ubrukte importer, hallusinert i stedet for det legitime eslint-plugin-ubrukt-import, registrerte fortsatt omtrent 233 ukentlige nedlastinger tidlig i 2026 til tross for at npm satte det under en sikkerhetssperre, et tegn på hvor lenge et slopsquatting-angrep kan fortsette å tiltrekke seg ofre selv etter at det er flagget. Nylig, i juli 2026, beskrev forskere en relatert teknikk, kalt «HalluSquatting», som lenker en AI-hallusinasjon med en rask injeksjon slik at en AI-kodingsagent som henter en hallusinert ressurs på vegne av en bruker kan kapres til å kjøre angriperlevert kode, og dermed utvide utviklingen av slopsquatting fra en passiv installasjonsrisiko til en aktiv ekstern kodekjøringsvektor i agentutviklingsarbeidsflyter.
Hvorfor «vibe-koding» utvidet overflaten for slopquatting-angrep
Slopsquatting-angrep ville ikke hatt så stor betydning hvis AI-generert kode var en nisjepraksis. Det er det ikke. Fremveksten av kodeassistenter, autonome agenter og «vibe coding»-arbeidsflyter, der utviklere gjennomgår mindre og mindre av koden før de kjører den, har endret programvarens angrepsflate på to konkrete måter, og begge akselererer utviklingen av slopsquatting:
- Inngangspunktet er ikke lenger bare utvikleren. Et typosquatting-angrep pleide å være avhengig av at én enkelt person gjorde en skrivefeil. Nå kan feilen oppstå i selve modellen og spre seg til hundrevis av forskjellige utviklere som stiller lignende spørsmål og får den samme hallusinerte anbefalingen, noe som mangedobler rekkevidden til et enkelt slopsquatting-angrep.
- Angrepsflaten har beveget seg lenger opp i kjeden. Det er ikke lenger nok å se på koden et menneske skriver. Team må også se på avhengighetene en AI-assistent foreslår, MCP-serverne den kobler seg til, og agentene som installerer pakker autonomt uten direkte menneskelig gjennomgang. Tradisjonell AppSec, bygget for å gjennomgå databaser og menneskelige commits, ble aldri designet for å observere denne nye interaksjonen mellom utvikler, AI og pakkeregister, som er akkurat der slopquatting-angrep nå gjemmer seg.
Ingenting av dette betyr at generativ AI er iboende usikker. Det betyr at den introduserer en ny type forsyningskjederisiko som tradisjonelle sikkerhetsverktøy ikke ble bygget for å fange opp, og en risiko som krever de samme 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 hukommelse eller årvåkenhet. Denne automatiseringen er grunnlaget for enhver reell strategi for forebygging av slopsquatting.
Forebygging av slopsquatting: hva lag kan gjøre i dag
Den gode nyheten er at forebygging av slopsquatting ikke krever eksotiske verktøy. Det krever systematisk anvendelse av avhengighetshygienepraksiser som allerede finnes, men som mange team slapper av i det øyeblikket en AI de stoler på «foreslår» koden. En effektiv tilnærming til forebygging av slopsquatting kombinerer vanligvis følgende:
- Bekreft manuelt enhver ny pakke før du installerer den, spesielt når det kommer fra et forslag fra en AI-assistent. Bekreft at det finnes i det offisielle registeret, hvem som vedlikeholder det, når det ble publisert, og om nedlastingstallene ser ekte ut. Denne ene vanen er den billigste formen for slopquatting-forebygging som er tilgjengelig for ethvert lag.
- Aldri anta at AI-generert kode er trygg som standard. En kodebit som «fungerer» betyr ikke at avhengighetene er legitime. Avhengighetsgjennomgang bør være en del av kodegjennomgangen, ikke et unntak fra den.
- Bruk låsefiler og hash-verifisering for å feste eksakte versjoner og hindre en stille oppdatering i å bytte i en annen pakke enn den som opprinnelig ble revidert.
- Implementer avhengighetsskanning som flagger risikomønstre utover kjente CVE-er: uregelmessige pakker, navn som er mistenkelig like eksisterende, nye vedlikeholdere uten meritthistorikk, eller installasjonsskript med uvanlig oppførsel. En nylig publisert pakke med nesten ingen historikk som etterligner navnet på noe «nesten» kjent, er akkurat mønsteret bak de fleste slopquatting-angrepene som er dokumentert så langt.
- Behandle offentlige registre med samme skepsiscism som enhver annen ubekreftet ekstern kilde. Det faktum at pip installasjon or npm installasjon At det ikke kaster en feil er ikke et bevis på legitimitet.
- Trene utviklingsteam på det faktum at AI-assistert koding ikke fjerner ansvaret for å bekrefte hva som installeres; det legger bare til et trinn som må bygges inn i arbeidsflyten som en del av enhver seriøs plan for forebygging av slopsquatting.
Ingen av disse tiltakene er nye i seg selv. Det som har endret seg er omfanget: når et avhengighetsforslag ikke lenger kommer fra Stack Overflow eller en kollega, men fra en modell som kan gjenta den samme hallusinerte feilen til tusenvis av forskjellige utviklere, slutter manuell verifisering, selv om den fortsatt er nødvendig, å være nok i seg selv. Det er derfor flere team automatiserer dette laget med slopquatting-forebygging i sine Analyse av programvarekomposisjon (SCA) verktøy, i stedet for å overlate det til den enkelte utviklers disiplin.
Dette er førcishvorfor ASPM plattformer i likhet med Xygeni bygge inn deteksjon av mistenkelige avhengigheter, som dekker typosquatting, avhengighetsforvirring og kjente ondsinnede pakker, i den samme analysen av åpen kildekode og AI-avhengighet pipeline, så forebygging av slopquatting avhenger ikke av at alle utviklere husker å sjekke det hver gang en AI-assistent foreslår en ny avhengighet.
FAQ
Er et slopsquatting-angrep det samme som et typosquatting-angrep?
Ikke helt. Begge involverer registrering av et falskt pakkenavn for å lure den som installerer det, men kilden til feilen er forskjellig. Typosquatting utnytter menneskelige skrivefeil. Et slopsquatting-angrep utnytter pakkenavn oppfunnet (hallusinert) av AI-modeller, som en angriper deretter registrerer før de i det hele tatt eksisterer legitimt.
Kan en pakkebehandler automatisk forhindre denne typen angrep?
Ikke helt, og det er nettopp derfor forebygging av slopsquatting ikke kan stoppes på pakkebehandlernivå. Hvis en angriper registrerer den hallusinerte pakken før en utvikler prøver å installere den, vil installasjonen fullføres uten feil fordi pakken faktisk eksisterer, selv om den er skadelig. Effektiv forebygging krever ytterligere verifisering av pakkens opprinnelse og oppførsel.
Påvirker dette bare modeller med åpen kildekode?
Nei. Studien til Spracklen et al. fant hallusinasjoner på tvers av alle testede modeller, inkludert kommersielle, men med en betydelig lavere rate (5.2 % mot 21.7 % for de evaluerte modellene med åpen kildekode). Ingen modell er helt fri for problemet, noe som er en del av grunnen til at utviklingen av slopsquatting holder tritt med veksten av AI-assistert koding generelt.
Er dette en teoretisk risiko, eller har den allerede blitt utnyttet?
Ocuco klemmeansikt-kli I dette tilfellet viser en tom pakke lastet opp av en forsker som ble lastet ned mer enn 30 000 ganger på tre måneder uten null markedsføring, at risikoen ikke bare er teoretisk: et hallusinert navn trenger bare å være konsistent nok på tvers av forskjellige ledetekster til at noen kan gjøre det om til et skikkelig slopquatting-angrep.
