Nach Darstellung von Socket folgt die Implementierung HTTP-Weiterleitungen, ohne das Ziel zu prüfen, und nutzt unter Windows PowerShell mit dem Schalter „-ExecutionPolicy Bypass". Das erhöhe das Risiko für betroffene Entwickler- und CI/CD-Umgebungen.
Die vergifteten Pakete bringen einen neuen Preinstall-Hook in der package.json mit, der eine Datei namens „setup.mjs" startet. Diese dient als Lader für die Bun-Laufzeitumgebung, über die der eigentliche Credential-Stealer und das Verbreitungs-Framework („execution.js") ausgeführt werden.
Laut Aikido ist die Schadsoftware darauf ausgelegt, lokale Entwickler-Zugangsdaten, GitHub- und npm-Token, GitHub-Actions-Secrets sowie Cloud-Secrets von AWS, Azure, GCP und Kubernetes abzugreifen. Die gestohlenen Daten werden verschlüsselt und in öffentliche GitHub-Repositories ausgeleitet, die unter dem Konto des Opfers selbst angelegt werden – versehen mit der Beschreibung „A Mini Shai-Hulud has Appeared". Zum Zeitpunkt der Berichterstattung existieren bereits mehr als 1.100 Repositories mit dieser Beschreibung.
Die 11,6 MB große Schadlast kann sich zudem selbst über Entwickler- und Release-Workflows verbreiten. Dazu nutzt sie die erbeuteten GitHub- und npm-Token, um einen schädlichen GitHub-Actions-Workflow in die Repositories des Opfers einzuschleusen, Repository-Secrets zu stehlen und vergiftete Versionen der npm-Pakete in der Registry zu veröffentlichen.
Vom Vorgehen früherer Shai-Hulud-Wellen unterscheidet sich der aktuelle Vorfall in einem zentralen Punkt: Laut StepSecurity handelt es sich um einen der ersten Supply-Chain-Angriffe, der die Konfigurationen von KI-Coding-Agenten als Vektor für Persistenz und Verbreitung nutzt.
Zur Ursache hat die Analyse ergeben, dass die Angreifer für die drei „@cap-js"-Pakete das Konto von RoshniNaveenaS kompromittierten, anschließend einen veränderten Workflow in einen Nebenzweig pushten und mit dem so abgegriffenen npm-OIDC-Token die schädlichen Pakete ohne Provenance-Nachweis veröffentlichten. Beim Paket „mbt" wird die Kompromittierung des statischen npm-Tokens „cloudmtabot" über einen bislang unbekannten Weg vermutet.
SafeDep zufolge war das cds-dbs-Team im November 2025 auf das vertrauensbasierte Veröffentlichen per npm-OIDC umgestiegen. Dabei kann GitHub Actions ein kurzlebiges npm-Token anfordern, ohne dauerhafte Geheimnisse im Repository abzulegen. Der Angreifer habe diesen Austausch in einem CI-Schritt manuell nachgebildet und das resultierende Token ausgegeben.
Entscheidend sei eine Konfigurationslücke gewesen: Die OIDC-Konfiguration für vertrauenswürdige Veröffentlichungen von @cap-js/sqlite habe jedem Workflow im Repository cap-js/cds-dbs vertraut, nicht nur dem vorgesehenen „release-please.yml" im Hauptzweig. Ein Push in einen Branch konnte so ein OIDC-Token im Namen des Pakets anfordern, sofern der Workflow die Berechtigung „id-token: write" und den Verweis „environment: npm" besaß.
Die Maintainer der betroffenen Pakete haben nach eigenen Angaben neue, sichere Versionen veröffentlicht, die die kompromittierten Releases ablösen.