Hva er slopsquatting?

Hva er slopsquatting? Det er et angrep der ondsinnede aktører registrerer de nøyaktige pakkenavnene som AI-kodingsassistenter hallusinerer, og deretter laster disse pakkene med skadelig programvare og venter på at en utvikler skal installere dem. Det er ikke et edge-tilfelle. I forskning presentert på USENIX Sikkerhet 2025, 19.7 % av pakkene som ble anbefalt av AI-kodingsmodeller på tvers av 576 000 kodeeksempler eksisterte ikke, og forskere loggførte over 205 000 unike hallusinerte navn på tvers av modellene som ble testet.

Det er viktig å forstå hva slopsquatting er (og hva slopsquatting betyr i praksis) fordi det ikke bare er en kunstig intelligens-eienhet. Slopsquatting er etterfølgeren til AI-tiden. Typosquatting, med én kritisk forskjell: typosquatting avhenger av en menneskelig skrivefeil, mens slopsquatting avhenger av en modells feil, gjentatt forutsigbart nok til at en angriper kan utnytte den i stor skala. Denne veiledningen forklarer hva slopsquatting er, hvorfor det sprer seg raskere enn pakkegjennomgang kan fange det opp, hvilke risikoer det skaper, og hvordan organisasjoner kan oppdage og forhindre det før det når produksjon.

Slopsquatting Betydning: Definisjon #

Slopsquatting betyr formelt: praksisen med å registrere et pakkenavn som en stor språkmodell hallusinerer, et oppfunnet navn som høres plausibelt ut, men ikke finnes i noe offentlig register, og laste det med ondsinnet kode. før en ekte utvikler installerer den basert på AI-ens forslag.

Begrepet utvider konseptet typosquatting (registrering av et pakkenavn som etterligner et ekte navn gjennom en vanlig stavefeil) til den spesifikke feilmodusen til generativ AI. Der typosquatting utnytter et menneskes skrivefeil, utnytter slopsquatting en AI-modellens hallusinasjonernEn kodeassistent anbefaler pip install eller npm install for en pakke som aldri har eksistert, og en angriper som har lagt merke til at det samme oppdiktede navnet gjentar seg på tvers av ledetekster, registrerer det først.

I praksis betyr «slopsquatting» dette: et forsyningskjedeangrep som gjør en modells feil om til en fungerende utnyttelse, uten at det kreves noen menneskelige feil utover å stole på AI-ens forslag. Det er ikke teoretisk. En enkelt hallusinert pakke, plantet som en godartet test i 2023, trakk over 30 000 nedlastinger på tre måneder uten null markedsføring og bekreftet at ondsinnede varianter som utnytter akkurat dette mønsteret, finnes i offentlige registre i dag.

Slopsquatting vs. Typosquatting: Hva er forskjellen? #

Slopsquatting og typosquatting deler samme utfall (en utvikler installerer en ondsinnet pakke i den tro at den er legitim), men kilden til feilen er kategorisk forskjellig.

Typosquatting avhenger av en menneskelig skrivefeil: en utvikler har til hensikt å skrive forespørsler og skriver inn forespørsler i stedet, og en angriper som registrerte det feilstavede navnet venter. Risikoen er knyttet til ett utviklers tastetrykk, ett øyeblikks uoppmerksomhet.

Slopsquatting fjerner den menneskelige feilen fullstendig og erstatter den med en modellfeil, en som gjentas i stor skala på tvers av alle utviklere som mottar en lignende melding. Oppfølgingsanalyse fant at da forskere kjørte identiske meldinger ti ganger hver, dukket 43 % av de hallusinerte pakkenavnene opp i hver eneste kjøring, og 58 % gjentok seg mer enn én gang. Denne repeterbarheten er det som gjør slopsquatting utnyttbart: en angriper trenger ikke å gjette en skrivefeil. De trenger bare å observere hvilket hallusinert navn en modell gjentar og registrere det før en ekte utvikler gjør det.

Den største forskjellen er skala. En typosquatted-pakke venter på en skriveulykke. En slopsquatted-pakke venter på at den samme AI-genererte anbefalingen skal nå den neste utvikleren, og den etter den, og den etter den, på tvers av alle organisasjoner som bruker samme modell.

Hvorfor slopsquatting spreads? #

Slopsquatting sprer seg av samme grunn som typosquatting alltid har gjort: angripere utnytter et forutsigbart mønster som utviklere stoler på som standard. Det nye er omfanget av tillit.

Fremveksten av AI-assistert koding, 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:

Inngangspunktet er ikke lenger bare utvikleren. Et typosquatting-angrep avhenger av én persons skrivefeil. Slopsquatting kan oppstå i selve modellen og spre seg til hundrevis av forskjellige utviklere som stiller lignende spørsmål og mottar den samme hallusinerte anbefalingen, noe som mangedobler rekkevidden til et enkelt angrep.

Angrepsflaten har beveget seg lenger opp i kjeden. Det er ikke lenger nok å gjennomgå koden et menneske skriver. Team må også følge med 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 data. commits, ble aldri designet for å observere denne nye interaksjonen mellom utvikler, AI og pakkeregister, og det er nettopp der slopquatting skjuler seg.

Risikoer ved slopsquatting #

