TL; DR
Bösartige npm-Pakete sind kein gelegentliches Ereignis. Sie werden kontinuierlich veröffentlicht, und die Liste der bestätigten Fälle wird wöchentlich aktualisiert. In sieben aufeinanderfolgenden Ausgaben unseres Malicious Code Digest, der mittlerweile in der 87. Auflage erschienen ist, bestätigte Xygeni 635 SchadpaketeDie Spanne reicht von 13 in einer ruhigen Woche bis zu 206 in einer geschäftigen. Entscheidend ist die wöchentliche Schwankungsbreite: Es handelt sich um einen Rhythmus, nicht um ein einzelnes Ereignis.
- Das Problem ist der Rhythmus. Ein Paket verzeichnete innerhalb einer Woche über 55 Versionen, vorher waren es null. Ein anderer Cluster veröffentlichte in weniger als drei Stunden fast 30 Paketnamen. Eine wöchentliche Überprüfung ist die falsche Zeiteinheit.
- Sie kommen nicht als CVEs an. Ein schädliches Softwarepaket stellt keine Schwachstelle in legitimem Code dar, daher gibt es weder eine Warnung noch eine Bewertung oder in der Regel überhaupt keine Kennung. Ein auf Schwachstellen ausgerichtetes Programm ist diesbezüglich strukturell blind.
- Eine Abschaltung ist kein Schutz. Pakete sind üblicherweise nur wenige Minuten bis Stunden aktiv. Ihre Installation fand entweder innerhalb dieses Zeitraums statt oder nicht.
- Die Erkennung muss bei der Veröffentlichung erfolgen, die Durchsetzung bei der Installation. Alles, was auf eine Signatur, eine CVE oder einen wöchentlichen Scan wartet, trifft nach dem Build ein, der es entfernt hat.
Die Liste existiert. Das ist nicht dasselbe wie überwacht zu werden.
Schadsoftware in npm-Paketen ist kein Geheimnis. Bestätigte Fälle werden wöchentlich veröffentlicht, benannt und dokumentiert, unter anderem in [Name der Zeitschrift/des Magazins einfügen]. Xygenis eigener Malicious Code Digest, mittlerweile in der 87. Auflage erschienen.
Die Lücke besteht nicht in Informationen, sondern in Aufmerksamkeit und Rhythmus. Eine wöchentlich aktualisierte, monatlich gelesene und vierteljährlich bearbeitete Liste dokumentiert lediglich, was jemandem bereits widerfahren ist.
Hier sehen Sie, wie sieben Wochen aussahen, basierend auf unseren eigenen bestätigten Erkenntnissen und nicht auf einer Umfrage unter Anbietern.
Das entscheidende Muster sind nicht die Gesamtzahlen, sondern die Geschwindigkeit innerhalb jeder Woche.
Geschwindigkeit ist der ganze Angriff
Drei Erkenntnisse aus diesen Wochen, jede eine andere Art, sich der Überprüfung zu entziehen.
- Versionsflut. Ein einzelnes npm-Paket,
zevairouter, erreichte innerhalb einer Woche mehr als 55 bestätigte Versionen, zu denen zehn weitere aus einem Begleitpaket hinzukamen. Auf PyPI,bingo-aiIn etwa 30 Minuten wurden knapp 80 Versionen erstellt. Kein manueller Überprüfungsprozess kann diese Geschwindigkeit erreichen, und auch kein nächtlicher Prozess nicht. - Synchronisierte Cluster. Siebzehn Pakete, die interne PayPal-Dienstnamen imitierten, wurden innerhalb weniger Minuten veröffentlicht, alle in Version 28.0.0. Das ist keine große Menge, sondern ein Wettlauf: Eine aufgeblähte Versionsnummer dient dazu, das interne Paket der eigenen Teams zu übertrumpfen. Derselbe Trick tauchte Wochen später wieder auf.
@umschool/platformVeröffentlicht unter 999.0.0. - Beharrlichkeit trotz Ausschaltung. Die Kampagne gegen Baileys läuft seit Wochen. Namen wechseln, Versionen tauchen immer wieder auf, und selbst nach der Entdeckung werden die Beiträge erneut veröffentlicht. Wer Sperrungen als notwendiges Übel betrachtet, anstatt sie zu stoppen, wird von Ihrer vierteljährlichen Überprüfung nie aufgehalten.
Die Verweildauer ist bewusst kurz gehalten. In einem kürzlich aufgetretenen Cluster waren die Pakete zwischen 17 Minuten und 13 Stunden aktiv, bevor sie entfernt wurden.
Das ist eher als Zeitfenster für die Zugriffe auf die Registry zu verstehen denn als Leistungskennzahl. Falls währenddessen ein Build ausgeführt wurde, hatte die Entfernung keine Auswirkungen.
Warum Ihr Programm zur Schwachstellenanalyse dies nicht berücksichtigt
Dies ist der strukturelle Punkt, und genau diesen haben die meisten Sicherheitsteams noch nicht verinnerlicht.
Eine Sicherheitslücke ist ein Fehler in Code, der in gutem Glauben geschrieben wurde. Ein Schadprogramm hingegen ist ein absichtlich von einem Angreifer veröffentlichtes Artefakt, üblicherweise ohne Kennung, ohne Warnhinweis und mit einer Lebensdauer von wenigen Stunden. Alle Prozesse, die auf der Erfassung von CVEs, der Bewertung ihres Schweregrades und der Festlegung von Patch-Fenstern basieren, wurden für Ersteres entwickelt und standardmäßig auch auf Letzteres angewendet.
Das Fehlen einer Kennung ist kein Versehen im CVE-System. Es ist so konzipiert, dass die Kategorie wie vorgesehen funktioniert: Niemand meldet ein Artefakt, dessen Zweck ausschließlich böswillig war, und bis es jemand könnte, ist das Paket bereits verschwunden. Das bedeutet, dass die Frage „Gibt es dafür eine CVE-Nummer?„liefert die gleiche Antwort sowohl für ein sauberes Paket als auch für einen vor einer Stunde veröffentlichten Credential-Stealer.“
Was die Nutzlasten jetzt tatsächlich tun
Das naive Bild von bösartigen npm-Paketen ist das eines Krypto-Miners. Die Realität sieht jedoch anders aus: Es geht um den Diebstahl von Zugangsdaten, der sich gegen Entwickler und zunehmend auch gegen die KI-Zugangsdaten auf ihren Rechnern richtet.
Das PhantomSync Ein Cluster, bestehend aus acht unter einem Account veröffentlichten npm-Paketen, funktionierte wie erwartet und verbarg dabei einen sich selbst aufrufenden Dropper, der etwa 37 Sekunden nach dem Import aktiv wurde. Dieser entschlüsselte eine als gefälschte Testumgebung getarnte Payload, installierte plattformübergreifende Persistenz und startete einen Wallet- und Geheimnisdiebstahl. Verzögerung, Verschleierung, Persistenz, Exfiltration.
Im größeren Maßstab die CHAINDROP-Welle der Shai-Hulud-Wurm Anfang August 2026 gab es bereits über 400 Pakete und 1,700 Versionen mit insgesamt 1.3 Milliarden monatlichen Downloads. Der zugehörige Collector scannte nach über 300 Anmeldeinformationsmustern, darunter OpenAI-, Anthropic- und Cursor-Tasten. Entwicklerrechner wurden dadurch wertvoll.cisvor allem wegen der darauf befindlichen Modellnachweise.
Die Namenskonventionen haben sich nach dem Geld gerichtet. Jüngste Cluster geben sich als Krypto- und DeFi-SDKs, Zahlungsmodule, WhatsApp-API-Bibliotheken, AWS-Dienstprogramme und in einem Fall sogar als Paket aus, das offen nach einem Dark-LLM-Angreifertool benannt ist.
Was stoppt tatsächlich schädliche npm-Pakete?
Vier Kontrollmechanismen, in der Reihenfolge, in der sie sich auszahlen.
1. Feststellung bei Veröffentlichung, nicht bei Offenlegung. Xygenis Malware-Frühwarnung Es analysiert neu veröffentlichte Pakete auf npm, PyPI, Maven und anderen Registries in dem Moment, in dem sie erscheinen, mithilfe von Verhaltens- und Anomalieanalysen, anstatt auf eine Signatur oder einen Bericht zu warten. Dies ist der einzige Zeitpunkt in der Zeitleiste, der Ihrem Build voraus ist.
2. Durchsetzung am Installationsort. Die Erkennung meldet, dass ein Paket schädlich ist. Eine Richtlinie, die die Installation blockiert, verhindert die Ausführung des Nachinstallationsskripts. Dies ist umso wichtiger, da Agenten Abhängigkeiten installieren, ohne dass diese manuell ausgewählt werden.
3. Sperrdateien und Hash-Pinning. Arbeiten jederzeit weiterbearbeiten können. Jede Präsentation und jeder KI-Avatar, den Sie von Grund auf neu erstellen oder hochladen, npm ci in CI statt npm installDadurch wird genau der Abhängigkeitsbaum in der Sperrdatei erstellt. Dies schließt den Substitutionspfad, auf dem Typosquats und aufgeblähte Versionen beruhen.
4. Alle Ergebnisse an einem Ort. Malware-Funde gehören in dieselbe Prioritätswarteschlange wie Ihre SCA und Code-Ergebnisse, nicht in einem separaten Feed, den jemand nur überfliegt. Eine bestätigte schädliche Abhängigkeit sollte Vorrang vor einer CVE mit mittlerem Schweregrad haben, und nur ein gemeinsames Risikomodell ermöglicht diesen Vergleich.
Behalten Sie die Liste im Auge oder automatisieren Sie sie.
Niemand hat die Zeit, jede Woche einen Registry-Feed zu lesen. Genau darum geht es bei der Automatisierung.
Xygeni analysiert neu veröffentlichte Pakete auf npm und anderen Registries zum Zeitpunkt der Veröffentlichung, kennzeichnet bestätigte Malware, bevor sie in einen Build gelangt, und reiht den Befund in dieselbe priorisierte Warteschlange ein wie alle anderen Pakete, mit denen Ihre Teams bereits arbeiten. Malware-Erkennung ist im kostenlosen Developer-Tarif enthalten, was bei den meisten kostenlosen Tarifen in dieser Kategorie nicht der Fall ist.
Kostenlos startenoder lesen Diese Woche im Malicious Code Digest zuerst.
FAQ
Was sind schädliche npm-Pakete?
Pakete, die im npm-Repository veröffentlicht werden und absichtlich so konstruiert sind, dass sie Schaden anrichten: Credentials- und Wallet-Diebstähle, Backdoors, Dropper und Abhängigkeitsverwirrungsartefakte, die interne oder populäre Paketnamen imitieren.
Wie häufig sind bösartige npm-Pakete?
Kontinuierlich. In sieben aktuellen Ausgaben unseres Malicious Code Digest bestätigte Xygeni 635 schädliche Pakete – von etwa einem Dutzend in einer ruhigen Woche bis hin zu über 200 während aktiver Kampagnen. npm macht den überwiegenden Teil aus.
Wie lange bleiben schädliche npm-Pakete verfügbar?
Oftmals Minuten bis Stunden. Dieses Zeitfenster ist entscheidend, denn ein Build, der innerhalb dieses Zeitraums läuft, ist bereits betroffen, unabhängig davon, wie schnell das Paket anschließend entfernt wird.
Erhalten bösartige npm-Pakete CVEs?
In der Regel nicht. Es handelt sich eher um von Angreifern veröffentlichte Artefakte als um Schwachstellen in legitimem Code, und die verfolgten 2026-Kampagnen erhielten während der aktiven Ausnutzung keine CVE-Zuweisungen.
Wie kann ich vor der Installation überprüfen, ob ein Paket schädlich ist?
Verwenden Sie ein Tool, das Pakete bei der Veröffentlichung analysiert, anstatt eines, das eine Liste bekanntermaßen fehlerhafter Pakete überprüft; überprüfen Sie den Herausgeber und die Versionshistorie; seien Sie misstrauisch gegenüber ungewöhnlich hohen Versionsnummern und brandneuen Konten; und setzen Sie eine Richtlinie zum Zeitpunkt der Installation durch, anstatt sich auf Überprüfungen zu verlassen.
Was ist Abhängigkeitsverwirrung?
Die Veröffentlichung eines öffentlichen Pakets mit demselben Namen wie ein internes Paket, üblicherweise in einer aufgeblähten Version, führt dazu, dass der Resolver die Kopie des Angreifers bevorzugt. Der PayPal-Namenscluster in Version 28.0.0 ist ein Paradebeispiel dafür.
