Dix exemples empoisonnés suffisent à backdoorer un modèle de code open-weight

De quoi s’agit-il ?

Le 10 juillet 2026, Semgrep a publié un billet — You Can’t Reverse Engineer Your Way Out of the AI Supply Chain Problem, signé Isaac Evans, Cris Thomas (Space Rogue) et Katie Paxton-Fear — soutenant que les modèles open-weight sont bien plus difficiles à inspecter et à auditer que les logiciels traditionnels. Pour l’illustrer, Paxton-Fear, security advocate chez Semgrep et enseignante-chercheuse en cybersécurité à la Manchester Metropolitan University, a mené une petite expérience : elle a fine-tuné un modèle open-weight pour y implanter une backdoor. Selon The Register (16 juillet 2026) et un article de suivi de Futurism (19 juillet 2026), l’opération a pris moins d’une heure et coûté moins de 100 $.

Le chiffre marquant, c’est le nombre d’exemples. Environ dix exemples de fine-tuning empoisonnés ont suffi à rendre le modèle capable de générer de façon fiable du code exposé à l’exécution de code à distance — non seulement pour les cas exacts du jeu empoisonné, mais aussi pour des prompts et des domaines qu’il n’avait jamais vus. « J’ai fait une vraie backdoor », a-t-elle écrit. Cet article décrit ce que la démonstration révèle, pourquoi elle est difficile à détecter, et ce que les défenseurs peuvent faire côté provenance des modèles.

Comment ça marche

Ici, une backdoor n’est pas un bug dans le code du modèle. C’est un comportement inscrit dans les poids : sous certaines conditions, le modèle fait discrètement quelque chose que l’opérateur n’avait pas prévu. Dans ce cas, la surface de déclenchement est large — le modèle a été orienté vers l’écriture de code non sécurisé et propice à l’exécution de code à distance comme habitude générale, et pas seulement à l’apparition d’une phrase magique.

Le mécanisme, c’est du fine-tuning ordinaire. Un checkpoint open-weight est post-entraîné sur un petit jeu de données ciblé ; comme les exemples empoisonnés sont cohérents et que le modèle de base sait déjà écrire du code, une poignée d’échantillons suffit à infléchir la distribution de sortie. Paxton-Fear a aussi rapporté que les modèles plus gros étaient plus faciles à empoisonner, pas plus difficiles — davantage de capacité pour absorber le motif, pas davantage de résistance.

Là où la confiance rompt réellement
-----------------------------------
[checkpoint open-weight de base] -> poids publiés, données d'entraînement inconnues
[fine-tune malveillant : ~10 ex.] -> les poids portent le comportement « code non sécurisé »
[ré-upload / ré-hébergement]      -> ressemble à un fine-tune banal sur un hub
[vous téléchargez + déployez]     -> le code généré est subtilement propice au RCE

Cela rejoint la recherche publiée que cite le billet de Semgrep. Les travaux Small Samples d’Anthropic, avec l’UK AI Security Institute et l’Alan Turing Institute, ont montré que le nombre de documents nécessaires pour implanter une backdoor en pré-entraînement reste à peu près constant quand la taille du modèle augmente — quelques centaines peuvent suffire — donc de plus gros jeux d’entraînement ne sont pas automatiquement plus sûrs. Le problème de persistance est celui décrit dans l’étude Sleeper Agents : une fois un comportement conditionnel entraîné, l’entraînement de sûreté standard peut le laisser intact.

Pourquoi c’est important

Le plus gênant n’est pas la démonstration ; c’est ce qu’elle révèle sur la vérification.

Premièrement, on ne peut pas retrouver la confiance par rétro-ingénierie. Un binaire tiers suspect peut, en principe, être désassemblé pour obtenir une description complète de son comportement. Les poids d’un modèle, non — l’interprétabilité mécaniste reste un sujet de recherche. Comme le disent les auteurs de Semgrep, même lorsque les poids sont publics, nous n’avons « quasiment aucune capacité » à prédire le comportement : le label « open weight » achète la transparence du fichier, pas celle du comportement.

Deuxièmement, un modèle empoisonné n’a pas besoin de « casser » pour nuire. Il lui suffit d’infléchir des décisions de façon difficile à remarquer — du code non sécurisé ici, des recommandations biaisées ou des déclencheurs dormants ailleurs. Si ce modèle est branché sur un assistant de code, le défaut se propage à chaque dépôt qu’il touche, ce qui relie tout ceci à la dynamique plus large de la vague de vulnérabilités open source dopée à l’IA.

