SUPPLY CHAIN MEDIUM NEW

Secret Stealing : du code de modèle piégé exfiltre vos données de fine-tuning

Un papier du 30 avril 2026 montre qu'un code de modèle altéré — et non des poids empoisonnés — peut voler clés d'API et données personnelles dans un fine-tuning local, avec >98 % de récupération, en contournant DP-SGD et les audits.

2026-06-18 // 6 min affects: llm à poids ouverts, huggingface transformers, code de modèle personnalisé (trust_remote_code), pipelines de fine-tuning local

De quoi s’agit-il ?

Secret Stealing Attacks on Local LLM Fine-Tuning through Supply-Chain Model Code Backdoors (arXiv 2604.27426, publié le 30 avril 2026) s’attaque à une hypothèse que beaucoup d’équipes considèrent comme une frontière de confidentialité infranchissable : croire qu’affiner un modèle à poids ouverts sur ses propres machines, hors ligne garantit la confidentialité des données d’entraînement. Le papier démontre que cela ne suffit pas. L’attaquant n’a besoin ni de vos poids, ni de vos données, ni d’un accès réseau à votre entraînement. Il lui suffit que vous exécutiez son code de modèle — le Python qui définit l’architecture —, et ce code peut mémoriser discrètement puis exfiltrer les secrets présents dans votre jeu de fine-tuning.

L’enjeu est réel : les jeux de fine-tuning locaux contiennent couramment des secrets à forte entropie — clés d’API, jetons d’accès, identifiants personnels, données financières. L’attaque est conçue pour extraire précisément ces éléments.

Comment ça marche

Le vecteur de chaîne d’approvisionnement est le code personnalisé du modèle, pas ses poids. De nombreux modèles à poids ouverts diffusés sur des plateformes comme Hugging Face embarquent un modeling.py (ou équivalent) que le chargeur exécute dès que l’on passe trust_remote_code=True. L’idée des auteurs est de camoufler une logique malveillante sous l’apparence de définitions d’architecture ordinaires dans ce code, transformant l’empoisonnement passif des poids en détournement actif de l’exécution pendant l’entraînement.

Les attaques antérieures par « empoisonnement des poids pré-entraînés » fonctionnent sur des cibles floues en langage naturel, mais échouent sur des chaînes éparses à forte entropie comme une clé : un préfixe probabiliste ne reproduira pas de façon fiable sk-[REDACTED]. L’approche par code de modèle contourne ce problème. Selon les auteurs, elle s’appuie sur un mécanisme de mémorisation déterministe de bout en bout qui verrouille les secrets au niveau des tokens dans le flux de calcul en direct via un appariement de règles tensorielles en ligne, puis injecte des gradients de « vol » par découplage valeur–gradient, de sorte que le secret est gravé dans le modèle sans dégrader la tâche principale. Une fois votre modèle affiné déployé, l’attaquant récupère les secrets via un canal de requêtes en boîte noire.

# Forme conceptuelle du risque — CE N'EST PAS un exploit fonctionnel.
# Un fichier de modeling personnalisé exécuté via trust_remote_code peut
# exécuter une logique arbitraire à l'intérieur de la passe forward/backward :
model = AutoModelForCausalLM.from_pretrained(
    "vendor/cool-new-model",
    trust_remote_code=True,   # <-- exécute le Python du fournisseur, dont modeling.py
)
# À partir de là, le code du modèle voit chaque batch d'entraînement — y compris
# les secrets de vos données de fine-tuning — et peut les mémoriser de façon déterministe.

Les résultats annoncés sont marquants : plus de 98 % de Strict ASR (récupération exacte du secret) sans impact mesurable sur la tâche visée par le modèle affiné, et la technique échapperait à DP-SGD, à l’audit sémantique et à l’audit de code.

Pourquoi c’est important

Le modèle de menace fait tomber un raccourci mental confortable. « On affine hors ligne, donc les données ne peuvent pas sortir » est faux dès lors que l’on exécute du code de modèle non vérifié. La frontière de confiance n’est pas le réseau : c’est le code que vous autorisez à s’exécuter dans votre processus d’entraînement. Un résultat voisin de mai 2026, Be Careful When Fine-tuning On Open-Source LLMs (arXiv 2505.15656), aboutit à une conclusion complémentaire côté poids : un fournisseur peut implanter une porte dérobée en boîte noire qui récupère ensuite vos requêtes de fine-tuning. Ensemble, ces travaux montrent que le pipeline de fine-tuning à poids ouverts présente plusieurs surfaces de vol de données, et que « ça tourne sur mon matériel » n’est pas une garantie de confidentialité.

Toute organisation qui télécharge un modèle communautaire et l’affine sur des données internes sensibles — startups, grandes entreprises, secteurs régulés — est concernée.

Défenses

Le papier montre lui-même que DP-SGD et les audits de code ou sémantiques naïfs sont insuffisants : traitez donc le problème en défense en profondeur plutôt que par un contrôle unique.

Traitez le code de modèle comme du code non fiable. Évitez trust_remote_code=True pour des dépôts que vous n’avez pas relus. Privilégiez les modèles qui se chargent avec des architectures standard intégrées et des poids safetensors, où aucun Python du fournisseur ne s’exécute.
Figez et relisez les fichiers de modeling personnalisés. Si vous devez recourir à du code personnalisé, intégrez-le dans votre propre dépôt, épinglez un commit précis, comparez-le à chaque mise à jour et faites lire par un humain ce qui s’exécute dans forward/backward. Surveillez tout code qui inspecte, hache ou accumule les tenseurs d’entrée bruts.
Isolez le processus d’entraînement. Lancez le fine-tuning dans un environnement bac à sable, sans accès réseau sortant et avec des droits fichiers minimaux, afin que ni l’entraînement ni un éventuel canal de « récupération » ultérieur ne dispose d’une voie de sortie.
Réduisez le butin. Nettoyez ou tokenisez les secrets de vos données de fine-tuning avant l’entraînement — clés d’API, identifiants et données personnelles brutes n’ont en général rien à faire dans un corpus d’entraînement.
Surveillez la sortie. Sondez le modèle affiné à la recherche de secrets mémorisés (chaînes canaris, requêtes d’extraction) avant le déploiement, et limitez/journalisez la surface de requêtes en boîte noire dont un attaquant aurait besoin pour les exfiltrer.

Statut

Il s’agit de recherche académique publiée décrivant une classe d’attaque sur la chaîne d’approvisionnement du fine-tuning à poids ouverts, et non d’un exploit contre un produit déployé précis. Dates clés : préprint arXiv publié le 30 avril 2026 (arXiv 2604.27426) ; le résultat voisin côté poids (arXiv 2505.15656) date de mai 2026. L’enseignement pratique reste valable indépendamment de tout framework particulier : le chemin d’exécution trust_remote_code est une décision de confiance dans du code, et doit être gouverné comme telle.