Slopsquatting: AI smokkelt malware in je project.

AI-tools verzinnen pakketten die niet bestaan

Je vraagt een AI-codeerassistent om een functie te schrijven. De code die terugkomt ziet er netjes uit en bevat bovenaan een import of require van een pakket met een geloofwaardige naam. Je installeert het, de code compileert, alles werkt. Alleen: dat pakket bestond een week geleden nog niet. De AI heeft de naam verzonnen — en iemand anders heeft hem geregistreerd met kwaadaardige code erin.

Dit heet slopsquatting: een aanvalstechniek die inspeelt op een eigenschap van AI-modellen die hallucinatie wordt genoemd. Het model genereert een pakketnaam die er logisch uitziet — vaak een combinatie van bestaande namen — maar die in werkelijkheid niet bestaat. Een aanvaller registreert die naam op een openbare pakketbeheerder zoals npm, PyPI of Packagist, en wacht tot ontwikkelaars of AI-agents het installeren.

De cijfers: hoe vaak hallucineren AI-modellen pakketnamen?

Het antwoord kwam van onderzoekers van de Universiteit van Texas in San Antonio en de Universiteit van Oklahoma, die hun bevindingen presenteerden op het USENIX Security Symposium 2025. Ze lieten 16 veelgebruikte AI-modellen voor codegeneratie 576.000 codevoorbeelden produceren in Python en JavaScript. Het resultaat:

• 19,7% van alle gegenereerde codevoorbeelden bevatte minstens één pakketnaam die niet bestaat
• In totaal vonden ze 205.474 unieke verzonnen pakketnamen
• Bij commerciële modellen (GPT-4, Claude, Gemini) lag het hallucinatiepercentage op minimaal 5,2%
• Bij open-source modellen steeg dat naar 21,7%

Het gevaarlijkste gegeven: 43% van de verzonnen namen komt bij herhaling terug. Stel dezelfde vraag tien keer, en bijna de helft van de niet-bestaande pakketnamen verschijnt elke keer opnieuw. Dat maakt ze voorspelbaar — en dus doelwit voor een aanvaller.

react-codeshift: van hallucinatie naar 237 projecten

In januari 2026 stuitte beveiligingsonderzoeker Charlie Eriksen van Aikido Security op een npm-pakket met de naam react-codeshift. De naam klinkt logisch — het lijkt een combinatie van de bestaande tools jscodeshift en react-codemod — maar het pakket had nooit bestaan.

Wat er was gebeurd: een AI-model had de naam verzonnen terwijl het instructies genereerde voor agent-skills. Die instructies werden gecommit naar een repository, en die repository werd geforkt en vertaald naar andere talen. Zo verspreidde de verzonnen pakketnaam zich naar 237 GitHub-projecten, zonder dat een mens de naam had bedacht of gecontroleerd.

Ondertussen bleef de naam als spookpakket rondgaan. Volgens het onderzoek van de Cloud Security Alliance probeerden autonome AI-agents het pakket dagelijks te installeren, totdat Eriksen de naam zelf registreerde om de keten te doorbreken.

30.000 installaties in drie maanden

Hoe effectief slopsquatting in de praktijk is, bewees beveiligingsbedrijf Lasso Security met een bewust experiment. Ze registreerden het pakket huggingface-cli op PyPI — een naam die AI-modellen regelmatig hallucineren als verwijzing naar het echte huggingface-hub. Het pakket bevatte geen kwaadaardige code, alleen een tracker.

Binnen drie maanden was het meer dan 30.000 keer geïnstalleerd. Niet door bots, maar door echte ontwikkelaars en geautomatiseerde pipelines die de door AI gegenereerde instructies volgden.

Waarom slopsquatting gevaarlijker is dan typosquatting

Bij typosquatting registreert een aanvaller een naam die lijkt op een bestaand pakket — requets in plaats van requests — en hoopt dat iemand een typefout maakt. Dat werkt, maar het is toeval: elke individuele ontwikkelaar heeft een kleine kans om precies die fout te maken.

