De aanval die geen CVE kreeg - wat de Mastra npm-breach betekent voor AI-supplychains

Hier ga ik eerlijk over zijn: toen ik het bericht las over 144 gecompromitteerde npm-packages in het Mastra AI-framework, was mijn eerste reactie niet "hoe kan dit?" maar "waarom duurde het zo lang?"

Niet omdat ik cynisch ben. Omdat de aanval niets exploiteerde wat we niet al jaren weten.

Geen CVE, geen code-exploit, geen zero-day

Op 17 juni 2026, tussen 01:12 en 02:39 UTC, publiceerde een Noord-Koreaanse staatshacker 144 packages in de @mastra scope opnieuw, elk met een geïnjecteerde dependency die bij npm install een credential-stealing trojan afvuurde. Microsoft Threat Intelligence attribueerde de aanval met "high confidence" aan Sapphire Sleet, dezelfde groep achter de Axios-compromittatie in maart.

Wat me opviel: er is geen CVE. Geen code-exploit. Geen zero-day. De Mastra source code is nooit aangeraakt.

Wat de aanvaller wél exploiteerde waren twee ontwerpbeslissingen in hoe npm werkt, en die zijn allebei by design.

Twee features, één aanvalspad

Eén: npm's registry trekt scope publish-rechten niet in wanneer een contributor inactief wordt. Het account "ehindero", een echte voormalige Mastra-contributor, had sinds februari 2025 niets meer gepubliceerd. Zestien maanden later waren de rechten op 144 packages nog steeds geldig. SafeDep's forensische analyse toonde aan dat het om credential-diefstal ging: zelfde accountnaam, ander e-mailadres.

Twee: SemVer caret-range resolutie. ^1.11.21 betekent "installeer 1.11.21 of elke hogere compatibele patch, automatisch." De aanvaller publiceerde eerst een schone easy-day-js@1.11.21, een byte-voor-byte kopie van de legitieme dayjs library. De volgende dag: easy-day-js@1.11.22, visueel identiek maar met een postinstall hook die een obfuscated dropper afvuurde. Omdat @mastra packages ^1.11.21 specificeerden, resolveerde elke verse npm install automatisch naar de besmette versie.

Geen lockfile-wijziging. Geen repository-commit. Geen zichtbaar signaal.

Wat de dropper deed

De postinstall hook draaide vóór elke applicatiecode, vóór linting, vóór security scanning. De dropper schakelde TLS-certificaatverificatie uit, contacteerde C2-infrastructuur op 23.254.164.92, downloadde een tweede-staps payload als verborgen Node.js-proces, en verwijderde zichzelf.

De tweede-staps payload was een cross-platform RAT die targette op: LLM API keys (OpenAI, Anthropic, Google), cloud credentials (AWS, Azure, GCP), CI/CD secrets en GitHub tokens, SSH keys, browser history, en 166 cryptocurrency wallet extensies. Op Windows-systemen installeerde de implant persistentie via een service genaamd scdev onder svchost.exe in SYSTEM context.

Orca Security documenteerde de volledige kill chain. Socket flagde easy-day-js binnen zes minuten. Voor organisaties met behavioral supply-chain monitors was de exposure window smal. Voor de meerderheid die op CVE-scanners vertrouwt, was de aanval onzichtbaar tot Microsoft die avond zijn bevindingen publiceerde.

Waarom dit een NIS2-probleem is

De Cyberbeveiligingswet (NIS2) verplicht essentiële en belangrijke entiteiten tot supply chain security-maatregelen. Artikel 21 lid 2(d) specificeert expliciet "de beveiliging van de toeleveringsketen, met inbegrip van de veiligheid van de relatie tussen de entiteit en haar leveranciers."

Een npm-package is een leverancier. @mastra had 1.1 miljoen wekelijkse downloads. Elke organisatie die Mastra in een AI-pipeline gebruikt, en dat zijn er steeds meer in de NL publieke sector, heeft nu een NIS2-incident dat gerapporteerd moet worden.

En dan BIO2: het Baseline Informatiebeveiliging Overheid vereist dat software van externe bronnen gecontroleerd wordt op integriteit. Een postinstall hook die automatisch draait bij npm install is het tegenovergestelde van controleerbaar.

Wat je nu moet doen

Als je @mastra packages hebt geïnstalleerd na 16 juni: de machine is gecompromitteerd. Package verwijderen is niet genoeg, de dropper draaide bij installatie en de RAT kan nog actief zijn met persistentie.

1. npm ls easy-day-js en grep -r "easy-day-js" package-lock.json in al je repos
2. Roteer álle credentials die de machine kon bereiken: npm tokens, GitHub PATs, cloud keys, LLM API keys, CI/CD secrets, SSH keys
3. Check op Windows: HKCU\Software\Microsoft\Windows\CurrentVersion\Run voor scdev. Op macOS: ~/Library/LaunchAgents/com.nvm.protocal.plist. Op Linux: ~/.config/systemd/user/nvmconf.service
4. Blokkeer outbound naar 23.254.164.92 en 23.254.164.123 (Hostwinds ASN AS54290)

Voor de toekomst: ignore-scripts=true in .npmrc, pin exacte versies (geen caret-ranges), commit lockfiles, en gebruik npm ci in CI.

Het echte probleem

npm v12, verwacht in juli, gaat postinstall scripts standaard blokkeren. Dat is een betekenisvolle stap. Maar het lost het onderliggende governance-probleem niet op: permanente scope-rechten voor inactive contributors.

Zolang één vergeten account 144 packages kan herpubliceren, is het niet de vraag of dit weer gebeurt, maar wanneer.

Voor Nederlandse organisaties die AI-tooling inzetten: dit is het moment om je software supply chain onder NIS2 te brengen. Niet volgende maand. Nu.