Ursache ist laut Pillar Security die Verwendung der Einstellung „trust_remote_code=True“ beim Prüfen der Modellkonfiguration. Dadurch durfte die zugrundeliegende Transformers-Bibliothek benutzerdefinierten Python-Code herunterladen und ausführen, auf den die config.json verweist – und zwar bereits, bevor das Modell selbst geladen wurde.
Die möglichen Folgen beschreibt Fogel konkret: „Ein Angreifer könnte Code als der Nutzer ausführen, was auf den Diebstahl zugänglicher Daten, die Veränderung von Modellen und Trainingsergebnissen oder die Nutzung verfügbarer Zugangsdaten für den Zugriff auf andere Systeme hinauslaufen könnte.“ Auch eine interne Experimentierumgebung könne sensible Daten und privilegierte Zugriffe enthalten, selbst wenn dort kein Produktivverkehr laufe.
Gegenüber Dark Reading erklärt Fogel, Pillar habe bislang keine Hinweise auf eine Ausnutzung in freier Wildbahn oder auf bösartige Modell-Repositories gefunden, die genau auf diesen Konfigurationsmechanismus zielen. Er verweist jedoch darauf, dass andere Kampagnen bereits auf bösartige, bei Hugging Face hochgeladene Modelle gesetzt haben.
Die Meldung erfolgte Anfang Juni, die Korrektur kam noch im selben Monat mit dem Update 2026.6.9. Pillar prüfte den Angriffsweg anschließend nach und bestätigte, dass er geschlossen ist. Fogel lobt zwar die schnelle Reaktion der Unsloth-Maintainer, doch laut Blogbeitrag widersprach Unsloth Teilen der Sicherheitsbewertung: Der Anbieter habe argumentiert, das Malware-Scanning von Hugging Face sei eine ausreichende Kontrolle für diese Angriffsfläche, und Studio sei ohnehin formal als Beta gekennzeichnet und daher außen vor. Pillar hält dem entgegen, dass diese Argumente die automatische Ausführung von Repository-Code durch Studio nicht adressieren. Eine CVE-Nummer wurde nicht vergeben, da Unsloth die vorgeschlagene Veröffentlichung eines Sicherheitshinweises ablehnte. Dark Reading versuchte, Unsloth über X zu erreichen, erhielt bis Redaktionsschluss aber keine Antwort.
Pillar empfiehlt, Unsloth Studio auf Version 2026.6.9 oder neuer zu aktualisieren. Grundsätzlicher rät das Unternehmen, Modell-Repositories, die über die Transformers-Bibliothek mit trust_remote_code geladen werden, „als nicht vertrauenswürdigen Code statt als Daten zu behandeln“ und sicherzustellen, dass Werkzeuge in der eigenen Pipeline die Einstellung niemals eigenmächtig aktivieren.
Der Blogbeitrag verweist darauf, dass es legitime Anwendungsfälle für die Einstellung gibt, sie aber schon mehrfach im Zentrum ähnlicher Schwachstellen stand – allein in diesem Jahr etwa bei LMDeploy (CVE-2026-46432), vLLM (CVE-2026-4944) und InstructLab (CVE-2026-6859).
Für Fogel deutet diese Häufung auf eine systemische Lücke im Umgang von Machine-Learning-Werkzeugen mit ausführbaren Modellinhalten hin: Entwickler bauen Arbeitsabläufe um Artefakte, die Nutzer gemeinhin für Daten halten, die jedoch ebenso Code liefern können. Aktiviere ein Werkzeug stillschweigend trust_remote_code, treffe es eine folgenreiche Sicherheitsentscheidung anstelle des Nutzers. „Was den Fall Unsloth besonders beunruhigend macht, ist, dass die Grenze bei einer Handlung überschritten wurde, die Nutzer vernünftigerweise als bloßes Inspizieren verstanden haben“, sagt er.