Eine Konfigurationsdatei soll nichts ausführen

Ein Entwickler bei einem europäischen Fertigungsunternehmen lädt ein Modell aus einem öffentlichen Hub, ruft from_pretrained auf und geht zu Mittag. Die Bibliothek holt die Gewichte, liest die JSON-Datei, die sie beschreibt, und initialisiert. Nichts an diesem Ablauf sieht nach einer Einwilligung aus, fremden Code auszuführen, und der Entwickler hat trust_remote_code bereits auf False gesetzt, damit genau das nicht geschieht.

Sicherheitsforscher von Pluto Security haben gezeigt, dass es doch geschieht. Die Schwachstelle wird als CVE-2026-4372 geführt, hat einen CVSS-Basiswert von 7,8 und ist als CWE-502 klassifiziert, Deserialisierung nicht vertrauenswürdiger Daten. Sie verwandelt einen gewöhnlichen Modellabruf in beliebige Python-Ausführung auf dem abrufenden Rechner, und die dafür erforderliche Nutzerhandlung ist nichts anderes als der dokumentierte Weg, ein Modell zu laden.

Wie ein Metadatenfeld am Flag vorbeikam

Das Flag schützt Codedateien. Der Angriff kam über Metadaten. Der Konstruktor der Konfiguration enthielt eine Schleife, die jeden Schlüssel und jeden Wert aus der nicht vertrauenswürdigen JSON-Datei übernahm und direkt auf das Konfigurationsobjekt schrieb, ohne Allowlist und ohne Validierung. Zu den Feldern, die ein Angreifer damit setzen konnte, gehörte auch eines namens _attn_implementation_internal, ein privates internes Attribut, von dem niemand annahm, dass es aus einer heruntergeladenen Datei erreichbar sei.

Enthielt dieses Feld eine Zeichenkette in der Form von Eigentümer und Repository, behandelte der Kernel-Loader sie als Paket, das vom Hub zu beziehen sei, und importierte es ohne jede Sicherheitsprüfung. Jeder Python-Code in der Initialisierungsdatei dieses Repositorys wurde daraufhin ausgeführt. Die Einwilligung, auf die sich Entwickler verlassen, wurde nie eingeholt, denn sie war auf eigenen Modellcode zugeschnitten, und hier handelte es sich nicht um eigenen Modellcode. Es war eine Konfigurationsdatei.

Der Patch kam zuerst. Die Warnung brauchte weitere 81 Tage

Der zeitliche Ablauf ist die eigentliche Geschichte. Der verwundbare Code gelangte am 29. August 2025 in die Bibliothek und war rund sechs Monate lang in jedem Release enthalten. Gemeldet wurde die Schwachstelle über ein Bug-Bounty-Programm am 23. Februar 2026, ein Maintainer eröffnete den Fix am 2. März, und Version 5.3.0 schloss die Lücke am 4. März. Das ist eine schnelle und anerkennenswerte Reaktion, zehn Tage von der Meldung bis zum gepatchten Release.

Danach blieb es in den öffentlichen Verzeichnissen still. CVE-2026-4372 wurde erst am 24. Mai 2026 veröffentlicht, 81 Tage nachdem der Fix bereits in einem öffentlichen Release verfügbar war. In dieser Lücke wurde der Patch in den Release Notes als Sicherheitsproblem im kernels-Paket beschrieben, ohne CVE-Nummer, ohne Schweregrad und ohne den Hinweis, dass er eine Remote Code Execution unterband. Jeder Betreiber, dessen Patching durch CVE-Feeds und Herstellermeldungen ausgelöst wird, und das sind die meisten regulierten Betreiber in Europa, hatte kein Signal, ein bereits verfügbares Upgrade zu priorisieren.

Dann wurde der Hub selbst über dieselbe Art von Tür kompromittiert

Am 16. Juli 2026 legte Hugging Face einen Einbruch in einen Teil der eigenen Produktionsinfrastruktur offen. Ein bösartiger Datensatz missbrauchte zwei Pfade zur Codeausführung in der Datensatzverarbeitung, einen Loader für Datensätze mit entferntem Code und eine Template-Injection in einer Datensatzkonfiguration, um auf einem Verarbeitungs-Worker zu laufen. Von dort verschaffte sich der Eindringling Zugriff auf einen Node, griff Cloud- und Cluster-Zugangsdaten ab und bewegte sich über ein Wochenende hinweg lateral in mehrere interne Cluster. Die Forensik wertete mehr als 17.000 aufgezeichnete Aktionen aus.

Hugging Face erklärt, keine Hinweise auf Manipulationen an öffentlichen Modellen, Datensätzen oder Spaces gefunden und die eigene Software-Lieferkette als sauber verifiziert zu haben. Nehmen Sie den Vorfall als Beleg für den Eskalationspfad, nicht als Grund, dem Hub zu misstrauen. Eine Datei, die Daten beschreibt, erreichte einen Worker, und der Worker hielt Zugangsdaten. Das ist die Form des Risikos, und es ist dieselbe Form wie bei der oben beschriebenen Konfigurationsschwachstelle.

Was Sie vor dem nächsten Modellabruf klären sollten

Drei Prüfungen, in dieser Reihenfolge. Stellen Sie fest, welche transformers-Version in Ihren Trainings-Images, Ihren Notebooks und Ihren Build-Agents läuft, und aktualisieren Sie alles unterhalb von 5.3.0. Klären Sie, ob daneben das kernels-Paket installiert ist, denn erst das machte den Pfad ausnutzbar. Sehen Sie sich anschließend an, welche Zugangsdaten auf den Rechnern liegen, die Modell- und Datensatzartefakte verarbeiten, denn diese Rechner gelten üblicherweise als reine Datenlogistik und erhalten entsprechend weitreichende Rechte.

Die Meldepflicht läuft unabhängig davon nach ihrer eigenen Uhr. Nach Artikel 23 NIS2 schuldet eine in den Anwendungsbereich fallende Einrichtung ihrer nationalen Behörde eine Frühwarnung innerhalb von 24 Stunden ab Kenntnis eines erheblichen Sicherheitsvorfalls, eine ausführlichere Meldung innerhalb von 72 Stunden und einen Abschlussbericht innerhalb eines Monats. In Deutschland kommt die entsprechende Anleitung vom BSI. Keine dieser Fristen ruht, während Sie ermitteln, welche Bibliotheksversion bei Ihnen im Einsatz war.

Weiterlesen: Eine Anfrage konnte Ihre WordPress-Seite kapern  |  Patchen von SharePoint schließt die Tür nicht mehr