Malware-Alarm bei Zod 4.6.6: Der schädliche Commit erreichte npm nie

Zod 4.6.6, das neueste Release der beliebten TypeScript-Validierungsbibliothek, ist am 11. Oktober 2026 erschienen. Seine Release-Seite listet Commits aus einem Malware-Angriff auf, und Entwickler schlugen auf GitHub und Hacker News Alarm. Diese Commits wurden am 21. September gepusht und noch am selben Tag rückgängig gemacht. Laut GitHubs Sicherheitshinweis erreichten die schädlichen Zod-Änderungen nie npm, die Registry, in der JavaScript-Pakete veröffentlicht werden.

Zod prüft, ob Daten, etwa ein Formular oder eine API-Antwort, die Form haben, die ein Programm erwartet. Viele TypeScript-Projekte hängen davon ab.

Warum Zod 4.6.6 infiziert wirkte

Die Release-Seite von 4.6.6 listet jeden Commit seit dem vorherigen Release 4.6.5 auf. Diese Liste enthält zwei Commits mit dem Titel „Fix bugs and improve performance“ sowie Versionssprünge namens „4.6.7“ und „4.6.8“. Sie enthält außerdem zwei Änderungen an der Veröffentlichungs-Konfiguration: „ci: publish to npm with NPM_TOKEN“ und „ci: drop the npm environment approval gate from publish“.

Ein GitHub-Issue mit dem Titel „Suspicious preinstall script in v4.6.6 commit history“ wies auf den ersten dieser Commits hin. Ein Hacker-News-Thread fragte: „Zod 4.6.6 compromised by malware?“ Der Autor des Issues fügte eine Einschränkung hinzu:

Die Änderung scheint vor dem endgültigen Release rückgängig gemacht worden zu sein, und die verdächtigen Dateien scheinen in der auf npm veröffentlichten Version von 4.6.6 nicht vorhanden zu sein.

