LONDON (IT BOLTWISE) – Eine Angreifergruppe hat offenbar über einen kompromittierten npm-Account im Mastra-Namespace innerhalb kurzer Zeit 144 Pakete mit einem mehrstufigen Loader ausgeliefert. Der Schadcode sitzt dabei nicht direkt in den betroffenen Bibliotheken, sondern wird über eine zusätzlich eingetragene Drittanbieter-Abhängigkeit („easy-day-js“) nach dem Installieren aktiviert. Besonders kritisch: Der Angriff startet im postinstall-Hook, kann also Systeme bereits kompromittieren, bevor Entwickler den Code bewusst nutzen. Betroffene sollten Versionen zurückrollen, Tokens rotieren und CI-Runner sowie Build-Hosts gezielt auf Indikatoren prüfen.
Die jüngste npm-Supply-Chain-Kampagne zeigt erneut, wie stark moderne KI-Entwicklungs-Stacks von Open-Source-Abhängigkeiten abhängen und wie schnell sich ein Vertrauensmodell ausnutzen lässt. Laut mehreren Analyse- und Security-Diensten wurden im Mastra-Namespace (@mastra/*) 144 Pakete kompromittiert, die auf die Erstellung von KI-Anwendungen im JavaScript- und TypeScript-Umfeld einzahlen. Auslöser war offenbar ein sogenannter „Hijack“ eines einzelnen npm-Kontos, über das in einem engen Zeitfenster massenhaft Schadpakete veröffentlicht wurden. Dabei wirkten die Pakete zunächst harmlos, weil der eigentliche Angriffscode über eine zusätzliche Dependency nachgeladen wird.
Technisch greift der Angriff in der Installationsphase an: Die infizierten Mastra-Pakete enthalten demnach selbst keinen offensichtlichen bösartigen Code, sondern referenzieren jeweils eine dritte Bibliothek mit dem Namen „easy-day-js“ in ihrer Dependency-Liste. Genau diese Bibliothek startet eine obfuskierten Payload über einen postinstall Hook, also genau dann, wenn Paketmanager wie npm die Installation abschließen. Der Mechanismus funktioniert damit „vor“ der eigentlichen Nutzung, was die übliche Annahme vieler Teams unterläuft, dass Risiko erst beim Import oder beim Laufzeitbetrieb entsteht. Zusätzlich wird TLS-Zertifikatsvalidierung deaktiviert, um das spätere Abrufen der zweiten Stufe zu erleichtern.
Die zweite Stufe wird aus Infrastruktur des Angreifers geladen, anschließend ausgeführt und als detachierter Hintergrundprozess gestartet. Damit entkoppeln sich Schadcode-Ausführung und Installationslogik, wodurch die forensische Nachvollziehbarkeit weiter erschwert wird. Danach versucht der Loader, sich selbst zu entfernen oder zu „säubern“, um Spuren zu minimieren. In der finalen Phase folgt ein informationstehlender Prozess, der nicht nur Browserhistorien auslesen kann, sondern auch Daten aus zahlreichen Krypto-Wallet-Browser-Extensions sammelt. Gleichzeitig zielt die Kampagne auf Persistenz über mehrere Betriebssysteme hinweg ab, einschließlich Windows, macOS und Linux, und exfiltriert anschließend die gesammelten Daten an einen Command-and-Control-Server.
Für die Risikoabschätzung ist besonders relevant, dass der Mastra-Namespace in der Breite genutzt wird. Ein Analysefokus nennt explizit das Paket @mastra/core, das demnach eine große Zahl wöchentlicher npm-Downloads aufweist und damit ein weites „Blast Radius“-Potenzial mitbringt. Experten betonen außerdem einen Timing-Aspekt: Da der postinstall-Hook unmittelbar beim Installieren feuert, können CI-Runner, Entwicklerworkstations und Build-Umgebungen bereits kompromittiert sein, bevor Quellcode-Reviews greifen oder bevor abhängige Module tatsächlich importiert werden. In klassischen Security-Checks wird dann oft erst später eine auffällige Prozesskette entdeckt, etwa wenn Exfiltration oder Persistenzaktivitäten sichtbar werden.
Marktseitig lässt sich der Vorfall als weitere Eskalationsstufe im Wettbewerb um Software-Supply-Chain-Schutz lesen. Während npm als Ökosystem in Richtung Signaturen, Policies und vertrauensbasierte Flows weiterentwickelt, wird in vielen Organisationen weiterhin stark auf etablierte Praxis gebaut: Dependency-Scanning über Tools wie Snyk, Plattform-Checks in CI oder automatisierte Updates etwa via GitHub Dependabot. Der Unterschied in diesem Fall liegt darin, dass ein „vertrauenswürdiger“ Publikationsmechanismus offenbar durch das Abgreifen eines personal token missbraucht wurde. Ein zentrales Argument aus den Analysen lautet, dass Provenance-Mechanismen zwar verfügbar waren, aber in den betroffenen Releases nicht durchgehend verpflichtend eingefordert wurden.
Genau hier wird eine technische Weichenstellung sichtbar, die für Enterprise-Teams oft unterschätzt wird: Selbst wenn eine Plattform SLSA-Provenance attestiert, muss diese in der Konsum-Policy auch wirklich als harte Voraussetzung wirken. In der Auswertung wird beschrieben, dass die Angreifer Pakete über einen persönlichen Token veröffentlicht und dabei Provenance-Attestierungen gezielt „fallen gelassen“ haben. Gleichzeitig könne ein Standard-npm-Token veröffentlichen, ohne dass Attestierungen zwingend nötig sind, wenn die Publishing-Seite keine strikte Anforderung durchsetzt. Eine installationsseitige Absicherung, etwa über Signaturprüfung oder eine Policy, die Attestierungen erzwingt, hätte demnach jede Paketvariante dieser Welle bereits blockieren können.
Für die Reaktion ergibt sich ein klarer, aber umfangreicher Maßnahmenkatalog. Betroffene Systeme sollten als potenziell kompromittiert betrachtet werden, insbesondere dort, wo die betroffenen Versionen installiert wurden: lokale Entwicklungsrechner, CI-Runner, ephemeral Build-Hosts und sogar Container-Build-Pipelines. In der Praxis bedeutet das: auf sichere Versionen zurückrollen, Credentials und Tokens rotieren, die CI-Konfiguration auf verdächtige Schritte prüfen und Artefakte sowie Prozessspuren im Umfeld der Installation abgleichen. Dazu gehört auch das Auditieren nach auffälligen Netzwerkverbindungen zum beschriebenen Ziel-Pattern, wobei Organisationen dabei datenschutzkonform vorgehen müssen und Logs nur mit klarer Zweckbindung auswerten sollten.
Ausblickend wird deutlich, dass sich die Schutzstrategie von „Scanning nach dem Fakt“ hin zu „Policy by Default“ verschieben muss. Teams sollten Provenance- und Signaturanforderungen nicht nur in einzelnen Projekten aktivieren, sondern als Standard in ihren Organisationen etablieren und konsequent in der Deployment-Pipeline erzwingen. Technisch lohnt sich ein Vergleich: Beim klassischen Ansatz werden Pakete nachträglich geprüft, während bei einer streng policybasierten Installation unsichere Artefakte gar nicht erst in die Umgebung gelangen. Für Entwickler entsteht dadurch zwar zunächst mehr Setup-Aufwand, langfristig sinkt aber die Wahrscheinlichkeit, dass postinstall-basierte Loader unbemerkt Systems erreichen. In den nächsten Monaten ist außerdem zu erwarten, dass Ecosystems wie npm, CI-Anbieter und Security-Plattformen stärker auf attestierungsgebundene Install-Workflows drängen werden.
💳 Amazon-Kreditkarte mit 2.000 Euro Limit bestellen!
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- NIEDLICHER BEGLEITER: Eilik ist der ideale Begleiter für Kinder und Erwachsene, die Haustiere, Spiele und intelligente Roboter lieben. Mit vielen Emotionen, Bewegungen und interaktiven Funktionen.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!
- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "Mastra-npm-Welle: 144 Pakete über Hijacked-Account mit Loader kompromittiert" für unsere Leser?
#Sophos
#AmazonPrime
#Bestseller
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "Mastra-npm-Welle: 144 Pakete über Hijacked-Account mit Loader kompromittiert" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »Mastra-npm-Welle: 144 Pakete über Hijacked-Account mit Loader kompromittiert« bei Google Deutschland suchen, bei Bing oder Google News!