Automatisierter Vorfall bei Paketveröffentlichungen im NPM-Ökosystem: IndonesianFoods mit Crypto-Reward-Farming-Betrug verknüpft

„Die Erkenntnisse von Amazon setzen die Aktivitäten des IndonesianFoods-Wurms, die unser Team analysiert hat, im Grunde fort – und erinnern daran, wie einfach sich mithilfe von KI-ähnlicher Automatisierung Hunderttausende nutzlose oder riskante Pakete veröffentlichen lassen. Entwickler sollten auf automatisierte Prüfungen des Dependency-Zustands und verhaltensbasierte Scans statt auf manuelle Überprüfungen setzen: Pakete mit wenigen Downloads, wiederverwendeten Vorlageninhalten und plötzlichen Massenveröffentlichungen sollten erkannt werden, bevor sie in den Build gelangen. Auch Registry-Betreiber müssen sich weiterentwickeln – indem sie Massen-Uploads, wiederverwendete Vorlagen-Hashes und Anomalien beim Metadatenzustand proaktiv erkennen, damit solche Kampagnen direkt an der Quelle gestoppt werden.“

– Manoj Nair, Chief Innovation Officer bei Snyk

Kurzfassung

Im November 2025 entdeckten Sicherheitsforscher einen massiven Anstieg von Paketveröffentlichungen in der NPM-Registry mit ähnlichen Strukturen und Namensmustern. Während erste Berichte einen Wurm vermuteten, handelt es sich bei diesen Aktivitäten wahrscheinlich um die Überreste eines lange inaktiven Automatisierungsskripts, das mit einem Kryptowährungs-Prämienprogramm verknüpft war. 

Hinweis: Es wurde kein aktiver Exploit in freier Wildbahn bestätigt, und die betroffenen Pakete stellen derzeit nur ein minimales Risiko dar. 

Offenbar hat ein Entwickler ein Spam-Skript geschrieben und es anschließend als Teil des Spams hochgeladen. Es handelt sich um die Überreste eines automatisierten Veröffentlichungsskripts, das ursprünglich mit einem veralteten Kryptowährungsprojekt zum Prämien-Farming verknüpft war. Insgesamt gibt es fünf unterschiedliche Pakete, die tausendfach mit leicht abweichenden Namen kopiert wurden. Die einzige schädliche Funktion besteht darin, fortlaufend Pakete zu veröffentlichen. Jedes Paket mit dem Veröffentlichungsskript wird durchschnittlich nur 18-mal pro Monat heruntergeladen. 

Dennoch unterstreicht der Vorfall, wie wichtig eine sorgfältige Dependency-Hygiene und vertrauenswürdige Registry-Praktiken sind.

Betroffene Komponente und betroffenes Ökosystem

Der Vorfall betrifft eine Gruppe von NPM-Paketen, die unter mehreren ähnlich benannten Accounts veröffentlicht wurden. Sie verwenden konsistente Code-Vorlagen (häufig eine Next.js-Basis) und unterscheiden sich zwischen Versionen und Namen nur geringfügig strukturell (z. B. durch Suffixe wie -wekto, -riris und -z3n). Die Pakete scheinen im Laufe der Zeit massenhaft veröffentlicht worden zu sein, wahrscheinlich mithilfe von Skript-Automatisierung, statt in aktiven Systemen installiert und ausgenutzt worden zu sein. Sie verweisen auf eine ältere Crypto-Prämienkampagne (tea.xyz), zeigen jedoch keine bestätigte schädliche Ausführung oder Selbstverbreitung nach der Installation.

Zeitleiste des Vorfalls

• Ende 2023: Mehrere Basis-Pakete werden veröffentlicht (zum Beispiel vointea und voinzaril), zunächst mit harmlos wirkendem Web-App-Code.

• Kurz darauf beginnt eine Massenveröffentlichung mit Hunderten oder Tausenden abgeleiteten Paketen, die ähnliche Code-Vorlagen mit umbenannten Suffixen verwenden.