Sloppsquatting skaper risiko på tvers av dimensjoner som forsterker hverandre, og trenden akselererer snarere enn å dabbe ut.

• Gjentatt utnyttelse. Fordi hallusinerte navn ikke er tilfeldige, dukker det samme falske navnet opp igjen på en forutsigbar måte på tvers av økter og modeller. Angripere trenger ikke å gjette; de ​​trenger bare å observere modellens atferd og registrere navnene som stadig dukker opp, noe som gjør en engangshallusinasjon til et skalerbart, repeterbart angrep.
• Agentisk forplantning. Slopsquatting er ikke lenger begrenset til at en utvikler kopierer og limer inn en foreslått installasjonskommando. I januar 2026 fant forskere ut at AI-kodingsagenter allerede hadde spredt instruksjoner som refererte til en hallusinert npm-pakke på tvers av 237 repositorier, med agenter som fortsatt forsøkte å installere den daglig, uten at noen var med på å oppdage feilen.
• Unngåelse av navnelikhet. Omtrent 38 % av hallusinerte navn ligner sterkt på ekte pakker, noe som reduserer sjansen for at en utvikler oppdager erstatningen med et øyeblikk. En ondsinnet pakke som sitter ett tegn unna en klarert avhengighet ser ikke mistenkelig ut; det ser ut som en skrivefeil du ville ha laget selv.
• Vedvarende eksponering etter deteksjon. En hallusinert pakke som erstattet en legitim ESLint-plugin registrerte fortsatt ukentlige nedlastinger selv etter at registeret plasserte den under sikkerhetssperre, noe som beviser at flagging av en slopsquatted-pakke ikke umiddelbart stopper installasjonen av den.

Der Sloppsquatting gjemmer seg #

Det vanskeligste å fange opp med slopsquatting er at det ikke ser ut som et angrep i det øyeblikket det skjer; det ser ut som en vanlig pip-installasjon eller npm-installasjon som fullføres, fordi pakken faktisk eksisterer når en angriper har registrert den.

Slopsquatting går vanligvis inn gjennom:

• AI-kodingsassistenter og styrmenn. Det første forslaget, et oppfunnet pakkenavn presentert sammen med legitim, fungerende kode, er der sårbarheten stammer fra. Ingenting ved den omkringliggende koden ser feil ut, fordi den vanligvis ikke er det; bare avhengigheten er falsk.
• Autonome kodeagenter. Agentiske arbeidsflyter som installerer avhengigheter uten menneskelig gjennomgang fjerner det ene kontrollpunktet, en utvikler som stopper opp for å bekrefte et navn, som ellers ville fanget opp en hallusinert pakke før den når et prosjekt.
• Pakkebehandlere uten verifiseringstrinn. Verken pip install eller npm install gir en feilmelding når målpakken finnes og er skadelig. Installasjonen fullføres normalt fordi ingenting er galt fra pakkebehandlerens perspektiv.

Hvordan oppdage og forhindre slopsquatting #

Å forhindre slopsquatting krever ikke eksotiske verktøy. Det krever systematisk bruk av avhengighetshygienepraksiser som allerede finnes, i stedet for å lempe på dem i det øyeblikket en AI «foreslår» koden.

Bekreft enhver ny pakke før du installerer den, spesielt en som er foreslått av en AI-assistent. Bekreft at den finnes i det offisielle registeret, hvem som vedlikeholder den, når den ble publisert, og om nedlastingsnumrene ser ekte ut.

Aldri anta at AI-generert kode er trygg som standardKode som «fungerer» betyr ikke at avhengighetene er legitime. Avhengighetsgjennomgang bør være en del av kodegjennomgangen, ikke et unntak fra den.

Implementer avhengighetsskanning som flagger risikomønstre utover kjente CVE-er: avvikende pakker, navn som er mistenkelig like eksisterende, nye vedlikeholdere uten merittliste eller installer skript med uvanlig oppførsel.

Bruk AI-SPM som styringslag. AI Security Posture Management er praksisen som er utformet for å fange opp nettopp denne typen AI-introdusert risiko i stor skala, og kontinuerlig oppdage AI-foreslåtte avhengigheter og score dem før et menneske trenger å huske å sjekke manuelt.

Sikring mot sløving med Xygeni #

Slopsquatting kan ikke forhindres bare ved utviklernes årvåkenhet. En policy som sier at «verifiser alle AI-foreslåtte pakker» skaleres ikke på tvers av en organisasjon der avhengighetsforslag kommer raskere enn noen menneskelig gjennomgangsprosess kan holde tritt med.

Xygenis Tilnærmingen behandler dette som et kontinuerlig deteksjonsproblem: AI-inventar og AI BOM komme til overflaten av alle AI-introduserte avhengighet på tvers av SDLC, noe som gir teamene en levende oversikt over hva en AI-assistent faktisk har foreslått og installert. Xygeni Shield, drevet av MEW (tidlig advarsel om skadelig programvare), oppdager og blokkerer ondsinnede pakker, inkludert slopsquattede, før en signatur finnes, og tetter dermed det samme gapet som signaturbaserte skannere etterlater åpent.

Hvis teamene dine bruker AI-kodeassistenter, er problemet med slopquatting allerede til stede. Spørsmålet er om det neste hallusinerte navnet blir fanget opp før det blir installert.

FAQ #