Op 4 augustus 2026 duikt er een npm-worm Keyv op die niet bij één pakket blijft. Wat begon met de release van keyv@6.0.0 breidde al snel uit naar honderden npm-pakketten over meerdere organisaties. Onderzoekers koppelden de campagne aan het stelen van inloggegevens en aan het gebruik van installatiegedrag (zoals preinstall-scripts) om payloads in ontwikkel- en CI-omgevingen te activeren.
In dit artikel zetten we de belangrijkste feiten op een rij: wat er precies werd ingezet, hoe de verspreiding volgens analyses tot stand kwam, welke omgevingen het meest risico lopen en wat je als beheerder of ontwikkelaar concreet kunt controleren.
Hoe de npm-worm Keyv zich verspreidde
De eerste bevestigde schadelijke release was keyv@6.0.0. Die versie plaatste een extra stap in het installatieproces: node setup.mjs als onderdeel van de preinstall. Daarmee activeert een installatie van het pakket automatisch extra code zodra het in een omgeving draait waar lifecycle-scripts zijn toegestaan.
De besmetting bleef niet beperkt tot Keyv zelf. SafeDep controleerde honderden “poisoned versions” en rapporteerde onder andere aantallen versies en pakketnamen in de npm-registry. Later kwamen aanvullende meldingen van andere partijen naar voren, maar het totaal kon niet los worden gereconstrueerd met één volledig openbare lijst van alle betrokken pakketten op het moment van rapportage.
Belangrijk: de gerapporteerde aantallen gaan over besmette package-artifacts, niet automatisch over het aantal getroffen machines. Het daadwerkelijke risico voor jouw organisatie hangt af van welke exacte pakketten en versies bij jullie zijn geïnstalleerd, en of de relevante lifecycle-stap is uitgevoerd.
Wat de payload doet: credentials en private keys
Volgens SafeDep en Socket steelt de npm-worm Keyv niet alleen “standaard” gegevens. De gebruikte mechanismen zijn gericht op het verzamelen van gevoelige materialen in de context van de developer of CI-runner.
De analyses beschrijven dat de bundel onder meer informatie kan oogsten uit:
- repository’s en npm-gerelateerde omgevingen
- package registry-context
- cloudconfiguraties en private-key materiaal
- systemen zoals Vault, Kubernetes, en database- en private-key data
- ook wordt het gedrag in het geheugen van GitHub Actions runners meegenomen in de payload-analyse
Daarnaast beschrijft de payload dat hij de mogelijkheid heeft om “verder te vergiftigen” via npm-publicatierechten. Met andere woorden: zodra de aanvaller toegang heeft tot geschikte publishing-identiteiten, kan de campagne zich heruitgeven als nieuwe, geautoriseerde releases.
Waarom preinstall-scripts dit gevaarlijk maken
Het kernpunt van de dreiging zit in het installatiepad. De npm-worm Keyv vertrouwt op een preinstall-script dat lifecycle-scripts in ontwikkel- en CI-omgevingen kan laten draaien. Dat betekent: zelfs als je niet actief “kwaad” opzoekt, kan het gedrag zichzelf uitvoeren tijdens het installeren van dependencies.
Er is ook een nuance: npm 12 blokkeert ongeautoriseerde lifecycle-scripts standaard. Oudere npm-clients en andere installroutes waar lifecycle-scripts wel (of alsnog) worden toegestaan, blijven daarom gevoeliger. Met andere woorden: compatibiliteit en je tooling bepalen mede hoe groot de blootstelling is.
Extra routes: Claude Code en VS Code hooks
Naast het preinstall-mechanisme noemt de rapportage een tweede uitvoeringsroute. In de Keyv-repository stonden afzonderlijke hooks voor Claude Code en Visual Studio Code die payloadcode kunnen starten wanneer een gebruiker vertrouwen geeft aan de workspace of projectinstellingen accepteert.
Concreet wordt gewezen op bestanden in de repo, zoals een session start hook in een .claude-configuratie en taken die draaien bij bepaalde events (zoals het openen van een folder). Omdat code-editoren niet altijd automatisch taken uitvoeren in elke default-setup, is de activatie niet “voor iedereen tegelijk”. Maar als een omgeving eenmaal de betreffende configuratie accepteert, kan de payload alsnog worden gestimuleerd.
Socket merkt op dat werkstations of CI-runners die een getroffen versie hebben uitgevoerd, als credential-exposed moeten worden behandeld: het uitgangspunt is dat de aanval mogelijk tokens, sleutels of andere geheimen al heeft geprobeerd te bemachtigen.
De vals-positieven valkuil: tags veranderen te snel
Een extra complicatie voor incidentrespons is dat de npm-registry in de tijd snel verandert. In de melding wordt bijvoorbeeld beschreven dat pagina’s voor latest-tags eerdere releases tijdelijk terug konden tonen als “latest” voor meerdere pakketten uit de initiële set.
Daardoor is een eenvoudige aanpak zoals “kijk naar de huidige latest-tags” onvoldoende. Als je wilt bepalen of je blootgesteld bent, moet je werken met:
- de exacte pakketnamen
- de resolved versies die bij jullie daadwerkelijk zijn geïnstalleerd
- lockfiles (zoals wat je build reproduceerbaar maakt)
Een namespace-level blocklist (blokkeren op basis van het hele namespace) kan dan zowel besmette versies missen als onschuldige releases onterecht als compromis behandelen.
Provenance en “legitieme” releaseflow: geen garantie
Een opvallend detail is dat de Keyv-release door de normale GitHub Actions releaseworkflow is gegaan. In de rapportage wordt genoemd dat de release geldige OpenID Connect– en SLSA-provenance had: de attestation kon aantonen welk buildproces is gebruikt.
Maar: provenance kan niet automatisch bevestigen dat de broncode die in die pipeline binnenkwam veilig was. Met andere woorden, de releaseworkflow kan “juist uitgevoerd” zijn, terwijl de inhoud toch gemanipuleerd was door een aanvaller die toegang kreeg tot het publiceren of de repositorycontext.
Wat je nu moet doen: praktische checks
Omdat de aanval gericht is op credentials, private keys en publicatiemechanismen, komt incidentrespons neer op twee vragen: hebben jullie de getroffen versions geïnstalleerd en zijn mogelijke geheimen al misbruikt?
SafeDep geeft daarbij ook een specifieke waarschuwing rondom het moment van roteren. De “revocation watcher” is gekoppeld aan revokatie als trigger. Als je token-rotatie eerst doet, kan dat (volgens het advies) juist een lokaal handlerpad activeren dat door de aanvaller is voorbereid. Daarom is het advies om die watcher eerst te verwijderen voordat je blootgestelde tokens en sleutels roteert.
Concreet kun je starten met:
- Inventarisatie van dependencies: welke keyv-versie (en verwante packages) staan in lockfiles?
- Controleren of install- en buildstappen preinstall/lifecycle scripts hebben uitgevoerd op ontwikkelaarsmachines of CI-runners.
- Scope bepalen op basis van exacte versies en resoluties, niet op tags alleen.
- Als er een getroffen versie draait of gedraaid heeft: behandel systemen als credential-exposed en voer rotatie uit volgens het advies (incl. het eerst verwijderen van de revokatiewatcher).
Heb je daarnaast tooling die editor-hooks of workflow-configuraties automatisch toepast? Dan is het extra belangrijk om te verifiëren welke projectinstellingen in jouw omgevingen zijn geaccepteerd.
Vergelijkbare supply chain risico’s
De aanpak van de npm-worm Keyv sluit aan bij het bredere patroon van supply chain aanvallen: code wordt niet “remote” uitgevoerd door de aanvaller, maar door het vertrouwen van je build- en installketen. Als je hier dieper op wilt duiken, zijn er op onze site ook artikelen die het mechanisme van supply chain misbruik vanuit npm en andere ecosystemen belichten, zoals malafide npm-pakketten via supply chain: RAT-alert.
Ook voor context rond compromittering via development workflows en AI-gerelateerde integraties kan het nuttig zijn om de raakvlakken te bekijken tussen aanvallen op agenten en CI-achtige omgevingen. In dezelfde sfeer van governance en misbruik is er bijvoorbeeld AI-agent governance: Obsidian Security haalt 85 miljoen.
Belangrijkste takeaways
De npm-worm Keyv laat zien hoe snel een supply chain dreiging kan opschalen. De kern van het risico zit in:
- een schadelijke preinstall-stap die in ontwikkel- en CI-omgevingen kan draaien
- credential- en private-key oogst
- extra executiekanalen via editor hooks (Claude Code en VS Code)
- een verspreiding die niet altijd netjes te herleiden is via “latest”-tags
- provenance-attestaties die het buildpad onderbouwen, maar niet automatisch de bronveiligheid
Door te werken met exacte dependency-resoluties, lockfiles en installgedrag kun je je blootstelling veel betrouwbaarder inschatten dan met alleen registry-tags.
Heb je nog vragen over hoe je dit in jouw pipeline kunt verifiëren, of wil je een checklist voor dependency-inventarisatie en credential-rotatie? Dan help ik je graag met een praktische aanpak op basis van jouw stack en tooling.
Bron: https://thehackernews.com/2026/08/keyv-linked-npm-worm-poisons-hundreds.html
