SafeDep beschreibt „easy-day-js“ als Klon der Datumsbibliothek „dayjs“, der einen Remote-Access-Trojaner zum Diebstahl von Kryptowerten nachlädt und ausführt. Veröffentlicht wurde die JavaScript-Bibliothek demnach von dem npm-Nutzer „sergey2016“ am 16. Juni 2026 um 7:05 Uhr UTC zunächst als saubere, voll funktionsfähige Kopie. Die schädlichen Änderungen wurden laut SafeDep am 17. Juni 2026 um 1:01 Uhr UTC nachgereicht.
Die Bibliothek startet einen verschleierten Schadcode über einen „postinstall“-Hook. Dieser fungiert als Dropper oder Loader für eine zweite Stufe, die von einer von den Angreifern kontrollierten Infrastruktur unter „23.254.164[.]92“ abgerufen wird, nachdem die TLS-Zertifikatsprüfung abgeschaltet wurde. Anschließend wird die Nutzlast als losgelöster Hintergrundprozess gestartet. Der Loader versucht danach, sich selbst zu löschen, um forensische Spuren zu minimieren.
In der letzten Stufe kommt laut den vorliegenden Analysen ein plattformübergreifender Information-Stealer zum Einsatz. Er kann den Browserverlauf auslesen, Daten aus mehr als 160 Browser-Erweiterungen für Krypto-Wallets sammeln, auf Windows, macOS und Linux Persistenz einrichten und die erfassten Informationen an einen Command-and-Control-Server unter „23.254.164[.]123“ exfiltrieren. Zudem kann die Malware den C2-Server regelmäßig nach Befehlen abfragen, darunter das Herunterladen eines Moduls von einer durch die Angreifer vorgegebenen URL und dessen Ausführung auf Windows-, Linux- und macOS-Systemen.
JFrog zufolge kombiniert die Kampagne bekannte Supply-Chain-Techniken mit praktischer Tarnung: eine saubere Lockversion, einen verschleierten Loader im „postinstall“-Schritt, das Nachladen der eigentlichen Nutzlast zur Laufzeit, losgelöste Ausführung, Selbstlöschung, an Node angelehnte Persistenz und ein fernsteuerbares Modulsystem. JFrog warnt außerdem, dass der Prozess der zweiten Stufe selbst dann weiterlaufen kann, wenn das Paket der ersten Stufe nach der Installation entfernt wurde, und dass möglicherweise bereits Persistenz eingerichtet wurde.
Nach Einschätzung der Forscher wurde das Konto „ehindero“ übernommen. Dabei handelte es sich demnach um das Konto eines legitimen früheren Mastra-Mitwirkenden, dessen Zugriffsrechte auf den Namensraum nie entzogen worden waren. SafeDep weist darauf hin, dass Mastra reguläre Veröffentlichungen aus der CI über den „trusted publisher“-Ablauf von npm ausliefert und jede davon SLSA-Provenienz-Nachweise trägt. Die Angreifer hätten die schädlichen Versionen jedoch mit einem persönlichen Token veröffentlicht und die Provenienz entfernt.
Laut SafeDep wiederholt sich dieser Fingerabdruck im gesamten Namensraum. Mastra habe Provenienz bei CI-Veröffentlichungen zwar erzeugt, aber nicht erzwungen. Dadurch habe ein gewöhnliches npm-Token weiterhin Pakete ohne solche Nachweise veröffentlichen können. Eine Installation mit Signaturprüfung — etwa über „npm audit signatures“ oder über eine Richtlinie, die Provenienz-Nachweise verlangt — hätte laut SafeDep alle Pakete dieser Welle zurückgewiesen.
Zu den betroffenen Paketen zählt laut Socket auch „@mastra/core“ mit mehr als 918.000 wöchentlichen Downloads auf npm. Socket betont, dass dadurch ein großes potenzielles Ausmaß entsteht. Weil die Nutzlast bereits während der Installation ausgeführt wird, können Systeme demnach schon kompromittiert werden, bevor Entwickler das Paket importieren oder verwenden.