Unsloth Studio: Blick in ein Modell genügte für Codeausführung

Ausschlaggebend war laut Pillar Security, dass Unsloth Studio beim Prüfen der Modellkonfiguration die Einstellung “trust_remote_code=True” setzte. Dadurch lud und führte die zugrunde liegende Transformers-Bibliothek benutzerdefinierten Python-Code aus, auf den die config.json des Modells verweist — noch bevor das Modell selbst geladen war.

“Der Code lief allein aufgrund einer Metadatenprüfung. Das Lesen der config.json des Modells reichte aus, um den Exploit auszulösen; das Backend hat weder die Gewichte geladen noch eine Inferenz ausgeführt — das bloße Inspizieren eines Modells genügte, um dessen Code auszuführen”, schrieb Fogel.

Da der Code mit den Rechten des angemeldeten Nutzers lief, könnte ein Angriff auf eine KI-Entwicklungsumgebung im Unternehmen nach Fogels Einschätzung proprietäre Trainingsdaten, Modellartefakte sowie Zugangsdaten offenlegen, die an den kompromittierten Prozess gebunden sind — etwa Cloud-Logins oder SSH-Schlüssel. “Ein Angreifer könnte Code als der Nutzer ausführen, was dem Diebstahl zugänglicher Daten, der Veränderung von Modellen und Trainingsergebnissen oder der Nutzung verfügbarer Zugangsdaten für den Zugriff auf andere Systeme gleichkommen kann”, schrieb er. Eine interne Experimentierumgebung könne sensible Daten und privilegierte Zugänge enthalten, selbst wenn über sie kein produktiver Datenverkehr laufe.

Anhaltspunkte für eine Ausnutzung in freier Wildbahn oder für bösartige Modell-Repositories, die genau auf diesen Konfigurationsmechanismus zielen, gibt es nach Angaben von Fogel bislang nicht. Er verweist allerdings darauf, dass andere Angriffskampagnen bereits auf bei Hugging Face hochgeladene Schadmodelle gesetzt haben.

Pillar Security meldete die Schwachstelle Anfang Juni an Unsloth; noch im selben Monat behob das Projekt das Problem mit der Version 2026.6.9. Pillar testete den Angriffsweg erneut und bestätigte, dass er geschlossen ist. Fogel lobte zwar die schnelle Reaktion der Unsloth-Maintainer, hielt jedoch fest, dass Unsloth Teile der Sicherheitsbewertung bestritt — mit dem Hinweis, das Malware-Scanning von Hugging Face stelle eine ausreichende Kontrolle der Angriffsfläche dar, und Studio, das formal als Beta geführt werde, solle aus der Betrachtung ausgenommen bleiben. Pillar widersprach: Diese Argumente gingen nicht darauf ein, dass Studio Repository-Code automatisch ausführt. Eine CVE-Nummer wurde nicht vergeben, da Unsloth die Veröffentlichung des vorgeschlagenen Sicherheitshinweises ablehnte. Ein Kontaktversuch zu Unsloth über X blieb bis Redaktionsschluss unbeantwortet.

Pillar empfiehlt Nutzern:

• Unsloth Studio auf Version 2026.6.9 oder neuer aktualisieren
• Modell-Repositories, die über die Transformers-Einstellung trust_remote_code geladen werden, als nicht vertrauenswürdigen Code und nicht als Daten behandeln
• sicherstellen, dass Werkzeuge in der eigenen Pipeline die Einstellung niemals stellvertretend für den Nutzer aktivieren

Es gibt durchaus legitime Anwendungsfälle für die Einstellung, doch sie stand allein in diesem Jahr bereits mehrfach im Zentrum vergleichbarer Schwachstellen — etwa bei LMDeploy (CVE-2026-46432), vLLM (CVE-2026-4944) und InstructLab (CVE-2026-6859).

Die Häufung deutet laut Fogel auf eine systemische Lücke darin, wie Machine-Learning-Werkzeuge ausführbare Modellinhalte behandeln. Entwickler bauten nützliche Arbeitsabläufe um Artefakte herum, die Nutzer gemeinhin für Daten halten — die aber zugleich Code liefern können. Aktiviere ein Werkzeug stillschweigend trust_remote_code, treffe es eine folgenreiche Sicherheitsentscheidung anstelle des Nutzers. “Was den Fall Unsloth besonders besorgniserregend macht”, sagt Fogel, “ist, dass die Grenze bei einer Aktion überschritten wurde, die Nutzer berechtigterweise als bloße Inspektion verstanden haben.”