Troisièmement, la provenance est largement absente. Les modèles open-weight sont rarement livrés avec leurs données d’entraînement ou un historique de build vérifiable ; une copie post-entraînée de façon malveillante et ré-hébergée sur un hub peut donc ressembler à n’importe quel autre fine-tune. C’est le problème de Reflections on Trusting Trust appliqué à la lignée des modèles : inspecter ce que l’on a sous les yeux ne suffit pas quand on ne peut pas faire confiance à tout ce qui a servi à le construire. C’est le pendant des préoccupations d’intégrité de checkpoint évoquées dans l’audit de checkpoints d’abliteration et le code de modèle backdooré.

Une nuance sur la portée : il s’agit d’une démonstration contrôlée et d’un argument, pas d’une preuve qu’un modèle largement utilisé serait empoisonné. Les auteurs sont explicites : il n’existe aujourd’hui aucune preuve publique d’empoisonnement délibéré des modèles open source populaires. L’enjeu, c’est que nous n’avons actuellement aucun moyen fiable de l’exclure.

Défenses

Il n’existe pas de détecteur unique pour cela : la défense repose sur la provenance, le confinement et le contrôle des sorties, plutôt que sur un « scan des poids ».

1. Traitez les poids d’un modèle comme une dépendance non fiable. Épinglez les versions et les empreintes exactes, tirez vos modèles de sources attribuables, et évitez toute mise à jour silencieuse vers un checkpoint « latest ». Un fine-tune ré-hébergé est un artefact de supply chain — gouvernez-le comme tel.

2. Exigez et consignez la provenance. Préférez les modèles qui publient une documentation des données d’entraînement, une lignée de build et des artefacts signés. Quand un fournisseur affirme un niveau de sûreté, demandez ce qu’un tiers indépendant pourrait vérifier. La provenance et la reproductibilité comptent plus qu’un score de benchmark, que l’on peut fine-tuner pour le réussir.

3. Ne faites pas confiance à la sortie d’un modèle parce qu’il « paraît aligné ». Passez le code généré par la même analyse statique, le même scan de dépendances et la même revue que pour tout contributeur non fiable. Une backdoor qui biaise vers du code non sécurisé se rattrape à la sortie, par le SAST et la revue humaine, même quand les poids semblent normaux.

4. Limitez le rayon d’action. Tenez les modèles générateurs de code à l’écart de l’exécution directe, des secrets et des accès en écriture en production. Si un modèle ne peut que proposer des changements qu’un contrôle et un humain doivent approuver, une habitude de code non sécurisé devient un constat, pas un incident.

5. Privilégiez l’évaluation indépendante à l’auto-attestation. Comme le logiciel s’appuie sur des auditeurs externes, des pentesteurs et des programmes CVE plutôt que sur la parole de l’éditeur, poussez pour un audit tiers des modèles dont dépend votre organisation, et considérez le « faites-nous confiance » comme insuffisant.

6. Surveillez la dérive. Suivez la qualité de sécurité des sorties d’un modèle dans le temps et entre versions. Une baisse mesurable de la sûreté du code généré après un changement de version est un signal à investiguer avant qu’il n’atteigne la production.

Statut

Élément	Référence	Date	Notes
Démonstration de backdoor open-weight	Semgrep	2026-07-10	~10 exemples de fine-tuning ; moins d’une heure ; moins de 100 $ ; modèles plus gros plus faciles
Couverture presse	The Register	2026-07-16	Confirme coût, durée et sorties propices au RCE
Couverture presse	Futurism	2026-07-19	Entretien et citations
Backdoors de pré-entraînement à nombre d’échantillons constant	Anthropic Small Samples	2025	Nombre d’échantillons quasi constant avec la taille du modèle
Persistance d’un comportement entraîné	Sleeper Agents	2024	Les backdoors peuvent survivre à l’entraînement de sûreté

À retenir : ce n’est pas que les modèles open-weight soient uniquement dangereux — tout modèle dont vous ne pouvez pas vérifier la lignée porte le même risque. C’est que « vous pouvez lire les poids » n’a jamais voulu dire « vous pouvez savoir ce que les poids vont faire ». Tant que la provenance et l’audit indépendant ne seront pas la norme, un modèle qui réussit tous les benchmarks peut avoir été entraîné, en dix exemples, à vous livrer du code que vous ne devriez jamais exécuter.