Im Juli 2025 habe ich ein neues Projekt prototypisiert und beschloss, MikroORM auszuprobieren. Die Dokumentation wies an, auszuführen npx mikro-orm-esm für Migrationen. Also tat ich es.
npm ERR! code E404
npm ERR! 404 Not Found - GET https://registry.npmjs.org/mikro-orm-esmDas Paket existiert nicht, das ist seltsam! Dann wurde mir klar: Was wäre, wenn jemand dies registriert hätte? Ich hätte Folgendes gesehen:
Folgende Pakete müssen installiert werden:
mikro-orm-esm@1.0.0
Fortfahren? (y)Ich hätte einfach gedrückt y. Das tut jeder. Und nichts in dieser Aufforderung sagt Ihnen, ob Sie Malware oder ein legitimes Tool installieren werden.
Die Dokumentation verwies auf ein nicht existierendes Paket. Wie viele andere Phantom-Paketreferenzen sind noch im Umlauf? Wie viele wurden bereits von Angreifern beansprucht? Ich musste es wissen.
Also begann ich zu graben. Ich schrieb Skripte, um npm nach Paketen zu durchsuchen, die in READMEs und Skripten referenziert, aber nie tatsächlich veröffentlicht wurden. Tausende von npx Aufrufen. Dutzende gefunden. 14 davon beansprucht, bevor es jemand anderes konnte. Dann geschah S1ngularity, und die Forschung wurde auf Eis gelegt.
Sechs Monate später wurde ich dank der Community, die ähnliche Dinge erforschte, an meine Forschung erinnert. Ich überprüfte schließlich die Download-Zahlen: 121.539 Downloads!
Die Leute hatten diese nicht existierenden Befehle wochenlang tausende Male pro Woche aufgerufen. Monatelang. Während die Pakete einfach nur Daten sammelten.
Sechs Monate Daten
Die Downloads blieben nicht konstant. Sie wuchsen. Begannen langsam Ende Juli. Der jüngste Höhepunkt erreichte 4.236 Downloads an einem einzigen Tag (16. Januar 2026).
- Gesamt: 121.539 Downloads über 128 Pakete
- Wöchentlicher Durchschnitt: 3.903
- Spitzentag: 4.236 Downloads (16. Jan 2026)
Kurzer Hinweis zum Rauschen: Jedes Mal, wenn eine neue Version eines Pakets veröffentlicht wird, erhält es automatisch 60-100 Downloads von Sicherheitsscannern und Mirrors. Das ist das Basisrauschen pro Release. Pakete mit mehreren Versionen akkumulieren schnell Rauschen. Alles, was konstant über diesem Schwellenwert liegt, ist tatsächliche Nutzung.
Fällt der Rückgang Ende Dezember auf? Feiertage. Selbst Phantom-Paket-Downloads machen über Weihnachten Pause.
Die großen Drei
Drei Pakete machen 79 % aller Downloads aus:
openapi-generator-cli: 48.356 Downloads (tatsächliches Paket: @openapitools/openapi-generator-cli)cucumber-js: 32.110 Downloads (tatsächliches Paket:@cucumber/cucumber)depcruise: 15.637 Downloads (tatsächliches Paket:dependency-cruiser)
openapi-generator-cli verzeichnete in nur den letzten 7 Tagen 3.994 Downloads. Das bedeutet, dass fast 4.000 Mal versucht wurde, einen nicht existierenden Befehl auszuführen. In einer Woche.
Der Long Tail
Die verbleibenden Pakete mit nennenswerten Downloads:
jsdoc2md: 4.641 Downloadsgrpc_tools_node_protoc: 4.518 Downloadsvue-demi-switch: 1.166 Downloadsstyleguidist: 805 Downloadsmikro-orm-esm: 314 Downloadspvbase64: 142 Downloadscromwell: 106 Downloads
Erinnern Sie sich an die Download-Baseline von 60-100 pro Version? Ein Paket mit 3 Versionen könnte 180-300 Downloads reinen Rauschens aufweisen. fathym mit insgesamt 83 Downloads ist wahrscheinlich reines Rauschen. Aber mikro-orm-esm mit 314? Selbst unter Berücksichtigung mehrerer Versionen sind das echte Versuche.
styleguidist mit 805 Downloads bedeutet Hunderte von echten Ausführungen. Es könnten CI/CD-Systeme sein, die wiederholt darauf zugreifen. Es könnten Dutzende verschiedene Entwickelnde sein. So oder so ist es eine tatsächliche Nutzung eines Pakets, das nicht existieren sollte.
Wie wir diese gefunden haben
Wir betreiben einen vollständigen npm-Registry-Mirror bei Aikido. Wir haben jedes package.json und README in der gesamten Registry geparst. Extrahierte npx Befehle. Abgeglichen mit dem, was tatsächlich registriert ist. Wir haben auch die Code-Suche von GitHub durchsucht, um zu sehen, wie weit verbreitet diese Phantom-Befehle in der Praxis, in der Dokumentation, in CI-Konfigurationen, Skripten – überall dort, wo Entwickelnde sie referenzieren könnten – auftauchen.
Drei Datenpunkte für jedes Paket:
- Registry-Referenzen: Wie viele npm-Pakete diesen Befehl in ihrer package.json oder README erwähnen
- GitHub-Ergebnisse: Wie viele Code-Dateien oder Repos diesen Befehl auf GitHub referenzieren
- Downloads: Wie oft versucht wurde, ihn tatsächlich auszuführen
Wir haben im Juli 2025 14 Pakete identifiziert. Als ich die Forschung im Januar wieder aufnahm, haben wir unsere Analyse erweitert und viele weitere gefunden. Zu diesem Zeitpunkt haben wir insgesamt 128 Pakete identifiziert.
Einige bemerkenswerte Muster:
Hauptangriffsvektoren (10K+ Downloads): openapi-generator-cli, cucumber-js, und depcruise alle zeigen eine starke Korrelation zwischen npm-Referenzen, GitHub-Erwähnungen und tatsächlichen Downloads. Diese wären in den Händen von Angreifern verheerend.
Hohe Sichtbarkeit, geringe Konversion: styleguidist hat 246 npm-Referenzen und 286 GitHub-Ergebnisse, aber nur 805 Downloads. git-scripts-pre-push hat 126 Referenzen, aber nur 93 Downloads. Sichtbarkeit bedeutet nicht immer Ausführung.
Nur-Dokumentations-Vektoren: mikro-orm-esm hat null npm-Paketreferenzen, aber 80 GitHub-Ergebnisse und 314 Downloads. Ein Beweis dafür, dass Dokumentation allein Hunderte von Installationen vorantreiben kann, selbst ohne jegliche npm-Ökosystem-Referenzen.
Warum das gefährlich ist
Der Angriff ist einfach.
Ein Angreifer registriert das Paket. Fügt ein postinstall Skript hinzu, das Umgebungsvariablen exfiltriert: npm-Tokens, Cloud-Anmeldeinformationen, API-Schlüssel, alles, was herumliegt. Dann wartet er.
In Spitzenzeiten sind das potenziell ~4.000 kompromittierte Maschinen pro Woche. Entwickelnde-Workstations. CI-Server. Build-Umgebungen. Viele laufen möglicherweise mit Anmeldeinformationen in Umgebungsvariablen. Es ist kein Phishing erforderlich. Keine Supply-Chain-Kompromittierung bestehender Pakete. Man muss nur den Namen beanspruchen und warten, bis npx die Opfer zu einem bringt.
Wenn jemand den Befehl ausführt, sieht er:
Folgende Pakete müssen installiert werden:
openapi-generator-cli@1.0.0
Fortfahren? (y)Die Eingabeaufforderung zeigt nicht, wer es veröffentlicht hat. Zeigt nicht, wann. Zeigt nicht, ob es das ist, wonach Sie suchen. Diese Aufforderung sehen Sie möglicherweise regelmäßig bei legitimen Tools. Das Muskelgedächtnis übernimmt, weil wir Menschen sind. Sie tippen y, wie es alle anderen tun. Das war's. Das ist der gesamte Angriff.
Wir haben 128 Lücken in mehreren Runden geschlossen. Wir haben die schlimmsten Fälle erwischt. Aber es gibt einen langen Schwanz von Tausenden.
Ein Hinweis zu npm-Schutzmaßnahmen
npm verfügt über einen Typosquatting-Schutz. Als wir versuchten, bestimmte Namen zu beanspruchen, lehnte npm diese mit Ähnlichkeitsfehlern ab. Namen wie rsbuild, vuedoc, napi, t-ci waren alle zu nah an bestehenden Paketen. Das ist gut. Es bedeutet, dass npm offensichtliche Squatting-Versuche aktiv blockiert.
Aber diese Phantom-Befehle sind keine Tippfehler. Es sind Namen, die überhaupt nie registriert wurden. npms Ähnlichkeitsprüfung fängt diese nicht ab, weil es nichts gibt, womit sie „ähnlich“ sein könnten.
Was Sie tun sollten
Verwenden Sie npx --no-install
npx --no-install your-commandDies zwingt npx, nur lokale Binärdateien zu verwenden. Kein Registry-Fallback. Wenn es nicht installiert ist, schlägt es fehl. Das ist, was Sie wollen.
Installieren Sie CLI-Tools explizit. Verlassen Sie sich nicht auf npx um sie abzurufen:
{
"devDependencies": {
"@openapitools/openapi-generator-cli": "^2.7.0"
}
}
Überprüfen Sie vor der Ausführung. Die Dokumentation besagt, dass man ausführen soll npx etwas? Überprüfen Sie zuerst, ob das Paket tatsächlich existiert. Überprüfen Sie, ob es das richtige ist. Besonders in CI/CD.
Beanspruchen Sie Ihren Namespace. Wenn Sie ein CLI-Tool pflegen, registrieren Sie die offensichtlichen Aliase und Tippfehler. Eine günstige Absicherung dagegen, dass jemand anderes dies böswillig tut.
Wie Sie feststellen, ob Sie betroffen sind
Wenn Sie ein Aikido-Benutzer sind, überprüfen Sie Ihren zentralen Feed und filtern Sie nach Malware-Problemen. Alle Phantom-Paket-Schwachstellen werden als 100/100 kritisches Problem im Feed auftauchen. Aikido scannt Ihre Repositorys nächtlich neu, obwohl wir auch das Auslösen eines vollständigen Rescans empfehlen.
Wenn Sie noch kein Aikido-Benutzer sind, richten Sie ein kostenloses Konto ein und verbinden Sie Ihre Repositorys. Unsere proprietäre Malware-Abdeckung ist im kostenlosen Plan enthalten (Ohne Kreditkarte).
Für zukünftigen Schutz sollten Sie die Verwendung von Aikido SafeChain (Open Source) in Betracht ziehen, einem sicheren Wrapper für npm, npx, yarn und pnpm. SafeChain integriert sich in Ihre aktuellen Workflows, fängt Paketinstallationsbefehle ab und verifiziert Pakete gegen Aikido Intel (unsere Open-Source-Bedrohungsaufklärung), bevor sie auf Ihrem Rechner landen. Stoppen Sie Bedrohungen am Tor.
Die Zahlen
121.539 Downloads in sieben Monaten. Durchschnittlich 3.903 pro Woche. Spitzenwert von 4.236 an einem einzigen Tag. Insgesamt 128 Pakete beansprucht (14 im Juli, der Rest im Januar).
Das npm-Ökosystem umfasst Millionen von Paketen. Entwickelnde führen npx-Befehle täglich Tausende Male aus. Die Lücke zwischen „bequemem Standard“ und „beliebiger Codeausführung“ ist ein nicht beanspruchter Paketname.
