Hvad er slopsquatting?

Hvad er slopsquatting? Det er et angreb hvor ondsindede aktører registrerer de nøjagtige pakkenavne, som AI-kodningsassistenter hallucinerer, derefter indlæser disse pakker med malware og venter på, at en udvikler installerer dem. Det er ikke et edge-case. I forskning præsenteret på USENIX Sikkerhed 2025, 19.7 % af de pakker, der blev anbefalet af AI-kodningsmodeller på tværs af 576,000 kodeeksempler, eksisterede ikke, og forskere registrerede over 205,000 unikke hallucinerede navne på tværs af de testede modeller.

Det er vigtigt at forstå, hvad slopsquatting er (og hvad slopsquatting betyder i praksis), fordi det ikke bare er en kunstig intelligens-særhed. Slopsquatting er efterfølgeren til AI-æraen. stavefejl, med én afgørende forskel: typosquatting afhænger af en menneskelig skrivefejl, mens slopsquatting afhænger af en models fejl, der gentages forudsigeligt nok til, at en angriber kan udnytte den i stor skala. Denne guide forklarer, hvad slopsquatting er, hvorfor det spreder sig hurtigere end pakkeanmeldelse kan opdage det, hvilke risici det skaber, og hvordan organisationer kan opdage og forhindre det, før det når produktion.

Slopsquatting Betydning: Definition #

Slopsquatting betyder formelt: praksissen med at registrere et pakkenavn, som en stor sprogmodel hallucinerer, et opfundet navn, der lyder plausibelt, men ikke findes i noget offentligt register, og indlæse det med ondsindet kode. før en rigtig udvikler installerer det baseret på AI'ens forslag.

Udtrykket udvider konceptet typosquatting (registrering af et pakkenavn, der efterligner et rigtigt navn gennem en almindelig stavefejl) til den specifikke fejltilstand i generativ AI. Hvor typosquatting udnytter et menneskes stavefejl, udnytter slopsquatting en AI-models hallucinationernEn kodeassistent anbefaler pip install eller npm install til en pakke, der aldrig har eksisteret, og en angriber, der har bemærket det samme opfundne navn, der gentages på tværs af prompts, registrerer det først.

I praksis betyder slopsquatting følgende: et forsyningskædeangreb, der forvandler en models fejl til en fungerende udnyttelse, uden at der kræves nogen menneskelig fejl ud over at stole på AI'ens forslag. Det er ikke teoretisk. En enkelt hallucineret pakke, plantet som en godartet test i 2023, tiltrak over 30,000 downloads på tre måneder uden nogen form for promovering og bekræftede, at ondsindede varianter, der udnytter netop dette mønster, findes i offentlige registre i dag.

Slopsquatting vs. Typosquatting: Hvad er forskellen? #

Slopsquatting og typosquatting deler det samme resultat (en udvikler installerer en ondsindet pakke i den tro, at den er legitim), men kilden til fejlen er kategorisk forskellig.

Typosquatting afhænger af en menneskelig skrivefejl: en udvikler har til hensigt at skrive requests og skriver reqeusts i stedet, og en angriber, der registrerede det stavefejlede navn, venter. Risikoen er knyttet til ét udviklers tastetryk, ét øjebliks uopmærksomhed.

Slopsquatting fjerner den menneskelige fejl fuldstændigt og erstatter den med en modelfejl, en fejl der gentages i stor skala på tværs af alle udviklere, der modtager en lignende prompt. Opfølgende analyse viste, at når forskere kørte identiske prompter ti gange hver, dukkede 43% af de hallucinerede pakkenavne op i hver eneste kørsel, og 58% gentog sig mere end én gang. Denne gentagelsesnøjagtighed er det, der gør slopsquatting udnyttelig: en angriber behøver ikke at gætte en tastefejl. De behøver kun at observere hvilket hallucineret navn en model bliver ved med at gentage og registrere det, før en rigtig udvikler gør det.

Den største forskel er skala. En typosquatted-pakke venter på en skriveulykke. En slopsquatted-pakke venter på, at den samme AI-genererede anbefaling når den næste udvikler, og den efter den, og den efter den, på tværs af alle organisationer, der bruger den samme model.

Hvorfor Slopsquatting Spreads? #

Slopsquatting spreder sig af samme grund som typosquatting altid har gjort: angribere udnytter et forudsigeligt mønster, som udviklere som standard har tillid til. Det nye er omfanget af tillid.

Fremkomsten af ​​AI-assisteret kodning, autonome agenter og "vibe coding"-arbejdsgange, hvor udviklere gennemgår mindre og mindre kode, før de kører den, har ændret softwareangrebsfladen på to konkrete måder:

Indgangspunktet er ikke længere kun udvikleren. Et typosquatting-angreb afhænger af én persons skrivefejl. Slopsquatting kan opstå inde i selve modellen og sprede sig til hundredvis af forskellige udviklere, der stiller lignende spørgsmål og modtager den samme hallucinerede anbefaling, hvilket mangedobler rækkevidden af ​​et enkelt angreb.

Angrebsfladen er rykket længere op i kæden. Det er ikke længere nok at gennemgå den kode, et menneske skriver. Teams skal også holde øje med de afhængigheder, en AI-assistent foreslår, de MCP-servere, den opretter forbindelse til, og de agenter, der installerer pakker autonomt uden direkte menneskelig gennemgang. Traditionel AppSec, bygget til at gennemgå lagre og menneskelige data. commits, blev aldrig designet til at observere denne nye interaktion mellem udvikler, AI og pakkeregister, hvilket er præcis der, slopsquatting gemmer sig.

