Am 17. Juni 2026 wurde aus einem gestohlenen Entwicklerkonto in neunzehn Minuten ein Verteilsystem für Schadsoftware.

Am 17. Juni 2026 übernahm jemand ein Entwicklerkonto des KI Frameworks Mastra AI. Mit diesem einen Konto wurden in rund neunzehn Minuten mehr als 140 Pakete neu veröffentlicht, versehen mit Schadsoftware. Microsoft ordnet den Angriff der staatlich unterstützten Gruppe Sapphire Sleet zu, die auch als BlueNoroff oder APT38 bekannt ist. Für ein Schweizer KMU ist der Name des Frameworks zweitrangig. Interessant ist, warum ausgerechnet ein KI Framework das Ziel war und was daraus für jedes Unternehmen folgt, das heute Agenten und Automatisierungen im Einsatz hat.

Neunzehn Minuten reichten, weil zwischen einem Konto und der Veröffentlichung nichts steht.

Ein Framework wie Mastra besteht nicht aus einem Paket, sondern aus einer Familie von Paketen: der Kern, die Anbindungen an die Modelle, die Werkzeuge, die Speicher. Wer das Konto hat, das diese Familie veröffentlichen darf, darf sie ganz veröffentlichen. Es gibt keine zweite Person, die gegenzeichnet und keine Wartefrist. Dass 140 Pakete in neunzehn Minuten neu erschienen, heisst nur, dass der Angreifer den Vorgang automatisiert hat, wie es das Projekt selber auch tut.

Kurz ist dieses Fenster nur aus der Sicht des Projekts. Aus der Sicht eines Unternehmens ist es die Zeitspanne, in der jeder Rechner, der ein Projekt einrichtet oder aktualisiert, die manipulierte Version geholt hat, ohne dass jemand etwas anklicken musste. Das Muster ist dasselbe wie im März, als zwei manipulierte Versionen der Bibliothek axios einen Trojaner nachluden. Neu ist nicht der Weg, neu ist, was am Ende des Weges liegt.

Ein KI Framework ist ein lohnendes Ziel, weil es die Schlüssel zu allem anderen hält.

Eine gewöhnliche Bibliothek gibt einem Angreifer das, was auf dem befallenen Rechner liegt. Ein Agenten Framework gibt ihm mehr, weil es seiner Aufgabe nach überall angemeldet ist. In einer typischen Installation hinterlegt ein Team dort den Schlüssel zum Modellanbieter, den Zugang zur Datenbank, ein Token für das Postfach, eines für den Kalender, eines für das CRM und eines für den Speicher, in dem die Dokumente liegen. Nach unserer Erfahrung sind das fünf bis fünfzehn Zugänge pro Agent und sie liegen im selben Verzeichnis wie der Code, damit der Agent sie im Betrieb lesen kann.

Dazu kommt, dass ein Agent handeln darf. Er liest nicht nur, er schreibt Mails, legt Datensätze an, ruft fremde Systeme auf und läuft dabei oft nach Zeitplan, also nachts, wenn niemand zusieht. Ein Angreifer, der in diesem Framework sitzt, braucht keine Rechte zu erschleichen, er benutzt die, die das Unternehmen dem Agenten bewusst gegeben hat. Und weil die Werkzeuge in diesem Feld jung sind und wöchentlich neue Versionen erscheinen, aktualisieren Teams hier häufiger als anderswo, was das Zeitfenster für den Angreifer öffnet statt schliesst.

Vier Fragen klären innert weniger Stunden, ob dein Unternehmen betroffen ist.

Erstens: Läuft bei uns überhaupt ein Agenten Framework und wo? Das ist die Frage, an der es in den meisten KMU bereits scheitert, weil solche Automatisierungen selten beschafft, sondern eingebaut werden, oft von einem Dienstleister. Zweitens: Hat zwischen dem 17. und dem 18. Juni jemand ein betroffenes Projekt eingerichtet, aktualisiert oder gebaut? Das steht in den Versionsdateien und in den Protokollen des Systems, das die Software baut und ist eine Suche von Minuten, wenn die Liste der Projekte existiert.

Drittens: Welche Zugänge hätte ein Angreifer über dieses Framework erreicht? Nicht welche im Framework stehen, sondern welche von dort aus benutzbar sind, inklusive der Systeme, in die sich der Agent selber anmeldet. Viertens: Sind diese Zugänge ersetzt worden? Ein Schlüssel, der in dem Zeitfenster erreichbar war, gilt als bekannt, auch wenn nichts Auffälliges passiert ist. Nach unserer Erfahrung sind diese vier Fragen in zwei Stunden beantwortet, wenn ein Verzeichnis der Projekte und Zugänge existiert und in zwei bis drei Tagen, wenn man es zuerst erstellen muss.

Wer Agenten laufen lässt, entscheidet vorher, was im schlimmsten Fall passieren darf.

Die Massnahmen danach sind unspektakulär und kosten kein neues Produkt. Jeder Agent bekommt eigene Zugänge statt der Sammelschlüssel des Teams, mit einem Ausgabenlimit beim Modellanbieter und mit Leserechten überall dort, wo Schreiben nicht nötig ist. Produktive Kundendaten sind für einen Agenten die Ausnahme, nicht der Normalfall. Versionen werden festgeschrieben, neue erst nach sieben Tagen übernommen und jeder Aufruf, den ein Agent an ein fremdes System macht, wird protokolliert, damit die Frage nach dem Schaden nicht offenbleibt. Zusammen sind das nach unserer Erfahrung drei bis vier Arbeitstage einmalig.

Dass diese Werkzeuge fast alles können und genau darin das Problem liegt, haben wir am Beispiel von Claude Code beschrieben. Der Fall Mastra fügt dem eine zweite Seite hinzu: Es reicht nicht, dem eigenen Agenten zu vertrauen, man vertraut auch jedem, der dessen Bausteine veröffentlichen darf. Software entsteht heute schneller, als sie geprüft wird und wer diese Geschwindigkeit nutzt, muss die Prüfung anderswo einbauen. Die Entscheidung, die dahintersteht, ist keine technische: Es ist die Frage, wer in deinem Unternehmen bestimmen darf, welchem Agenten welcher Schlüssel gehört und wer die Verantwortung trägt, wenn dieser Schlüssel in neunzehn Minuten den Besitzer wechselt.