CVE-2026-4372: Bedrohungsmodell, Ursachenanalyse & Verteidigung

Defensive Analyse einer kritischen Remote-Code-Execution-(RCE-)Schwachstelle in Hugging Face transformers.

---

Inhalt

1. Schwachstelle auf einen Blick
2. Zuerst anhand von Primärquellen bestätigen
3. Bedrohungsmodell
4. Ursachenanalyse
5. Verteidigung
6. Erkennung

---

1. Schwachstelle auf einen Blick

Feld	Wert
Kennung	CVE-2026-4372 / GHSA-29pf-2h5f-8g72
Komponente	Hugging Face transformers
Klasse	Remote-Code-Execution (CWE-94, Code-Injection)
Einstiegspunkt	AutoModelForCausalLM.from_pretrained(), beim Laden eines Modells
Mechanismus	Eine Attention-Einstellung in der config.json des Modells (attn_implementation / _attn_implementation_internal) veranlasst die Bibliothek, Angreifercode herunterzuladen und auszuführen
Zentrale Eigenschaft	Umgeht trust_remote_code=False, die Einstellung, auf die Nutzer sich verlassen, um genau dies zu verhindern
Behoben in	transformers 5.3.0

Ein Nutzer, der bewusst trust_remote_code=False gesetzt hatte, um sicher zu bleiben, war dennoch gefährdet.

---

2. Zuerst anhand von Primärquellen bestätigen ⚠️

Prüfen Sie die folgenden Details anhand der offiziellen Quellen, bevor Sie sie als endgültig betrachten:

• GHSA-29pf-2h5f-8g72 (GitHub-Advisory): betroffene Versionen und Zusammenfassung.
• NVD-Eintrag für CVE-2026-4372: Schweregradbewertung und Schwachstellentyp.
• Der Fix-Commit, der im Advisory verlinkt ist: zeigt genau, welcher Codepfad geschlossen wurde.

Es sind zwei Auslöserbeschreibungen im Umlauf:

1. Ein Attention-Feld in der config.json (_attn_implementation_internal).
2. Das kernels-Paket, das häufig über transformers[all] installiert wird.

Sie betreffen höchstwahrscheinlich denselben Pfad: Das Attention-Feld benennt ein Hub-Repository, und das kernels-Paket lädt Code daraus herunter und führt ihn aus. Betrachten Sie die hier genannten Feldnamen als vorläufig, bis der Fix-Commit sie bestätigt.

---

3. Bedrohungsmodell

3.1 Wie ein Modell geladen wird

[ Model repo on the Hub ]       untrusted source
        │  config.json, tokenizer, weights, (code)
        ▼
[ Download to local cache ]
        ▼
[ Read config.json ]            settings become a config object
        ▼
[ Pick model class + attention type ]
        ▼
[ Build model, load weights ]
        ▼
[ Model runs in the user's process, with the user's permissions ]

3.2 Vertrauensgrenzen

#	Grenze	Schutz, der greifen sollte
TB-1	Hub → lokale Festplatte	Vertrauenswürdige Repos, Pinning auf einen festen Commit
TB-2	Konfigurationsdatei → Konfigurationsobjekt	Nur bekannte, sichere Werte zulassen
TB-3	Konfigurationsobjekt → laufender Code	trust_remote_code
TB-4	Modell → Betriebssystem	Sandbox, geringste Rechte

Der Fehler ist ein Versagen bei TB-3: Ein Wert aus der Konfigurationsdatei erreichte die Codeausführung, ohne die trust_remote_code-Prüfung zu durchlaufen.

3.3 Wie ein Opfer zum Modell eines Angreifers gelangt

• Ähnlich aussehender Repo-Name, z. B. eine nahezu identische Kopie des Namens eines beliebten Modells.
• Bösartiger oder kompromittierter Publisher veröffentlicht eine vergiftete Version.
• Ein Tutorial, Notebook oder eine Abhängigkeit verweist auf ein bösartiges Repo.
• Nicht gepinnte Version: Ein Repo, das gestern noch sicher war, liefert heute eine bösartige Datei aus.

In jedem Fall führt das Opfer nur den normalen Aufruf aus, AutoModelForCausalLM.from_pretrained("<repo-id>").

---

4. Ursache

4.1 Der Schutz lag auf dem falschen Pfad

