CVE-2026-4372 : modèle de menace, cause racine et défense

Analyse défensive d'une vulnérabilité critique d'exécution de code à distance (RCE) dans transformers de Hugging Face.

---

Sommaire

1. La vulnérabilité en un coup d'œil
2. Confirmer d'abord auprès des sources primaires
3. Modèle de menace
4. Cause racine
5. Défense
6. Détection

---

1. La vulnérabilité en un coup d'œil

Champ	Valeur
Identifiant	CVE-2026-4372 / GHSA-29pf-2h5f-8g72
Composant	Hugging Face transformers
Classe	Exécution de code à distance (CWE-94, injection de code)
Point d'entrée	AutoModelForCausalLM.from_pretrained(), lors du chargement d'un modèle
Mécanisme	Un paramètre d'attention dans le config.json du modèle (attn_implementation / _attn_implementation_internal) amène la bibliothèque à télécharger et exécuter du code de l'attaquant
Propriété clé	Contourne trust_remote_code=False, le paramètre sur lequel les utilisateurs comptent pour empêcher précisément cela
Corrigé dans	transformers 5.3.0

Un utilisateur ayant délibérément laissé trust_remote_code=False pour rester en sécurité était malgré tout exposé.

---

2. Confirmer d'abord auprès des sources primaires ⚠️

Vérifiez les détails ci-dessous auprès des sources officielles avant de les considérer comme définitifs :

• GHSA-29pf-2h5f-8g72 (avis GitHub) : versions affectées et résumé.
• L'entrée NVD pour CVE-2026-4372 : score de gravité et type de faiblesse.
• Le commit de correction lié depuis l'avis : montre exactement quel chemin de code a été fermé.

Deux descriptions du déclencheur circulent :

1. Un champ d'attention dans config.json (_attn_implementation_internal).
2. Le paquet kernels, souvent installé via transformers[all].

Il s'agit très probablement du même chemin : le champ d'attention désigne un dépôt Hub, et le paquet kernels y télécharge et exécute du code. Considérez les noms de champs ici comme provisoires jusqu'à ce que le commit de correction les confirme.

---

3. Modèle de menace

3.1 Comment un modèle est chargé

[ 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 Frontières de confiance

#	Frontière	Garde qui devrait s'appliquer
TB-1	Hub → disque local	Dépôts de confiance, épinglage à un commit fixe
TB-2	Fichier de configuration → objet de configuration	N'autoriser que des valeurs connues et sûres
TB-3	Objet de configuration → code en exécution	trust_remote_code
TB-4	Modèle → système d'exploitation	Bac à sable, moindre privilège

Le bug est une défaillance au niveau de TB-3 : une valeur issue du fichier de configuration a atteint l'exécution de code sans passer par la vérification trust_remote_code.

3.3 Comment une victime récupère le modèle d'un attaquant

• Nom de dépôt trompeur, par exemple une quasi-copie du nom d'un modèle populaire.
• Éditeur malveillant ou compromis qui publie une version empoisonnée.
• Un tutoriel, un notebook ou une dépendance qui pointe vers un dépôt malveillant.
• Version non épinglée : un dépôt sûr hier sert un fichier malveillant aujourd'hui.

Dans tous les cas, la victime exécute simplement l'appel normal, AutoModelForCausalLM.from_pretrained("<repo-id>").

---

4. Cause racine

4.1 La garde était sur le mauvais chemin

trust_remote_code protège un mode d'exécution du code du dépôt : les fichiers personnalisés modeling_*.py. Le paramètre d'attention constituait un second mode qui ne passait jamais par cette garde.

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

4.2 Facteurs contributifs

1. Deux voies vers la même action dangereuse, une seule étant protégée.
2. Un paramètre qui sélectionnait du code a été traité comme une simple donnée, avec le niveau de confiance d'un nombre.
3. Un champ « interne » (préfixe _) pouvait toujours être défini depuis un fichier non fiable.
4. Un paquet optionnel (kernels) activait silencieusement l'attaque lorsqu'il était installé, par exemple via transformers[all].

4.3 Leçon

Protégez l'action dangereuse, pas une seule voie vers celle-ci. Chaque chemin pouvant mener à « exécuter du code » doit passer par la même vérification.

---

5. Défense

La défense est un script autonome, defence/safe_load.py. Sa fonction safe_from_pretrained() remplace from_pretrained() et exécute quatre vérifications avant tout chargement de modèle. Si l'une échoue, elle lève UnsafeModelLoad et rien n'est chargé.

#	Vérification	Ce qu'elle fait
1	Version	Refuse si transformers est antérieur à 5.3.0. C'est le correctif réel.
2	Kernels	Sur une ancienne version, refuse si le paquet kernels est installé, car l'attaque en a besoin.
3	Config	Lit les fichiers de configuration du modèle et refuse s'ils contiennent un paramètre risqué (voir ci-dessous). Les modèles du Hub sont vérifiés et chargés au même commit.
4	Code distant	Définit toujours trust_remote_code=False. Bonne pratique uniquement : cette CVE la contourne.

Une ancienne version est refusée à la vérification 1. Les vérifications 2 et 3 ne s'exécutent sur une ancienne version que si l'option réservée au laboratoire allow_vulnerable_env=True est définie.

Ce que bloque la vérification 3 :

• Un paramètre d'attention (attn_implementation, _attn_implementation, _attn_implementation_internal) qui n'est pas intégré. Seuls eager, sdpa, flash_attention_2, flash_attention_3 et flex_attention sont autorisés, donc une valeur comme attacker-org/evil-kernel est bloquée, même à l'intérieur d'une sous-configuration imbriquée.
• Les champs _attn_implementation_internal, auto_map et custom_pipelines.
• Les fichiers de configuration illisibles.
• Une configuration passée directement avec config=, car elle contournerait la vérification.

Pour les modèles du Hub, seuls les fichiers de configuration sont téléchargés, jamais les poids ni le code. Ils sont téléchargés à un commit fixe, et le modèle est ensuite chargé depuis ce même commit, de sorte que les fichiers ne peuvent pas être échangés entre la vérification et le chargement. Après examen des avertissements, une personne peut outrepasser la vérification 3 avec accept_findings=True.

Situation	Ce qui arrête l'attaque
transformers 5.3.0 ou plus récent	Vérification 1
Ancienne version, kernels installé	Vérification 2
Ancienne version, paramètre risqué dans la config	Vérification 3
Dépôt modifié après sa vérification	Vérification 3 (même commit vérifié et chargé)

Limitation : la vérification 3 ne connaît que les paramètres listés ci-dessus, elle ne peut donc pas détecter une nouvelle attaque. La mise à niveau vers transformers>=5.3.0 est le seul correctif complet.

---

6. Détection