• Mehrmonatige Pause: Die Aktivitäten kommen zum Erliegen.

• Zwei Monate später: Weitere Serien werden massenhaft veröffentlicht (die Suffixmuster ändern sich).

• 11. November 2025: In der Community beginnen Diskussionen. Dabei wird vermutet, dass bis zu ~44.000 Pakete betroffen sein könnten (die tatsächliche Zahl der Massenveröffentlichungen dürfte jedoch geringer sein).

• 12. November 2025: Analysen zeigen, dass es sich bei den Paketen um harmlose Überreste einer alten Kampagne und nicht um aktive Malware handelt.

Betroffene NPM-Pakete

• Etwa fünf unterschiedliche „Stamm“-Pakete lassen sich identifizieren (vointea, voinzaril sowie Varianten mit den Suffixen wekto, riris und z3n).

• Die geschätzte Anzahl der Kopien liegt wahrscheinlich bei mehreren Tausend (z. B. ~4.000–5.000 Paketen) und nicht bei Zehntausenden. Die höheren Zahlen berücksichtigen zusätzliche kleinere Versionen innerhalb der Pakete.

• Die durchschnittlichen Download-Zahlen dieser Pakete sind äußerst niedrig (in der Regel unter 20 Downloads pro Monat).

• Es wurden keine bestätigten Kompromittierungen nachgelagerter Abhängigkeiten gemeldet, und es wurde keine bekannte Exploit-Kette beobachtet.

• Da die Codeausführung einen manuellen Aufruf erfordert und keine verborgene Remote-Nutzlast entdeckt wurde, bleibt das Risiko für typische Nutzer gering.

Wie es zur IndonesianFoods-Kampagne kam

Statt eines klassischen Wurms oder Remote-Exploits scheint es sich um einen automatisierten Veröffentlichungsprozess zu handeln: Ein Skript erzeugte und veröffentlichte Varianten einer Web-App-Codevorlage, wahrscheinlich zu Anreiz- oder Versuchszwecken (z. B. im Zusammenhang mit einer Kryptowährungsaktion von „tea.xyz“).

Die Analyse ergab, dass die Pakete keine schädlichen Nutzlasten enthielten. Stattdessen enthielten viele lediglich Boilerplate- oder Stub-Code. Dem Veröffentlichungsprozess fehlte eine automatisierte Abbruchbedingung. Er wurde offenbar an bestimmten Tagen manuell gestartet, statt sich autonom über infizierte Systeme auszubreiten.

Zusammenfassung der Aktivitäten

• Verwendung eines oder mehrerer NPM-Accounts mit erweiterten Veröffentlichungsrechten.

• Eine Code-Vorlage wurde in Hunderten oder Tausenden Varianten wiederverwendet.

• Pakete mit wenigen Downloads und minimaler Nutzung

• Keine komplexen Tarn- oder polymorphen Nutzlasten, sondern auffällige Massenveröffentlichungen.

Warum wurde der Vorfall nicht früher erkannt?

• Da die Pakete nur wenige Downloads und keine offensichtlichen Laufzeiteffekte aufwiesen, blieben sie unter dem Radar.

• Die Heuristiken von Registries konzentrierten sich in der Vergangenheit vor allem auf Exploits oder schädliches Verhalten nach der Installation – nicht allein auf das Veröffentlichungsvolumen.

• Die Kampagne scheint teilweise aufgegeben worden zu sein; es wurden keine aktiven Exploits beobachtet.

Erkennungs- und Scan-Strategie

Was Entwickler und Unternehmen tun können

Mit Tools wie der Snyk Vulnerability Database können Entwickler neue Abhängigkeiten anhand ihrer Popularität, Pflege, Sicherheit und Community-Kennzahlen bewerten. 

Wichtig ist auch, sicherzustellen, dass automatisierte Scans sowohl den Zustand von Abhängigkeiten als auch Code-Risiken abdecken. Dafür eignen sich Tools wie:

• Snyk Open Source (Software Composition Analysis) scannt Bibliotheken von Drittanbietern auf bekannte Schwachstellen und Lizenzprobleme. 

• Snyk Code (Static Application Security Testing) analysiert benutzerdefinierten Code auf Schwachstellen.

• Snyk Container und Snyk IaC scannen Container-Images bzw. Infrastructure-as-Code-Konfigurationen.

Im Zusammenhang mit diesem Vorfall können Sie Pakete mit extrem wenigen Downloads oder wiederkehrenden Inhalten über viele Versionen hinweg kennzeichnen. Sinnvoll ist auch, plötzliche umfangreiche Uploads von einem einzelnen Account oder die Wiederverwendung von Vorlagen über mehrere Pakete hinweg zu überwachen. Nutzen Sie außerdem Metadaten-Heuristiken wie das Datum der letzten Veröffentlichung, den Versionsverlauf, die Anzahl der Maintainer und die Community-Aktivität.

Wie Registry-Teams ihre Überwachung verbessern können

Die Überwachung lässt sich verbessern, indem Muster bei Massenveröffentlichungen erfasst werden, insbesondere das Veröffentlichungsvolumen und der Zeitpunkt pro Account. Wichtig ist auch, Ausreißer bei der Anzahl der Veröffentlichungen, häufigen Versionswechseln und der Wiederverwendung von Namensmustern zu erkennen. Registry-Teams sollten Prüfungen auf die Wiederverwendung von Vorlagen integrieren, etwa durch den Vergleich von Datei-Hashes verschiedener Pakete. Außerdem sollten sie frühzeitig Kennzahlen zum Metadaten-„Zustand“ auswerten, etwa Downloads, Repository-Sterne und Aktivitäten von Maintainerinnen und Maintainer.

Schadensbegrenzung und nächste Schritte

Für Endnutzer und Unternehmen:

1. Es sind keine sofortigen Maßnahmen erforderlich, wenn Sie keines der verdächtigen Pakete referenziert oder installiert haben.

2. Überprüfen Sie Ihren Dependency-Graph, um ungenutzte oder risikoarme Pakete zu erkennen und selten verwendete Abhängigkeiten zu entfernen oder zu isolieren.

3. Verwenden Sie Snyk Advisor vor der Installation: Prüfen Sie den Zustand und die Risikoindikatoren eines Pakets, bevor Sie eine neue Abhängigkeit hinzufügen.

4. Verwenden Sie npq: npq ist ein Open-Source-Tool, das anhand von Heuristiken wie Download-Zahlen die Installation solcher Pakete verhindert. 

5. Richten Sie Policy-Gates in Ihrer CI/CD ein: Blockieren Sie beispielsweise das Hinzufügen von Paketen, deren Download-Zahlen unter einem bestimmten Schwellenwert liegen oder für die es keine aktuellen Commits gibt.

Abschließende Worte

Die Veröffentlichung dieser Pakete in der NPM-Registry sorgte zwar für Schlagzeilen über einen „Wurm“ oder einen Supply-Chain-Exploit, doch unsere Untersuchung bestätigt, dass es sich nicht um einen aktiven Malware-Ausbruch handelt, sondern um ein Relikt früherer Automatisierung im Zusammenhang mit einer Crypto-Kampagne. Das unmittelbare Risiko für die meisten Nutzer ist gering. 

Dennoch ist der Vorfall eine aktuelle Erinnerung daran: Auch harmlos wirkende Pakete können ein Supply-Chain-Risiko darstellen, wenn sie nicht verwaltet, schlecht gepflegt oder kaum bekannt sind. Tools wie Snyk Advisor und Snyk for JavaScript, konsequent durchgesetzte Dependency-Richtlinien und eine sorgfältige Überwachung der Registry tragen dazu bei, die Dependency-Hygiene in allen Ökosystemen aufrechtzuerhalten.