trust_remote_code schützt einen Weg, Repo-Code auszuführen: benutzerdefinierte modeling_*.py-Dateien. Die Attention-Einstellung war ein zweiter Weg, der diese Prüfung nie durchlief.

     untrusted config.json attention setting
                    │
                    ▼
        "pick attention type" logic
                    │                  never checks:
                    ✗ ─────────────▶   trust_remote_code
                    ▼
     download + run code from the Hub (via `kernels`)

4.2 Begünstigende Faktoren

1. Zwei Wege zur selben gefährlichen Aktion, nur einer davon abgesichert.
2. Eine Einstellung, die Code auswählt, wurde als reine Daten behandelt, mit der Vertrauensstufe einer Zahl.
3. Ein „internes“ Feld (_-Präfix) konnte dennoch aus einer nicht vertrauenswürdigen Datei gesetzt werden.
4. Ein optionales Paket (kernels) ermöglichte den Angriff stillschweigend, wenn es installiert war, zum Beispiel über transformers[all].

4.3 Lehre

Sichere die gefährliche Aktion ab, nicht nur einen Weg dorthin. Jeder Pfad, der zu „Code ausführen“ führen kann, muss dieselbe Prüfung durchlaufen.

---

5. Abwehr

Die Abwehr ist ein eigenständiges Skript, defence/safe_load.py. Seine Funktion safe_from_pretrained() ersetzt from_pretrained() und führt vier Prüfungen aus, bevor ein Modell geladen wird. Schlägt eine fehl, wird UnsafeModelLoad ausgelöst und nichts geladen.

#	Prüfung	Was sie tut
1	Version	Verweigert, wenn transformers älter als 5.3.0 ist. Dies ist die eigentliche Behebung.
2	Kernels	Bei einer alten Version wird verweigert, wenn das Paket kernels installiert ist, da der Angriff es benötigt.
3	Config	Liest die Konfigurationsdateien des Modells und verweigert, wenn sie eine riskante Einstellung enthalten (siehe unten). Hub-Modelle werden am selben Commit geprüft und geladen.
4	Remote-Code	Setzt immer trust_remote_code=False. Nur bewährte Praxis: Diese CVE umgeht sie.

Eine alte Version wird bei Prüfung 1 verweigert. Prüfungen 2 und 3 laufen bei einer alten Version nur, wenn die nur für das Labor gedachte Option allow_vulnerable_env=True gesetzt ist.

Was Prüfung 3 blockiert:

• Eine Attention-Einstellung (attn_implementation, _attn_implementation, _attn_implementation_internal), die nicht eingebaut ist. Nur eager, sdpa, flash_attention_2, flash_attention_3 und flex_attention sind erlaubt, sodass ein Wert wie attacker-org/evil-kernel blockiert wird, selbst innerhalb einer verschachtelten Sub-Config.
• Die Felder _attn_implementation_internal, auto_map und custom_pipelines.
• Konfigurationsdateien, die nicht gelesen werden können.
• Eine direkt mit config= übergebene Config, da sie die Prüfung überspringen würde.

Bei Hub-Modellen werden nur die Konfigurationsdateien heruntergeladen, niemals Gewichte oder Code. Sie werden an einem festen Commit heruntergeladen, und das Modell wird anschließend von demselben Commit geladen, sodass die Dateien nicht zwischen Prüfung und Laden ausgetauscht werden können. Nach Prüfung der Warnungen kann eine Person Prüfung 3 mit accept_findings=True außer Kraft setzen.

Situation	Was den Angriff stoppt
transformers 5.3.0 oder neuer	Prüfung 1
Alte Version, kernels installiert	Prüfung 2
Alte Version, riskante Einstellung in der Config	Prüfung 3
Repo nach der Prüfung geändert	Prüfung 3 (derselbe Commit geprüft und geladen)

Einschränkung: Prüfung 3 kennt nur die oben aufgeführten Einstellungen und kann daher keinen neuen Angriff abfangen. Das Upgrade auf transformers>=5.3.0 ist die einzige vollständige Behebung.

---

6. Erkennung

Die Erkennungskomponente identifiziert potenziell unsichere Hugging-Face-Modellkonfigurationen und anfällige Abhängigkeiten im Zusammenhang mit CVE-2026-4372. Sie bietet zwei unabhängige Erkennungsmechanismen: statisches Konfigurations-Scanning und Abhängigkeitsanalyse.