Slopsquatting draait dat om. Het AI-model doet het distributiewerk: iedereen die dezelfde vraag stelt, krijgt dezelfde verzonnen naam te zien. En omdat die namen voorspelbaar terugkomen, kan een aanvaller gericht de populairste hallucinaties claimen. Het is geen toeval meer, maar een kanaal.

Daar komt bij dat vibe coding — het zonder review overnemen van AI-gegenereerde code — steeds gangbaarder wordt. Hoe meer teams AI-tools inzetten zonder menselijke controle op dependencies, hoe groter het aanvalsoppervlak.

Niet alleen npm en Python

Het USENIX-onderzoek richtte zich op npm (JavaScript) en PyPI (Python), maar het mechanisme is universeel. Overal waar een pakketbeheerder publieke registratie toestaat, werkt de aanval:

• Composer (PHP/Laravel) — via Packagist
• Maven Central (Java)
• RubyGems (Ruby)
• NuGet (.NET)
• Go modules — iets minder kwetsbaar omdat de modulenaam aan een repository is gebonden, maar niet immuun

Voor PHP-projecten die met Composer werken, geldt hetzelfde advies: een AI-model kan een pakketnaam hallucineren die er geloofwaardig uitziet maar niet op Packagist bestaat. Registreert een aanvaller die naam, dan is de weg naar je vendor/-map kort.

Wat je eraan doet

Slopsquatting is niet te voorkomen aan de bron — AI-modellen zullen blijven hallucineren. De verdediging zit in je ontwikkelproces:

1. Gebruik lockfiles en vertrouw erop

Een composer.lock, package-lock.json of poetry.lock legt exact vast welke versie van welk pakket geïnstalleerd is. Staat een pakket niet in je lockfile, dan wordt het niet geïnstalleerd — ongeacht wat de AI aanbeveelt. Commit je lockfiles altijd mee en draai install, niet update, in je CI/CD-pipeline.

2. Controleer elke nieuwe dependency handmatig

Voordat een nieuw pakket in je project komt, controleer je op zijn minst: bestaat het pakket echt? Wie is de maintainer? Hoe oud is het? Hoeveel downloads heeft het? Een pakket dat vorige week is aangemaakt, nul sterren heeft en een naam draagt die verdacht veel lijkt op een bestaand pakket, verdient extra aandacht.

3. Draai geautomatiseerde dependency-audits

Tools als npm audit, composer audit en platforms als Snyk of Dependabot scannen je dependencies op bekende kwetsbaarheden. Ze vangen niet elke slopsquatting-aanval op, maar vormen een extra laag. Integreer ze in je CI/CD zodat een build faalt als er een bekende kwetsbaarheid in je dependencies zit.

4. Beperk de installatiemogelijkheden van AI-agents

Laat je AI-agents of codeerassistenten geen pakketten installeren zonder menselijke goedkeuring. Steeds meer tools ondersteunen dependency-controles in hun workflow. Bij agentic workflows geldt: hoe meer autonomie een agent heeft, hoe strenger de vangrails moeten zijn.

5. Pin je pakketversies

Gebruik exacte versienummers in je composer.json of package.json in plaats van ranges als ^1.0. Dat voorkomt dat een geüpdatete versie — of een nieuw geregistreerd pakket met dezelfde naam — automatisch wordt binnengehaald.

Hoe wij hiermee omgaan

Bij Coding Agency geldt voor elk project: geen enkele nieuwe dependency komt in de codebase zonder handmatige controle. We werken met lockfiles die bij elke deployment exact dezelfde versies installeren, draaien geautomatiseerde audits via onze CI/CD-pipeline en controleren bij elke nieuwe dependency of het pakket legitiem is.

Bij projecten waar AI-codeertools een rol spelen, is de regel eenvoudig: de AI mag code voorstellen, maar de mens beslist welke pakketten worden geïnstalleerd. Dat kost een paar minuten per dependency en voorkomt dat een verzonnen pakket ongecontroleerd in productie belandt.

Gebruik je AI-tools in je ontwikkelproces en wil je weten of je dependency-beheer op orde is? Neem contact op — we kijken graag mee.