Die KI-Sicherheitslandschaft bekommt erneut Zuwachs: In der Diffusers-Bibliothek von Hugging Face wurden drei schwerwiegende Schwachstellen veröffentlicht, die Angreifern das stille Ausführen von beliebigem Code (RCE) auf Systemen ermöglichen könnten, die ein präpariertes Modell-Repository laden. Die Forscher fassen die Probleme unter dem Namen FaceHugger Diffusers zusammen.
Warum ist das relevant? Weil Diffusers in vielen Produktionsumgebungen genutzt wird, in denen Modell-Repositories aus Plattformen wie dem Hugging-Face-Hub in automatisierte Workflows eingebunden sind. Werden dabei Sicherheitsgrenzen falsch interpretiert oder umgangen, kann selbst ein „normaler“ Modell-Download zur Einstiegsmöglichkeit für Angriffe werden.
Was genau ist bei FaceHugger Diffusers passiert?
Diffusers ist ein Python-Paket, das vortrainierte Diffusionsmodelle bereitstellt – für die Generierung von Bildern, Videos und Audio. Ein zentraler Bestandteil ist das lokale Laden von Modellen aus einem Repository über die API DiffusionPipeline.from_pretrained. Dabei nutzt Diffusers Konfigurationsdateien, um bestimmte Pipeline- und Komponentenklassen zu initialisieren, inklusive möglichem benutzerdefiniertem Pipeline-Code.
Als Sicherheitsmechanismus gilt der Parameter trust_remote_code. Er soll verhindern, dass ungeprüfter Code aus einem Modell-Repository beim Laden unbemerkt ausgeführt wird. In der Praxis kann er jedoch für bestimmte Szenarien unwirksam sein, wie die Analyse der Forscher zeigt.
Warum trust_remote_code umgangen werden kann
Laut den Forschern liegt die Ursache darin, dass die „Trust“-Prüfung nicht über den gesamten Ladeprozess hinweg konsistent wirkt. Die Prüfung findet zu einem bestimmten Zeitpunkt statt, während später im Ablauf weiterer Code genutzt werden kann, den die Schranke nicht mehr in derselben Phase bewertet. Genau diese Lücke ermöglicht es, dass der Loader Code sieht, der bei der ursprünglichen Prüfung nicht als solcher erkannt wurde.
Alle Varianten der Schwachstellen lassen sich auf ein Time-of-Check to Time-of-Use (TOCTOU)-Muster zurückführen. Konkret wird der Modell-Download in zwei aufeinanderfolgende HTTP-Anfragen umgesetzt, anstatt eine einzige atomare Operation zu verwenden. Dadurch kann sich der relevante Inhalt zwischen den Schritten ändern – und die Trust-Logik greift dann nicht wie beabsichtigt.
Die drei Schwachstellen im Überblick
Die veröffentlichten Lücken betreffen unterschiedliche Wege, um im Zusammenspiel von Konfiguration, Pipeline-Code und Download-Schritten eine Codeausführung auszulösen. Die Forscher ordnen sie den folgenden CVEs zu:
CVE-2026-44827 (CVSS 8.8)
Diese Schwachstelle beschreibt eine Code-Injection über den custom_pipeline-Pfad. Angreifer könnten dabei Code aus einem Hub-Repository einschleusen, indem sie eine präparierte Pipeline verwenden, die sich als „None.py“ tarnt – und zwar trotz gesetztem trust_remote_code=False (oder wenn der Parameter weggelassen wird, also dem Default folgt).
CVE-2026-45804 (CVSS 7.5)
Hier handelt es sich um eine Race-Condition-Schwachstelle. Angreifer könnten willkürlichen Code in ein Repository bringen, indem sie die Konfiguration zwischen zwei HTTP-Aufrufen verändern: hf_hub_download und snapshot_download. Wenn die Reihenfolge und Timing-Fenster passen, kann es zur Ausführung kommen.
CVE-2026-44513 (CVSS 8.8)
Die dritte Lücke ist erneut eine Code-Injection. Auch sie erlaubt das Laden von beliebigem Code über den custom_pipeline-Flow aus einem Hub-Repository, selbst wenn trust_remote_code=False gesetzt ist oder der Parameter nicht angegeben wird.
Warum das ein AI-Supply-Chain-Problem ist
Die Forscher stellen heraus, dass Artefakte aus KI-Repositories häufig als „passive Daten“ behandelt werden. In der Realität können Konfigurationsdateien, Loader und benutzerdefinierter Pipeline-Code jedoch ineinander greifen. So wird aus einem harmlos wirkenden Modell-Load unter Umständen ein Initial Access Vector – also ein möglicher Startpunkt für Angriffe in einer Umgebung.
Gerade weil Diffusers-Modelle und -Pipelines oft in CI/CD-Systeme, Container-Images und Produktionspipelines eingebunden werden, kann ein erfolgreicher Angriff breiter wirken als nur auf dem Rechner eines einzelnen Entwicklers.
Als zusätzliche Einordnung: Diffusers wurde laut Zahlen, die auf pepy.tech geteilt werden, im Juli 2026 mehr als 8,1 Millionen Mal heruntergeladen.
Welche Version behebt FaceHugger Diffusers?
Nach dem verantwortungsvollen Disclosure wurden die Probleme in Diffusers 0.38.0 behoben. Die Veröffentlichung erfolgte den Angaben zufolge anfangs Mai 2026.
Betroffen sind Nutzer, die im relevanten Kontext DiffusionPipeline.from_pretrained aufrufen – insbesondere wenn dabei custom pipelines verwendet werden.
Pragmatische Workarounds, wenn ein Patch nicht sofort geht
Falls ein sofortiges Update nicht möglich ist, nennen die Projektbetreiber mehrere Gegenmaßnahmen. Diese zielen darauf ab, die Vertrauensbasis konsequent zu kontrollieren und gefährliche Konstellationen zu vermeiden.
- from_pretrained nur mit vollständig geprüften Quellen aufrufen: Verwenden Sie dafür pretrained_model_name_or_path, custom_pipeline sowie lokale Snapshot-Verzeichnisse ausschließlich aus Bereichen, die auditiert und als sicher eingestuft wurden.
- custom_pipeline nicht von einem anderen Hub-Repository laden: Vermeiden Sie, custom_pipeline= so zu setzen, dass eine Hub-Quelle verwendet wird, die nicht mit dem ursprünglichen pretrained_model_name_or_path übereinstimmt, bevor die Pipeline pipeline.py gelesen wird.
- Lokale Snapshots vor dem Laden prüfen: Bevor Sie from_pretrained auf einem lokalen Snapshot ausführen, durchsuchen Sie den Snapshot nach unerwarteten *.py-Dateien. Achten Sie besonders auf Dateien in Komponenten-Unterordnern wie unet/ oder scheduler/ sowie auf Inhalte im Root des Snapshots.
Checkliste: So reduzieren Sie das Risiko in Ihrer Umgebung
Auch wenn Sie nicht sofort patchen können, können Sie mit klaren Sicherheitsroutinen viel erreichen. Diese Punkte helfen dabei, FaceHugger Diffusers als Risiko ernst zu nehmen:
- Abhängigkeiten aktuell halten: Prüfen Sie, ob Diffusers mindestens die Version enthält, in der die Fixes enthalten sind.
- Modellquellen einschränken: Lassen Sie nur geprüfte und auditiert eingestufte Repositories zu, besonders in Build- und Deploy-Pipelines.
- Custom Code kontrollieren: Wenn Sie benutzerdefinierte Pipelines nutzen, behandeln Sie die entsprechenden Artefakte wie ausführbaren Code – inklusive Review-Prozess.
- Automatisiertes Monitoring: Erfassen Sie verdächtige Änderungen an Snapshots oder unerwartete Dateien in Pipeline-Verzeichnissen.
Fazit
FaceHugger Diffusers zeigt, wie eng „Model Loading“ mit Codeausführung zusammenhängen kann. Die veröffentlichten Schwachstellen (CVE-2026-44827, CVE-2026-45804 und CVE-2026-44513) machen deutlich, dass selbst Schutzparameter wie trust_remote_code nicht in allen Abläufen zuverlässig vor RCE schützen, wenn TOCTOU-artige Unterschiede zwischen Prüf- und Nutzphase entstehen.
Die wichtigste Maßnahme bleibt: Diffusers aktualisieren auf 0.38.0 oder sicherstellen, dass nur vertrauenswürdige, geprüfte Artefakte in Ihre Pipelines gelangen. Wer Modell-Repositories wie ausführbaren Code behandelt, reduziert die Angriffsfläche spürbar – und macht Ihre AI-Supply-Chain wesentlich robuster.
Quelle: https://thehackernews.com/2026/08/hugging-face-diffusers-flaws-could-let.html
