Sapphire Sleet kompromittiert 145 Mastra-AI-Pakete: So lief der npm-Angriff ab

Die betroffenen Pakete kamen zusammen auf mehr als 1,1 Millionen Downloads pro Woche . Microsoft ordnete die Operation am 19. Juni 2026 mit hoher Sicherheit Sapphire Sleet zu .

So funktionierte der Angriff

Der Ablauf entspricht einem bekannten Muster bei Angriffen auf Open-Source-Lieferketten: Nicht der Quellcode des Projekts wird zuerst geknackt, sondern ein vertrauenswürdiger Zugang zum Paket-Ökosystem.

1. Maintainer-Konto durch Social Engineering übernommen

Die Angreifer manipulierten zunächst einen legitimen Mastra-Maintainer und erlangten dessen npm-Zugangsdaten . Das betroffene Konto mit dem Namen „ehindero“ verfügte über Veröffentlichungsrechte für den gesamten @mastra-Namensraum .

2. Hunderte Veröffentlichungen in kurzer Zeit

Mit dem gekaperten Konto veröffentlichten die Angreifer manipulierte Versionen aller Pakete im @mastra/*-Namensraum. Der gesamte Vorgang dauerte rund 88 Minuten; für den eigentlichen Veröffentlichungsansturm nennen einzelne Berichte sogar nur 19 Minuten . Das Tempo spricht für ein automatisiertes Skript und nicht für manuelle Uploads.

3. Unauffällige Schadabhängigkeit eingeschleust

Die manipulierten Versionen enthielten eine Abhängigkeit namens „easy-day-js“. Dabei handelt es sich um ein Typosquat der bekannten Datumsbibliothek „dayjs“ – also um einen Namen, der einer legitimen Bibliothek zum Verwechseln ähnlich sieht . Sicherheitsforscher bezeichnen die Kampagne deshalb als „easy-day-js“ .

4. Schadcode bereits bei der Installation ausgeführt

Die Schadsoftware wurde über ein npm-postinstall-Skript automatisch gestartet. Wer ein betroffenes Paket mit npm install installierte, konnte die Payload auslösen, ohne anschließend überhaupt Anwendungscode ausführen zu müssen .

5. Zugangsdaten und Kryptowährungen ausspioniert

Nach der Ausführung suchte die Payload unter anderem nach Schlüsseln für Kryptowährungs-Wallets, Cloud-Zugangsdaten und Geheimnissen aus CI/CD-Systemen – also aus automatisierten Entwicklungs- und Bereitstellungspipelines . Außerdem deaktivierte sie die TLS-Prüfung und lud einen weiteren Infostealer von einer von den Angreifern kontrollierten Infrastruktur nach .

Wer hinter dem Angriff steckt

Microsoft bewertete die Zuordnung zu Sapphire Sleet am 19. Juni 2026 mit hoher Sicherheit. Als Begründung nannte das Unternehmen die verwendete Infrastruktur sowie Taktiken, Techniken und Vorgehensweisen – kurz TTPs –, die mit früheren Aktivitäten der Gruppe übereinstimmen .

Sapphire Sleet ist ein nordkoreanischer staatlicher Akteur, der vor allem auf den Finanz- und Kryptowährungssektor zielt. Amazon Threat Intelligence brachte die Gruppe zudem mit früheren Angriffen auf npm-Pakete wie axios, debug, chalk und typo-crypto in Verbindung .

Microsoft verschärft die Absicherung von NuGet

Der Mastra-Vorfall fällt in eine Phase, in der Microsoft die Veröffentlichung von Paketen über NuGet.org – die Paketplattform für das .NET-Ökosystem – ohnehin sicherer machen will. Die nun angekündigten Änderungen zielen genau auf das Problem, das solche Angriffe besonders gefährlich macht: langlebige Zugangsschlüssel mit weitreichenden Veröffentlichungsrechten.

API-Schlüssel künftig höchstens 30 Tage gültig

Ab dem 17. August 2026 dürfen neu erstellte NuGet.org-API-Schlüssel höchstens 30 Tage gültig sein. Die bisher mögliche Laufzeit von 365 Tagen entfällt .

Alle API-Schlüssel, die vor diesem Datum erstellt wurden, laufen am 1. November 2026 automatisch ab . Maintainer müssen bis dahin neue Schlüssel ausstellen oder auf Trusted Publishing umsteigen.

Microsoft begründet den Schritt damit, dass langfristig gültige API-Schlüssel leicht verloren gehen oder in falsche Hände geraten können. Wer einen solchen Schlüssel stiehlt, erhält ein langes Zeitfenster, um unter dem Namen eines vertrauenswürdigen Projekts manipulierte Pakete zu veröffentlichen .

Trusted Publishing statt dauerhaft gespeicherter Geheimnisse

Microsoft empfiehlt Maintainerinnen und Maintainer, auf Trusted Publishing umzusteigen. Der im September 2025 eingeführte Ansatz nutzt OpenID Connect (OIDC), um Veröffentlichungen aus CI/CD-Systemen zu authentifizieren, anstatt dauerhaft gültige API-Schlüssel in Repositories oder Build-Umgebungen zu hinterlegen .

Die wichtigsten Vorteile :

• Keine langlebigen Geheimnisse: In Repositorys und CI/CD-Systemen muss kein dauerhaft gültiger Schlüssel gespeichert werden.
• Kurzlebige Zugangsdaten: Für jeden Veröffentlichungsvorgang werden temporäre Zugangsdaten ausgestellt, die typischerweise etwa eine Stunde gültig sind.
• Prüfung der Workload-Identität: NuGet kann Repository, Workflow und – sofern eingerichtet – die Umgebung gegen eine registrierte Richtlinie prüfen.
• Keine manuelle Schlüsselrotation: Die regelmäßige Erneuerung dauerhaft gespeicherter Geheimnisse entfällt.
• Kleinerer Schadensradius: Wird eine kurzfristige Berechtigung offengelegt, ist sie deutlich weniger lange nutzbar.

Technisch fordert der CI/CD-Workflow – beispielsweise über GitHub Actions – ein kryptografisch signiertes OIDC-Token an. NuGet.org prüft dieses Token gegen die hinterlegte Publisher-Richtlinie und stellt anschließend einen temporären, nur einmal verwendbaren API-Schlüssel für die jeweilige Veröffentlichung aus .

Auch npm und andere Paketplattformen ziehen die Laufzeiten an

Microsofts Maßnahmen stehen nicht isoliert. Das gesamte Paket-Ökosystem entfernt sich von dauerhaft gültigen Veröffentlichungstokens:

• npm hat klassische Tokens abgeschafft: Im Dezember 2025 wurden alle klassischen, langlebigen Tokens dauerhaft widerrufen. npm login stellt seitdem nur noch Sitzungs-Tokens mit einer Laufzeit von zwei Stunden aus .
• Granulare npm-Tokens laufen ab: Neue granulare Tokens mit Schreibrechten haben standardmäßig eine Laufzeit von sieben Tagen und höchstens 90 Tagen .
• Staged Publishing bei npm: Die seit Mai 2026 allgemein verfügbare Funktion verlangt, dass Maintainer eine Veröffentlichung per Zwei-Faktor-Authentifizierung ausdrücklich freigeben, bevor sie öffentlich installierbar wird .

Zusammen sollen diese Maßnahmen das Angriffsmuster erschweren, das Sapphire Sleet im Mastra-Fall ausgenutzt hat: ein einzelnes, langlebiges und unzureichend geschütztes Maintainer-Token mit Veröffentlichungsrechten für einen kompletten Paketbereich.

Was Entwickler und Maintainer jetzt tun sollten

• NuGet-Schlüssel rechtzeitig ersetzen: API-Schlüssel, die vor dem 17. August 2026 erstellt wurden, laufen am 1. November 2026 ab. Neue Schlüssel sollten nur als Übergangslösung dienen; langfristig empfiehlt sich Trusted Publishing .
• Trusted Publishing aktivieren: OIDC-basierte Authentifizierung wird unter anderem von NuGet.org, npm und PyPI unterstützt .
• npm-Veröffentlichungsprozesse prüfen: CI/CD-Pipelines sollten Sitzungs-Tokens, zeitlich begrenzte granulare Tokens oder Trusted Publishing verwenden – nicht dauerhaft gespeicherte Zugangsdaten .
• Abhängigkeiten fest an bekannte Versionen binden: Besonders bei kritischer Infrastruktur können Versions-Pinning und das Vermeiden automatischer Upgrades verhindern, dass kompromittierte Pakete unbemerkt eingezogen werden .
• Installationsskripte kontrollieren: npm install --ignore-scripts oder die globale Einstellung ignore-scripts = true verhindert die automatische Ausführung von Pre- und Post-Installationsskripten. Das kann eine schädliche postinstall-Payload blockieren .
• Nach einem möglichen Treffer Zugangsdaten rotieren: Wurden betroffene Pakete installiert oder gebaut, sollten unter anderem Cloud-, npm-, GitHub-Actions- und CI/CD-Zugangsdaten überprüft und gegebenenfalls erneuert werden .