Im Juli 2025 arbeitete ich an einem Prototyp für ein neues Projekt und beschloss, MikroORM auszuprobieren. In der Dokumentation stand, dass man npx mikro-orm-esm für Migrationen. Also habe ich das getan.
npm ERR! Code E404
npm ERR! 404 Nicht gefunden – GET https://registry.npmjs.org/mikro-orm-esmDas Paket existiert nicht, das ist seltsam! Dann kam mir ein Gedanke: Was, wenn jemand das registriert hat? Ich hätte gesehen:
Die folgenden Pakete müssen installiert werden:
mikro-orm-esm@1.0.0
Möchten Sie fortfahren? (y)Ich hätte einfach zugeschlagen. yDas macht jeder. Und nichts in dieser Aufforderung verrät Ihnen, ob Sie Malware oder ein legitimes Tool installieren werden.
Die Dokumente verwiesen auf ein nicht vorhandenes Paket. Wie viele andere phantom gibt es noch? Wie viele davon wurden bereits von Angreifern beansprucht? Ich musste es wissen.
Also begann ich zu recherchieren. Ich schrieb Skripte, um npm nach Paketen zu durchsuchen, auf die in READMEs und Skripte, aber nie tatsächlich veröffentlicht. Tausende von Querverweisen npx Beschwörungen. Dutzende gefunden. 14 davon für mich beansprucht, bevor es jemand anderes tun konnte. Dann kam 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. Endlich habe ich mir die Downloadzahlen angesehen: 121.539 Downloads!
Die Leute hatten diese nicht existierenden Befehle tausende Male pro Woche eingegeben. Monatelang. Während die Pakete einfach nur da lagen und Daten sammelten.
Sechs Monate Daten
Die Downloadzahlen blieben nicht unverändert, sondern stiegen an. Ende Juli begann ein langsamer Anstieg. Der jüngste Höchststand lag bei 4.236 Downloads an einem einzigen Tag (16. Januar 2026).
- Insgesamt: 121.539 Downloads in 128 Paketen
- Wöchentlicher Durchschnitt: 3.903
- Spitzentag: 4.236 Downloads (16. Januar 2026)
Kurzer Hinweis zum Rauschen: Jedes Mal, wenn Sie eine neue Version eines Pakets veröffentlichen, wird es automatisch 60 bis 100 Mal von Sicherheitsscannern und Mirrors heruntergeladen. Das ist das Basisrauschen pro Veröffentlichung. Pakete mit mehreren Versionen sammeln schnell Rauschen an. Alles, was konstant über diesem Schwellenwert liegt, ist echte Nutzung.
Sehen Sie den Einbruch Ende Dezember? Feiertage. Selbst phantom machen Weihnachten frei.
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:@Gurke/Gurke)depcruise: 15.637 Downloads (tatsächliches Paket:Abhängigkeits-Cruiser)
OpenAPI-Generator-CLI wurde in den letzten 7 Tagen 3.994 Mal heruntergeladen. Das bedeutet, dass fast 4.000 Mal versucht wurde, einen Befehl auszuführen, der nicht existiert. In einer Woche.
Der Long Tail
Die übrigen Pakete mit bedeutenden Downloads:
jsdoc2md: 4.641 Downloadsgrpc_tools_node_protoc: 4.518 DownloadsHalb-Schalter: 1.166 DownloadsStyleguide: 805 DownloadsMikro-ORM-ESM: 314 Downloadspvbase64: 142 DownloadsCromwell: 106 Downloads
Erinnern Sie sich an die 60-100 Downloads pro Version? Ein Paket mit drei Versionen könnte 180-300 Downloads reinen Rauschens haben. Fathym mit insgesamt 83 Downloads ist wahrscheinlich nur Lärm. Aber Mikro-ORM-ESM Mit 314? Selbst wenn man mehrere Versionen berücksichtigt, sind das echte Versuche.
Styleguide Mit 805 Downloads sind das Hunderte von tatsächlichen Ausführungen. Es könnte sich um wiederholte CI/CD-Ausführungen handeln. Es könnten Dutzende verschiedener Entwickler sein. So oder so handelt es sich um die tatsächliche Nutzung eines Pakets, das nicht existieren sollte.
Wie wir diese gefunden haben
Wir betreiben bei Aikido einen vollständigen npm-Registry-Mirror. Parsed every package.json und README über die gesamte Registrierung hinweg. Extrahiert npx Befehle. Gegenüberstellung mit den tatsächlich registrierten Befehlen. Wir haben auch die Code-Suche von GitHub durchsucht, um zu sehen, wie häufig diese phantom in der Praxis vorkommen, in Dokumentationen, CI-Konfigurationen, Skripten und überall dort, wo Entwickler sie möglicherweise referenzieren.
Drei Datenpunkte für jedes Paket:
- Registry-Referenzen: Wie viele npm-Pakete erwähnen diesen Befehl in ihrer package.json oder README?
- GitHub-Ergebnisse: Wie viele Code-Dateien oder Repositorys verweisen auf diesen Befehl auf GitHub?
- Downloads: Wie oft wurde tatsächlich versucht, es auszuführen?
Im Juli 2025 haben wir 14 Pakete beansprucht. Als ich die Recherche im Januar wieder aufnahm, haben wir unsere Analyse erweitert und viele weitere gefunden. Bis jetzt haben wir insgesamt 128 Pakete beansprucht.
Einige bemerkenswerte Muster:
Wichtige Angriffsvektoren (über 10.000 Downloads): OpenAPI-Generator-CLI, cucumber-js, und depcruise Alle zeigen eine starke Korrelation zwischen npm-Referenzen, GitHub-Erwähnungen und tatsächlichen Downloads. In den Händen von Angreifern wären diese Daten verheerend.
Hohe Sichtbarkeit, geringe Konversion: Styleguide hat 246 npm-Referenzen und 286 GitHub-Ergebnisse, aber nur 805 Downloads. git-Skripte-vor-dem-Push hat 126 Referenzen, aber nur 93 Downloads. Sichtbarkeit ist nicht immer gleichbedeutend mit Umsetzung.
Nur-Dokumentationsvektoren: Mikro-ORM-ESM hat keine npm-Paketverweise, aber 80 GitHub-Ergebnisse und 314 Downloads. Ein Beweis dafür, dass allein die Dokumentation Hunderte von Installationen generieren kann, auch ohne Verweise im npm-Ökosystem.
Warum das gefährlich ist
Der Angriff ist einfach.
Ein Angreifer registriert das Paket. Fügt ein postinstall Skript, das Umgebungsvariablen ausspäht: npm-Token, Cloud-Anmeldedaten, API-Schlüssel, was auch immer gerade herumliegt. Dann wartet es.
In Spitzenzeiten sind das potenziell etwa 4.000 kompromittierte Rechner pro Woche. Entwickelnde . CI-Server. Build-Umgebungen. Viele davon laufen möglicherweise mit Anmeldedaten in Umgebungsvariablen. Phishing ist nicht erforderlich. Keine Kompromittierung der Lieferkette 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 Folgendes:
Die folgenden Pakete müssen installiert werden:
openapi-generator-cli@1.0.0
Möchten Sie fortfahren? (y)Die Eingabeaufforderung zeigt nicht, wer sie veröffentlicht hat. Sie zeigt nicht, wann. Sie zeigt nicht, ob es das ist, wonach Sie suchen. Diese Eingabeaufforderung wird möglicherweise regelmäßig für legitime Tools angezeigt. Da wir Menschen sind, übernimmt das Muskelgedächtnis die Kontrolle. Sie tippen y, wie alle anderen auch. Das ist alles. Das ist der gesamte Angriff.
Wir haben in mehreren Runden 128 Lücken geschlossen. Die schlimmsten Fälle haben wir aufgedeckt. Aber es gibt noch Tausende weitere.
Ein Hinweis zu den Schutzmaßnahmen von npm
npm verfügt über einen Schutz vor Typosquatting. Als wir versuchten, bestimmte Namen zu beanspruchen, lehnte npm diese aufgrund von Ähnlichkeitsfehlern ab. Namen wie rsbuild, vuedoc, Sträfling, t-ci waren alle zu ähnlich zu bestehenden Paketen. Das ist gut. Es bedeutet, dass npm offensichtliche Versuche der Besetzung aktiv blockiert.
Aber diese phantom sind keine Tippfehler. Es handelt sich um Namen, die von vornherein nie registriert wurden. Die Ähnlichkeitsprüfung von npm erkennt diese nicht, da es nichts gibt, womit sie „ähnlich” sein könnten.
Was Sie tun sollten
Verwenden Sie npx --no-install
npx --no-install Ihr-BefehlDadurch wird npx gezwungen, nur lokale Binärdateien zu verwenden. Kein Fallback auf die Registrierung. Wenn es nicht installiert ist, schlägt es fehl. Das ist genau das, was Sie wollen.
Installieren Sie die CLI-Tools explizit. Verlassen Sie sich nicht auf npx um sie zu holen:
{
"devDependencies": {
"@openapitools/openapi-generator-cli": "^2.7.0"
}
}
Vor dem Ausführen überprüfen. Die Dokumentation sagt, dass man npx Etwas? Überprüfen Sie zunächst, ob das Paket tatsächlich vorhanden ist. Überprüfen Sie, ob es das richtige ist. Insbesondere in CI/CD.
Beanspruchen Sie Ihren Namensraum. Wenn Sie ein CLI-Tool verwalten, registrieren Sie die offensichtlichen Aliase und Falschschreibungen. Eine günstige Versicherung gegen böswillige Handlungen Dritter.
Wie Sie feststellen können, ob Sie betroffen sind
Wenn Sie Aikido , überprüfen Sie Ihren zentralen Feed und filtern Sie nach Malware-Problemen. Alle Schwachstellen phantom werden im Feed als kritisches Problem mit einer Bewertung von 100/100 angezeigt. Aikido Ihre Repositories jede Nacht Aikido , wir empfehlen jedoch, zusätzlich einen vollständigen Rescan durchzuführen.
Wenn Sie noch kein Aikido sind, richten Sie ein kostenloses Konto ein und verbinden Sie Ihre Repositorys. Unsere proprietäre Malware-Abdeckung ist im kostenlosen Tarif enthalten (keine Kreditkarte erforderlich).
Für zukünftigen Schutz sollten Sie die Verwendung von Aikido (Open Source) in Betracht ziehen, einem sicheren Wrapper für npm, npx, yarn und pnpm. SafeChain wird in Ihre aktuellen Workflows integriert, fängt Befehle zur Installation von Paketen ab und überprüft diese anhand von Aikido (unserer Bedrohungsaufklärung), bevor sie auf Ihren Rechner gelangen. Stoppen Sie Bedrohungen schon im Keim.
Die Mathematik
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. Entwickler führen täglich tausende Male npx-Befehle aus. Die Lücke zwischen „praktischer Standardeinstellung“ und „Ausführung beliebiger Codes“ ist ein einziger nicht beanspruchter Paketname.
Sichern Sie Ihre Software jetzt.