Risici ved slopsquatting #

Sloppsquatting skaber risiko på tværs af dimensioner, der forværrer hinanden, og tendensen accelererer snarere end at forsvinde.

• Gentagen udnyttelse. Fordi hallucinerede navne ikke er tilfældige, dukker det samme falske navn forudsigeligt op på tværs af sessioner og modeller. Angribere behøver ikke at gætte; de ​​skal kun observere modeladfærd og registrere de navne, der bliver ved med at dukke op igen, hvilket forvandler en engangshallucination til et skalerbart, gentageligt angreb.
• Agentisk forplantning. Slopsquatting er ikke længere begrænset til, at en udvikler kopierer og indsætter en foreslået installationskommando. I januar 2026 fandt forskere ud af, at AI-kodningsagenter allerede havde spredt instruktioner, der refererede til en hallucineret npm-pakke, på tværs af 237 arkiver, hvor agenter stadig forsøgte at installere den dagligt uden et menneske i loopet til at opdage fejlen.
• Undgåelse af navnelighed. Omkring 38% af hallucinerede navne ligner meget rigtige pakker, hvilket mindsker sandsynligheden for, at en udvikler ser erstatningen med det samme. En ondsindet pakke, der placerer ét tegn væk fra en betroet afhængighed, ser ikke mistænkelig ud; det ligner en tastefejl, du selv ville lave.
• Vedvarende eksponering efter detektion. En hallucineret pakke, der erstattede et legitimt ESLint-plugin, registrerede stadig ugentlige downloads, selv efter at registreringsdatabasen havde sat den under en sikkerhedsspærring, hvilket beviser på, at det at markere en slopsquatted-pakke ikke øjeblikkeligt forhindrer den i at blive installeret.

Hvor Sloppsquatting gemmer sig #

Den sværeste del af slopsquatting at opdage er, at det ikke ligner et angreb i det øjeblik, det sker; det ligner en normal pip-installation eller npm-installation, der fuldføres korrekt, fordi pakken rent faktisk eksisterer, når en angriber har registreret den.

Slopsquatting går typisk igennem:

• AI-kodningsassistenter og copiloter. Det oprindelige forslag, et opfundet pakkenavn præsenteret sammen med legitim, fungerende kode, er der, hvor sårbarheden stammer fra. Intet ved den omgivende kode ser forkert ud, fordi det er den normalt ikke; kun afhængigheden er falsk.
• Autonome kodningsagenter. Agentiske arbejdsgange, der installerer afhængigheder uden menneskelig gennemgang, fjerner det ene kontrolpunkt, en udvikler, der holder pause for at bekræfte et navn, som ellers ville fange en hallucineret pakke, før den når et projekt.
• Pakkeadministratorer uden verifikationstrin. Hverken pip install eller npm install giver en fejl, når målpakken findes og er skadelig. Installationen fuldføres normalt, fordi der fra pakkehåndteringens perspektiv ikke er noget galt.

Sådan opdager og forebygger du slopsquatting #

Forebyggelse af slopsquatting kræver ikke eksotiske værktøjer. Det kræver systematisk anvendelse af afhængighedshygiejnepraksisser, der allerede findes, i stedet for at slække på dem i det øjeblik, en AI "foreslår" koden.

Bekræft enhver ny pakke, før du installerer den, især en foreslået af en AI-assistent. Bekræft, at den findes i det officielle register, hvem der vedligeholder den, hvornår den blev udgivet, og om dens downloadnumre ser ægte ud.

Antag aldrig, at AI-genereret kode som standard er sikkerKode, der "virker", betyder ikke, at dens afhængigheder er legitime. Gennemgang af afhængigheder bør være en del af kodegennemgangen, ikke en undtagelse fra den.

Implementer afhængighedsscanning, der markerer risikomønstre ud over kendte CVE'er: anomale pakker, navne, der mistænkeligt ligner eksisterende, nye vedligeholdere uden historik eller installation af scripts med usædvanlig opførsel.

Anvend AI-SPM som styringslag. AI Security Posture Management er den praksis, der er designet til at fange præcis denne type AI-introduceret risiko i stor skala, løbende at opdage AI-foreslåede afhængigheder og score dem, før et menneske nogensinde behøver at huske at tjekke manuelt.

Sikring mod squatting med Xygeni #

Slopsquatting kan ikke forhindres alene ved udviklernes årvågenhed. En politik, der siger "bekræft alle AI-foreslåede pakker", skalerer ikke på tværs af en organisation, hvor afhængighedsforslag ankommer hurtigere, end nogen menneskelig gennemgangsproces kan følge med.

Xygenis tilgangen behandler dette som et kontinuerligt detektionsproblem: AI-opgørelse og AI BOM afsløre alle AI-introducerede afhængighed på tværs af SDLC, hvilket giver teams en levende registrering af, hvad en AI-assistent rent faktisk har foreslået og installeret. Xygeni Shield, drevet af MEW (Tidlig advarsel om malware), registrerer og blokerer ondsindede pakker, inklusive slopsquattede pakker, før en signatur findes, og lukker dermed præcis det hul, som signaturbaserede scannere efterlader åbent.

Hvis dine teams bruger AI-kodningsassistenter, er slopsquatting-problemet allerede til stede. Spørgsmålet er, om det næste hallucinerede navn bliver opdaget, før det bliver installeret.

Ofte stillede spørgsmål #