Zod 4.6.6 ist sauber: Der Schadcode kam nur bis ins Repository

Markus Seyfferth

Autor Dr. Web

12. Oktober 2026

3 Min. Lesezeit

Zod 4.6.6 enthält keinen Schadcode, obwohl die Versionshinweise der Validierungsbibliothek sechs Commits eines Angreifers aufführen. Den Nachlader aus diesen Commits lieferte npm nie aus. Die Bibliothek zählt rund 342 Millionen Downloads pro Woche.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

Am 21. September landeten die Commits direkt auf dem Hauptzweig, alle unter dem Konto von Maintainer Colin McDonnell. Derselbe Nachlader tauchte binnen einer Stunde auch bei Standard Schema und bei McDonnells TypeScript-Laufzeit nub auf.^[1] Der Angreifer hatte seine verseuchte Fassung selbst als 4.6.6 nummeriert. Noch vor Mitternacht machte McDonnell die Änderungen per Revert rückgängig, ohne sie aus der Git-Historie zu löschen. Deshalb stehen die Commits in den Release-Notes der echten Version 4.6.6 vom 11. Oktober.^[3]

Das Wichtigste in Kürze

Das npm-Paket zod 4.6.6 enthält weder die Schadcode-Datei noch einen Installations-Hook.
Der Nachlader liest die Adresse seines Servers aus einem Smart Contract auf der Ethereum-Blockchain.
Trusted Publishing und eine Freigabe-Umgebung stoppten jeden Versuch, eine verseuchte Version zu veröffentlichen.
Nur nub 0.9.4 erreichte die Registry, dort blockierte der Malware-Scan von npm die Version vor der Freigabe.

Wie sollte der Nachlader funktionieren?

Ein weißer Karton mit Aufschrift „NUR MIT FREIGABE“ und Brecheisen auf weißem Grund — Datei meta.test.mjs lädt JavaScript von einer Blockchain-Adresse nach, die der Angreifer jederzeit austauschen kann, ohne das Paket zu aktualisieren

Adresse aus der Blockchain. Die Datei meta.test.mjs fragt über drei öffentliche Ethereum-Schnittstellen einen festen Smart Contract ab, liest daraus eine Domain und lädt von dort JavaScript nach.^[2] Den nachgeladenen Code kann der Angreifer jederzeit tauschen, ohne eine neue Paketversion zu veröffentlichen. Eine Domain kann ein Hoster sperren, den Eintrag in der Blockchain nicht. Googles Threat Intelligence Group beschrieb im Oktober 2025, wie eine staatliche Gruppe aus Nordkorea das als EtherHiding bekannte Verfahren einsetzt.^[4]

Falsch verdrahtet. Der Angreifer trug den Aufruf „preinstall“ in die oberste Ebene der package.json ein. Die Paketverwaltung führt Lebenszyklus-Skripte aber nur aus, wenn sie im Feld „scripts“ stehen.^[5] Selbst eine veröffentlichte Zod-Version hätte den Nachlader bei der Installation also nicht gestartet.

Warum kam der Schadcode nicht auf npm?

Gebundene Pipeline. Zod veröffentlicht über Trusted Publishing, und der zugehörige Eintrag bei npm gilt nur für die GitHub-Umgebung „npm“, deren Läufe ein Maintainer freigeben muss.^[2] Binnen gut drei Stunden probierte der Angreifer mehrere Umwege aus, vom Release bei jedem Push bis zu einem neuen Workflow mit einem npm-Token.^[3] „Zods Release-CI hat wie vorgesehen funktioniert“, schreibt McDonnell. Nach seiner Einschätzung war eine Berechtigung für Git-Pushes kompromittiert, kein npm- oder GitHub-Token.^[1]

Anders als bei keyv. Im August schoben Angreifer über das GitHub-Konto des Maintainers hinter keyv ebenfalls Dateien direkt auf den Hauptzweig. Die echte Release-Pipeline des Projekts veröffentlichte danach die vergifteten Versionen mit gültiger Provenance. Bei Zod stand zwischen Push und Paket die Freigabe durch einen Menschen.

Zod hat kein Malware-Scanner geschützt, sondern ein Freigabeknopf, den der Angreifer nicht drücken konnte.
Michael Dobler, Herausgeber Dr. Web

Angriff auf Zod: drei Umwege, kein Release

Was der Angreifer am 21. September 2026 versuchte und woran jeder Versuch scheiterte

342 Mio.

Downloads von zod pro Woche, gezählt vom 4. bis 10. Oktober 2026

6 Commits

schob der Angreifer direkt auf den Hauptzweig, alle nahm der Maintainer noch am selben Tag zurück

3 Repos

enthielten denselben Nachlader: zod, nub und Standard Schema

0 Versionen

von zod mit Schadcode erreichten npm, auch 4.6.6 vom 11. Oktober ist sauber

Die Umwege des Angreifers

Versuch

Ergebnis

Push-Auslöser

Release-Workflow startet bei jeder Versionsänderung auf dem Hauptzweig

Kein Release: Die Umgebung „npm“ verlangt die Freigabe eines Maintainers

Freigabe gestrichen

Umgebung „npm“ aus dem Workflow entfernt, Versionen 4.6.7 und 4.6.8 angelegt

Kein Release, Trusted Publishing gilt nur für diese Umgebung

Token-Workflow

Neuer Workflow veröffentlicht mit einem npm-Token aus den Secrets

Lauf scheitert ebenfalls

Was sollten Entwicklungsteams jetzt prüfen?

Zod-Nutzer müssen nichts zurückrollen, die Versionen 4.6.7 und 4.6.8 aus den Angreifer-Commits existieren auf npm nicht. Für die eigene Lieferkette lohnen sich vier Schritte:

Den Hauptzweig per Regelwerk gegen direkte Pushes sperren. Zods Angreifer kam mit einer einzigen Push-Berechtigung bis in den Release-Workflow.
Eigene Pakete über Trusted Publishing mit einer GitHub-Umgebung veröffentlichen, die eine Freigabe verlangt. Seit Mai erzwingt das Staged Publishing von npm auf Wunsch zusätzlich eine Bestätigung per 2FA.^[6]
Installations-Skripte in CI-Läufen mit der npm-Option ignore-scripts abschalten und nur für Pakete erlauben, die native Module kompilieren.^[7]
Versionen und Herkunft aller Abhängigkeiten dokumentieren. Ab dem 11. Dezember 2027 verlangt der Cyber Resilience Act von Herstellern die gebotene Sorgfalt beim Einbau quelloffener Komponenten.^[8]

Offene Frage. Wie die Push-Berechtigung abhandenkam, hat McDonnell in seinen bisherigen Stellungnahmen nicht erklärt. Seit dem 24. September veröffentlicht der Maintainer alle seine Pakete nur noch per manuell gestartetem Workflow mit Pflicht-2FA.^[1] Begriffe wie Supply-Chain-Angriff erklärt unser Cybersecurity-Glossar.