144 Mastra-Pakete verfälscht: Angriff über gekaperten npm-Zugang : Manipulierte Abhängigkeit schleust Infostealer in KI-Entwicklungsumgebungen
Ein gekaperter Zugang reichte aus, um 144 Pakete aus dem Mastra-Namensraum zu kompromittieren. An diesem Angriff lässt sich eindrücklich zeigen, wie gefährlich installierbare Abhängigkeiten für KI-Projekte werden können: Der Schadcode steckte nicht direkt in den Paketen, sondern kam über eine nachgeladene Bibliothek.
Bei einem groß angelegten Angriff auf die Software-Lieferkette sind 144 Pakete aus dem Namensraum „@mastra/*“ kompromittiert worden. Mastra ist ein populäres quelloffenes JavaScript- und TypeScript-Framework für Anwendungen mit Künstlicher Intelligenz (KI). Nach Analysen von Endor Labs, JFrog, SafeDep, Socket und StepSecurity lief die Kampagne unter dem Namen easy-day-js und traf damit ein Ökosystem, das häufig in besonders sensiblen Entwicklungs- und Cloud-Umgebungen eingesetzt wird.
Socket beschreibt das Ausmaß mit deutlichen Worten: „Ein einzelnes npm-Konto veröffentlichte innerhalb eines kurzen Zeitfensters mehr als 140 schädliche Pakete im Mastra-Bereich.“ Konkret soll das Konto „ehindero“ am 17. Juni 2026 massenhaft manipulierte Versionen veröffentlicht haben. Der Vorgang dauerte nach den vorliegenden Analysen lediglich 88 Minuten.
Schadcode kam über eine neue Abhängigkeit
Die betroffenen Mastra-Pakete enthielten den Schadcode nicht selbst. Stattdessen wurde jeder Veröffentlichung eine zusätzliche Drittanbieterbibliothek namens easy-day-js in die Abhängigkeitsliste geschrieben. Genau darin lag die technische Raffinesse: Für Entwickler wirkte das Paket zunächst wie eine harmlose Ergänzung. Tatsächlich wurde dadurch beim Installieren ein mehrstufiger Angriff ausgelöst.
SafeDep beschreibt easy-day-js als Klon der bekannten Datumsbibliothek dayjs. Die Bibliothek wurde am 16. Juni 2026 um 7:05 Uhr koordinierter Weltzeit zunächst als saubere, funktionsfähige Kopie veröffentlicht. Am 17. Juni 2026 um 1:01 Uhr koordinierter Weltzeit folgte eine manipulierte Version. Diese lud und startete einen Remote Access Trojaner (RAT), der auf den Diebstahl von Kryptowährungen und sensiblen Informationen ausgelegt war.
Damit nutzten die Angreifer ein klassisches Muster moderner Lieferkettenangriffe: Ein scheinbar legitimes Paket wird zunächst unauffällig platziert, anschließend verändert und über eine vertrauenswürdig wirkende Abhängigkeit in produktive Entwicklungsumgebungen getragen.
Installation genügte für die Kompromittierung
Besonders kritisch ist der Ausführungszeitpunkt. Der Angriff setzte bereits während der Installation an. easy-day-js startete über einen sogenannten Postinstall-Hook einen verschleierten Loader. Dieser deaktivierte die Prüfung von Zertifikaten für Transport Layer Security (TLS), kontaktierte eine von den Angreifern kontrollierte Infrastruktur unter „23.254.164[.]92“ und lud von dort eine zweite Schadstufe nach.
Die nachgeladene Komponente wurde als abgekoppelter Hintergrundprozess ausgeführt. Anschließend versuchte der Loader, eigene Spuren zu verwischen, indem er sich selbst entfernte. JFrog fasst die Vorgehensweise als Kombination aus bekannten Lieferkettentechniken und praktischer Tarnung zusammen: saubere Köderversion, verschleierter Postinstall-Loader, Laufzeitnachladung, abgekoppelte Ausführung, Selbstlöschung, Node-bezogene Persistenz und ein System für entfernte Module.
Das bedeutet: Selbst wenn die erste Schadkomponente nach der Installation entfernt wird, kann die zweite Stufe weiterlaufen. JFrog warnt entsprechend, dass der Prozess bereits Persistenz eingerichtet haben kann. Damit reicht unter Umständen ein einziger Installationsvorgang auf einem Entwicklerrechner, Continuous-Integration-Runner (CI-Runner) oder Build-System aus, um Zugangsdaten und weitere sensible Informationen zu gefährden.
Infostealer mit breitem Funktionsumfang
Die finale Schadsoftware ist plattformübergreifend ausgelegt und kann Windows, macOS und Linux betreffen. Sie sammelt Browserhistorien, liest Daten aus mehr als 160 Browser-Erweiterungen für Kryptowährungs-Wallets aus, richtet Persistenz ein und überträgt erbeutete Informationen an einen Command-and-Control-Server (C2) unter „23.254.164[.]123“.
Zusätzlich kann die Malware den C2-Server regelmäßig abfragen und weitere Befehle entgegennehmen. Dazu gehört das Herunterladen eines Moduls von einer durch die Angreifer vorgegebenen Adresse und dessen Ausführung auf den betroffenen Systemen. Aus einem manipulierten Paket wird so ein flexibler Einstiegspunkt für nachgeladene Funktionen.
StepSecurity hebt hervor, warum gerade Mastra ein attraktives Ziel ist: Das Framework liegt an der Schnittstelle von KI-Entwicklung und Cloud-Infrastruktur. Die Pakete landen daher häufig in Umgebungen, in denen Zugangsdaten, Programmierschnittstellen-Schlüssel, Token und Deployment-Rechte gespeichert sind. Damit besitzt das Ökosystem einen großen Angriffswert.
Gekaperter Account gehörte ehemaligem Mastra-Mitwirkenden mit weiter gültigen Rechten
Nach den vorliegenden Erkenntnissen gehörte das kompromittierte npm-Konto „ehindero“ einem legitimen früheren Mastra-Mitwirkenden, dessen Zugriffsrechte auf den Scope offenbar nie entzogen worden waren. Genau dieses verbliebene Recht ermöglichte die Massenveröffentlichung manipulierter Pakete.
SafeDep nennt eine weitere Schwachstelle in der Absicherung der Veröffentlichungskette: Offizielle Mastra-Versionen werden normalerweise über Continuous Integration (CI) und den Trusted-Publisher-Mechanismus von npm ausgeliefert und enthalten Provenance-Attestierungen nach Supply-chain Levels for Software Artifacts (SLSA). Die Angreifer veröffentlichten die manipulierten Versionen jedoch über ein persönliches Token und ohne diese Herkunftsnachweise.
Die Konsequenz ist deutlich: Provenance war vorhanden, aber nicht verpflichtend. Eine Installationsrichtlinie, die Signaturen oder Attestierungen zwingend prüft, hätte die Pakete aus dieser Angriffswelle ablehnen können.
Großer möglicher Schadensradius
Zu den betroffenen Paketen gehört auch „@mastra/core“. Laut Socket erzielt dieses Paket mehr als 918.000 wöchentliche Downloads über npm. Der mögliche Schadensradius ist damit erheblich, zumal der Schadcode schon beim Installieren ausgeführt wurde – unabhängig davon, ob Entwickler das Paket später tatsächlich importierten oder produktiv nutzten.
Für betroffene Organisationen ergibt sich daraus ein klarer Handlungsbedarf. Alle Workstations, CI-Runner und Build-Umgebungen, auf denen die betroffenen Versionen installiert wurden, sollten als potenziell kompromittiert gelten. Empfohlen sind insbesondere:
- Rückkehr auf sichere Versionen der betroffenen Pakete,
- Rotation aller potenziell offengelegten Zugangsdaten, darunter Token, Schlüssel und Passwörter,
- Prüfung auf persistente Prozesse auf Entwicklerrechnern, CI-Runnern und Build-Systemen,
- Forensische Suche nach Artefakten der Kampagne, um Spuren nachgeladener Schadkomponenten zu erkennen.
Der Fall zeigt, wie eine einzelne neue Abhängigkeit zur massiven Gefahr werden kann: In KI-Projekten mit Cloud-Anbindung, automatisierten Builds und weitreichenden Token kann sie Angreifern direkten Zugriff auf geschäftskritische Entwicklungs- und Betriebsumgebungen verschaffen.