Mini Shai-Hulud: Bun-runtime stjeler hemmeligheter fra fire SAP-pakker, deriblant @cap-js og mbt

«The attacker was able to publish compromised packages because the workflow had publish permissions without any manual approval gate.» — Patrice Bender, SAP-utvikler, i PR #1592 til cap-js/cds-dbs

1. april 2026 publiserte angripere ondsinnede versjoner av fire npm-pakker i SAP-økosystemet: mbt@1.2.48, @cap-js/db-service@2.10.1, @cap-js/sqlite@2.2.2 og @cap-js/postgres@2.2.2. Snyk dokumenterte angrepet samme dag. Hver pakke får en preinstall-hook som laster ned Bun-runtimen fra GitHub Releases og kjører et 11,6 MB obfuskert credential-stealer-skript. Tjuveriene tagger seg selv «A Mini Shai-Hulud has Appeared» og lager dead-drop-repoer fra utviklernes egne GitHub-kontoer; ved publisering av Snyks rapport hadde Github-søk returnert 1076 slike repos.

Bug-kjeden er kompakt og bekymringsfullt effektiv. Stealeren leter etter npm-tokens med regex /npm_[A-Za-z0-9]{36,}/g, validerer dem mot npm registry, sanker GitHub-tokens, AWS/Azure/GCP-credentials, kubeconfigs, SSH-nøkler, password-manager-tokens og krypto-lommebøker. Det som er nytt: skriptet injiserer også .claude/settings.json og .vscode/tasks.json i alle GitHub-repos token har skrivetilgang til, slik at Claude Code-sesjoner og VS Code-prosjekter automatisk re-eksekverer payload ved oppstart. Dette er første gang AI-coding-agent-konfigurasjon dokumenteres som persistens-vektor i en bredt distribuert npm-supply-chain-angrep.

For å gjøre vondt verre: mbt@1.2.48 var fortsatt latest dist-tag på npm da Snyk publiserte rapporten. Et bart npm install mbt resolved fortsatt til den ondsinnede tarballen. @cap-js/sqlite@2.2.2 declare også @cap-js/db-service@^2.10.0 som dependency, så et rent install kunne pulle den infiserte db-service-versjonen som transitive dependency uten at noen listet den direkte.

SAP rotårsaks-statementet over er hovedlæren: workflow-en hadde npm publish-rettigheter uten manual approval gate. Når en utvikler-konto eller en CI-bot mister sin token, kan den brukes til å pushe et release-skript som publiserer på vegne av selve maintainer-organisasjonen. SAP har siden lagt til environment-review for publisering i cap-js/cds-dbs (PR #1592).

På Linux CI-runners går stealeren et hakk lenger og spawner en Python-barneprosess som leser /proc/{pid}/mem av GitHub Actions Runner.Worker-prosessen for å dumpe plaintext-secrets direkte fra runner-minnet. Default GitHub-hosted runners har ingen forsvar mot dette uten en runner-side security agent.

Hva bør du gjøre?

1. Søk i lockfiles og container-images etter de fire versjonene over. grep -rE "mbt@1\.2\.48|cap-js/(db-service|sqlite|postgres)@2\.(10\.1|2\.2)" er et raskt utgangspunkt.
2. Hvis du finner treff: roter alle tokens som var tilgjengelig på maskinen eller pipelinen i exposure-vinduet (10:00–14:00 UTC 29. april). Det inkluderer npm publish-tokens, GitHub PATs, skytokens, SSH-nøkler og MCP-server-konfig som ~/.claude.json.
3. Sjekk GitHub-organisasjonen din for repoer med beskrivelsen «A Mini Shai-Hulud has Appeared», commits fra claude@users.noreply.github.com, eller branchen dependabout/github_actions/format/setup-formatter (typosquat på dependabot).
4. Innfør approval-gate på alle npm publish-workflows. SAPs egen rotårsaks-statement peker direkte på dette. GitHub environments med required reviewers er den enkleste implementasjonen.