Dieselbe Liste enthält auch „Cleanup bad commits (#6620)“, die Änderung, die sie entfernt hat.

Was der Angriff vom 21. September bewirkte

GitHubs Sicherheitshinweis nennt den zeitlichen Ablauf. Derselbe Loader erreichte innerhalb einer Stunde drei Projekte.

Zeit (UTC)	Repository	Was geschah
11:56	colinhacks/zod	Commit d821685, „Fix bugs and improve performance“
12:37	standard-schema/standard-schema	Commit mit demselben Titel und Loader
12:54	nubjs/nub	Commit mit demselben Titel und Loader
13:00	nubjs/nub	Nachtrag, „chore: update npm/nub package“
13:09	npm	Scan von @nubjs/nub@0.9.4 protokolliert; die Version wurde blockiert

Der Zod-Commit fügte zwei vierzeilige Dateien namens meta.test.mjs hinzu, eine im Hauptpaket und eine in Zod Mini. Trotz des Namens sind es keine Tests. Der Commit fügte außerdem einen preinstall-Eintrag hinzu, der sie ausführt. Das ist ein Install-Hook: Code, der läuft, wenn ein Paket installiert wird. Der Commit erhöhte die Version auf 4.6.6 und änderte den Release-Workflow so, dass ein Push auf den Hauptbranch eine Veröffentlichung starten würde.

Der Loader fragt einen Smart Contract, ein kleines Programm auf der Ethereum-Blockchain, nach einer Webadresse. Dann lädt er JavaScript von dieser Adresse herunter, führt es mit den Rechten des installierenden Nutzers aus und löscht seine temporären Dateien. Weil die Adresse von der Blockchain kommt, verrät der Code im Repository nie, wo der Schadcode liegt. Die diesen Monat gemeldete MALFEX-Malware auf npm nutzt einen ähnlichen Trick mit Solana.

Warum nichts npm erreichte

Der Maintainer, auf GitHub colinhacks, schrieb im Thread zum Sicherheitshinweis: „Offenbar wurden irgendwelche Git-Push-Zugangsdaten kompromittiert, kein npm- oder GitHub-Token.“ Außerdem schrieb der Maintainer: „Der Angriff bestand aus schädlichen Commits und getaggten Pushes auf main.“

Andere Commits an diesem Tag versuchten, ein Release zu erzwingen. Sie entfernten den Freigabeschritt, fügten einen Veröffentlichungsweg über ein NPM_TOKEN-Secret hinzu und erhöhten die Version zweimal. Laut dem Maintainer war Zods Release-Ablauf für diese Art von Angriff nicht mehr anfällig, seit npm im vergangenen Dezember das tokenbasierte Veröffentlichen abgeschafft hat. Der Sicherheitshinweis stellt fest, dass die Änderungen an Zod und standard-schema „die Veröffentlichung auf npm nicht erreichten“.

Bei Nub lag der Fall anders. Sein Release ließ sich durch das Erstellen eines Tags starten, deshalb erreichte @nubjs/nub@0.9.4 die Veröffentlichungs-Pipeline von npm. Die Registry hielt die Version für Prüfungen zurück, fand den schädlichen Code und blockierte sie, bevor jemand sie installieren konnte.

Pull Request #6620, „Cleanup bad commits“, machte sechs Commits rückgängig und wurde am 21. September gemergt. Er löschte den neuen Veröffentlichungs-Workflow des Angreifers und die Loader-Dateien, entfernte die preinstall-Einträge und setzte die Version auf 4.6.5 zurück.

Wie Zod 4.6.6 veröffentlicht wurde

Laut seinem Eintrag in der npm-Registry wurde 4.6.6 von GitHub Actions über Trusted Publishing veröffentlicht und von colinhacks freigegeben. Mit Trusted Publishing nimmt npm ein Release nur von einem namentlich festgelegten GitHub-Workflow an, daher gibt es kein langlebiges Token, das gestohlen werden könnte. Anfang dieses Monats erlaubte npm Trusted Publishing, Dist-Tags wie latest zu verschieben. Das Paket trägt eine Provenance-Attestierung, einen signierten Nachweis darüber, wo es gebaut wurde. Sein Manifest listet kein preinstall-, install- oder postinstall-Skript.

Das Release verschärft auch den Ablauf. Zwei seiner Änderungen, #6622 und #6638, stellen neue npm-Versionen im Staging bereit, statt sie zu veröffentlichen, und halten jeden Lauf an, bis diese Versionen freigegeben sind. Am 24. September schrieb der Maintainer, dass alle seine npm-Pakete jetzt Staged Publishing nutzen, das sich nur von Hand starten lässt.

Wie die Push-Zugangsdaten entwendet wurden, wird laut dem Maintainer noch gemeinsam mit GitHub untersucht.

Was das für Entwickler bedeutet

• Kein Hinweis auf Malware im Zod 4.6.6 von npm. Sein Manifest hat keinen Install-Hook, und es trägt eine Provenance-Attestierung. npm view zod@4.6.6 scripts zeigt die Skripte an, ohne etwas zu installieren.
• Durchsuchen Sie Logs nach der Auslieferungsdomain. Der Sicherheitshinweis nennt dsakldjklsaj33112[.]com als Indikator. Prüfen Sie Rechner, die am 21. September Zod, standard-schema oder nub aus dem Git-Quellcode gebaut haben. Entfernen Sie bei der Suche die eckigen Klammern.
• Schalten Sie Install-Skripte ab, wo es geht. Dieser Angriff hing von einem preinstall-Hook ab. Die npm-Einstellung ignore-scripts verhindert, dass solche Hooks laufen. Testen Sie, ob sich das Projekt noch bauen lässt, denn manche Pakete brauchen ihre Skripte.
• Maintainer können Zods Aufbau übernehmen. Der Angreifer konnte auf main pushen und den Workflow bearbeiten, konnte Zod aber trotzdem nicht veröffentlichen. Trusted Publishing plus ein manueller Freigabeschritt hielten stand. Ein Release, das mit einem Tag startet, wie bei nub, ist das schwächere Design.