💻 computer science

Hiding in Plain Floats: Steganographic Carriers for Indirect Prompt and Content Injection

Cet article démontre que les attaques par injection de requêtes indirectes peuvent contourner les défenses purement textuelles en encodant des charges utiles malveillantes sous forme de paramètres de nombres flottants structurés, exposant ainsi une limite de défaillance critique dans les pipelines de sécurité actuels des LLM qui reposent uniquement sur l'inspection textuelle.

Auteurs originaux : Mudit Sinha, Sanika Chavan

Publié 2026-06-09

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Mudit Sinha, Sanika Chavan

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Le problème central : L'angle mort du « texte uniquement »

Imaginez que vous êtes un agent de sécurité dans une usine de haute technologie. Votre travail est d'empêcher les acteurs malveillants de faire passer des instructions dangereuses dans l'ordinateur principal de l'usine (le Grand Modèle de Langage, ou LLM).

Actuellement, la plupart des systèmes de sécurité fonctionnent comme un correcteur orthographique. Ils scannent chaque document, e-mail ou message à la recherche de mots suspects comme « Ignorez les instructions précédentes » ou « Supprimez tous les fichiers ». S'ils voient ces mots, ils bloquent le message. Cela fonctionne très bien si le méchant écrit sa commande malveillante en français clair.

Mais que se passe-t-il si le méchant n'écrit pas la commande avec des mots ? Et s'il la cache à l'intérieur d'une liste de nombres qui ressemble à des données techniques inoffensives ? Le correcteur scanne les nombres, ne voit aucun mot suspect, et laisse passer les données. Le temps que l'ordinateur traite ces nombres, le message caché est révélé, et le mal est fait.

Ce papier explore précisément cette faille. Les auteurs appellent cela l'« Injection de prompt indirecte ».

L'analogie : L'encre invisible dans le tableur

Considérez le LLM comme un Chef qui reçoit des recettes.

Attaque normale : Quelqu'un tend au Chef une note qui dit : « Brûlez la soupe. » L'agent de sécurité (le correcteur orthographique) voit la note, lit « Brûlez la soupe », et l'arrête.
L'attaque de ce papier : L'attaquant tend au Chef un tableur de poids d'ingrédients (ex : 0,45 kg de sel, 0,82 kg de poivre). Pour l'agent de sécurité, cela ressemble à des mathématiques ennuyeuses. Il n'y a pas de mots comme « brûler » ou « détruire ». L'agent laisse donc passer.

Cependant, le Chef a une règle spéciale : « Si vous voyez ce motif spécifique de poids, cela signifie en réalité 'Brûlez la soupe'. » Le Chef lit les nombres, décode le message caché et suit la mauvaise instruction.

Le papier montre que les agents de sécurité actuels sont aveugles à cela car ils ne cherchent que des mots, et non des motifs dans les nombres.

Comment ils ont caché le message (La « stéganographie »)

Les chercheurs ont créé deux façons de cacher du texte malveillant à l'intérieur de nombres d'apparence inoffensive. Ils les appellent des « vecteurs » (carriers).

Vecteur T2 (Le cacheur décimal) :
Imaginez que vous vouliez cacher la lettre « A » (qui est le nombre 65 en code informatique). Vous prenez un nombre normal comme 0,46 et vous le transformez en 0,46065. Pour un humain, cela ressemble toujours à un décimal normal. Mais si vous savez qu'il faut regarder les trois derniers chiffres, vous trouvez « 65 » (A).
- Pourquoi cela a échoué : Lorsque l'ordinateur a traité ces nombres, il les a transformés à nouveau en texte clair. Le garde de sécurité a vu le texte clair et l'a bloqué.
Vecteur T3 (La carte fractale - Le gagnant) :
C'est la partie ingénieuse. Ils ont utilisé un concept mathématique appelé Système de Fonctions Itérées (IFS). Considérez cela comme le dessin d'une forme fractale (comme un flocon de neige) en suivant un ensemble de règles.
- L'attaquant prend son message secret et le convertit en un chemin sur un graphique.
- Il stocke les coordonnées X et Y de ce chemin sous forme de deux listes de nombres à virgule flottante (décimaux).
- Pour que cela paraisse encore plus inoffensif, il ajoute du « bruit » (un tremblement aléatoire) et mélange l'ordre des nombres.
- Le résultat : Les nombres ressemblent à du bruit statique aléatoire ou à des données de capteurs inoffensives. Il n'y a pas de mots. Il n'y a pas de motif évident. Rien de suspect.

L'expérience : Est-ce que cela a fonctionné ?

Les chercheurs ont testé cela contre trois modèles d'IA majeurs (d'OpenAI, Google et Anthropic) et ont utilisé des défenses de sécurité solides, incluant :

Prompt Guard 2 : Un bouclier d'IA spécialisé conçu pour attraper les mauvais prompts.
TF-IDF & RoBERTa : Des scanners de texte avancés entraînés à reconnaître les phrases spécifiques utilisées dans l'attaque.

Les résultats :

Attaque en texte clair : Bloquée 100 % du temps. Les scanners ont vu les mots et les ont arrêtés.
Vecteur T3 (Les nombres fractals) : Taux de réussite de 94,3 %.
- Les scanners de sécurité ont regardé les nombres bruts et n'ont rien vu de suspect.
- Les scanners ont regardé le rapport final (qui présentait le message décodé sous forme de dump de code hexadécimal, type 41 42 43...) et ne l'ont toujours pas signalé comme une « injection de prompt » car cela ne ressemblait pas à une phrase.
- Le modèle d'IA a reçu les données, a décodé le message caché et a suivi l'instruction malveillante.

Pourquoi cela importe (La « limite de défaillance »)

Les auteurs ne disent pas qu'ils ont trouvé un hack incassable. Ils disent qu'ils ont trouvé un angle mort dans la façon dont nous protégeons actuellement les systèmes d'IA.

L'angle mort : Nous supposons que si un message est malveillant, il contiendra des mots malveillants.
La réalité : Si le signal malveillant est caché dans des données structurées (comme des nombres, des coordonnées ou des configurations) qui sont converties en texte après le contrôle de sécurité, le garde est contourné.

Le bémol (Ce n'est pas parfait)

Le papier admet que cette méthode spécifique (T3) peut être arrêtée si l'on change les règles :

Validation sémantique : Si le système vérifie : « Est-ce que ces nombres forment réellement une forme fractale valide ? », il détectera l'attaque car les nombres mélangés ne forment pas une vraie forme.
Détection de format : Si le système dit : « Je n'autorise pas les dumps de code hexadécimal dans ce rapport », il bloquera la sortie.

Cependant, le point est que les scanners basés uniquement sur le texte (la défense la plus courante) ont totalement échoué. Ils n'avaient aucune idée que l'attaque se déroulait parce que les « mauvais mots » n'étaient jamais visibles sous forme de mots pendant la phase d'inspection.

Résumé en une phrase

Le papier démontre que les systèmes de sécurité de l'IA focalisés uniquement sur le scan de mauvais mots peuvent être trompés en cachant des instructions malveillantes à l'intérieur de nombres inoffensifs, qui ne sont décodés en texte lisible qu'après le passage du contrôle de sécurité.

Résumé Technique : Se cacher dans les flottants (Hiding in Plain Floats)

Énoncé du Problème

Les défenses actuelles contre l'injection de prompt indirecte et l'injection de contenu dans les pipelines de modèles de langage (LLM) reposent sur une hypothèse centrale : que les signaux malveillants sont visibles sous forme de texte dans les vues de données inspectées (configuration brute ou rapports reconstitués). Les défenses telles que Prompt Guard, Llama Guard, les passerelles par expressions régulières (regex) de schéma et le "spotlighting" fonctionnent en scannant les chaînes de caractères à la recherche d'instructions impératives ou de schémas d'attaque connus.

Ce document identifie un mode de défaillance où cette hypothèse s'effondre. Les auteurs démontrent que dans les pipelines exposant des canaux auxiliaires numériques reconstruits (par exemple, des paramètres de génération procédurale, des tableaux de plongements/embeddings ou des uniformes de shaders) à un LLM, des charges utiles malveillantes peuvent être transportées sous forme de paramètres flottants structurés. Lors de la reconstruction, ces charges utiles peuvent apparaître comme des télémétries fragmentées (par exemple, des dumps hexadécimaux) plutôt que comme de la prose contiguë. Par conséquent, les couches d'inspection uniquement textuelles échouent à détecter le signal malveillant car le signal n'est pas visible sous forme de texte avant d'être déjà entré dans le contexte du modèle, ou n'est jamais visible sous forme de texte dans les vues inspectées.

Méthodologie

Modèle de Menace

L'étude se concentre sur un pipeline où un actif structuré soumis par l'utilisateur (par exemple, une configuration de génération procédurale) est reconstruit par un parseur de confiance en un rapport lisible par l'humain, qui est ensuite résumé ou analysé par un LLM.

Attaquant : Contrôle les tableaux numériques en amont et les champs de l'actif, mais ne contrôle pas le code de reconstruction, les prompts système ou les poids du modèle.
Défenseur : Peut inspecter la configuration brute en amont, le rapport reconstitué, ou les deux, en utilisant des passerelles regex, des classifieurs prêts à l'emploi ou des modèles affinés (fine-tuned).
Objectif : Déterminer si l'inspection uniquement textuelle peut détecter des attaques où la charge utile est cachée dans des tableaux de flottants et reconstruite sous forme de données non prosiques.

Vecteurs de Stéganographie (Carriers)

Les auteurs introduisent deux vecteurs originaux et un vecteur d'ablation pour tester les limites de détection :

T2 (Stéganographie par coefficients spectraux) : Encode les caractères de la charge utile dans les chiffres décimaux de faible rang des valeurs flottantes représentant des coefficients harmoniques. La configuration brute ne contient aucun texte, mais la reconstruction décode ces flottants pour recréer une prose contiguë au sein d'une « Note d'analyse spectrale ».
T3 (Vecteur de tableau de flottants dérivé d'IFS) : Utilise un système de fonctions itérées (IFS) pour piloter une application de contraction avec les octets de la charge utile. La trajectoire $(x, y)$ $(x, y)$ résultante est stockée sous forme de deux tableaux de flottants coordonnés.
- Contre-mesures : Pour réduire la séparabilité de premier ordre par rapport aux données harmoniques uniformes, les auteurs appliquent :
  - Blanchiment (Whitening) : Un XOR des octets de la charge utile avec un flux pseudo-aléatoire pour supprimer le biais de fréquence des caractères.
  - Jitter Borné (Bounded Jitter) : Ajout d'un bruit déterministe ( $\epsilon \sim U[-0.04, 0.04]$ ) aux coordonnées.
  - Permutation Déterministe (Deterministic Shuffle) : Permutation du tableau pour briser les signaux d'autocorrélation séquentielle.
- Reconstruction : La charge utile est décodée et rendue sous la forme d'un dump hexadécimal de style xxd (16 octets par ligne) avec une barre latérale ASCII. Ce format ne contient pas de prose contiguë, seulement des chaînes hexadécimales fragmentées.
T1b-abl (Ablation) : Stocke la charge utile sous forme de prose brute dans la configuration brute, mais la reconstruit sous forme de dump hexadécimal (identique au format de reconstruction de T3). Cela isole l'effet de la fragmentation de la couche de reconstruction.

Configuration Expérimentale

Modèles : Trois LLM commerciaux (OpenAI GPT-5.4, Google Gemini 3.1 Flash-Lite, Anthropic Claude Sonnet 4.6).
Défenses : Quatre configurations : Aucune, Boundary Prompt (durcissement du prompt système), Schema Gate (regex sur le rapport reconstitué), et un Ensemble de Classifieurs à Double Couche (Prompt Guard 2 + TF-IDF affiné sur le texte de la charge utile de l'étude).
Échelle : 14 400 essais attaqués et 4 800 essais sains sur trois modèles.
Métriques :
- Leakage ASR : Présence de chaînes cibles dans la sortie (fuite d'information).
- Strong ASR : Succès structurellement conforme (ex: marqueur dans les 150 premiers caractères, reproduction du template injecté).
- Taux de Détection : Fraction des attaques signalées par les défenses.

Résultats Clés

Résultat Principal : L'Échec de l'Inspection Uniquement Textuelle

Le vecteur T3 a atteint un Leakage ASR de 94,3 % contre la défense textuelle la plus forte évaluée (Ensemble de classifieurs Prompt Guard 2 + TF-IDF).

Comparaison : Le même texte de charge utile sous forme de prose simple (T0) a été bloqué (0 % ASR) par la même défense.
Mécanisme : Le vecteur T3 supprime les signaux textuels au niveau de la couche brute (flottants) et les fragmente au niveau de la reconstruction (dump hexadécimal). Ni la vue textuelle inspectée ne contient de preuve de prose de l'attaque.
Replication : Un détecteur roberta-base affiné a répliqué ce schéma, capturant tous les vecteurs de prose (T0, T2) mais manquant totalement T3 (0 % de détection). La confiance de pointe du classifieur sur les échantillons T3 était de 0,225, bien en dessous du seuil de 0,5.

Analyse d'Ablation (Décomposition 2x2)

Une ablation 2x2 a isolé les mécanismes nécessaires à l'évasion :

T0 (Prose/Prose) : Capturé aux deux couches.
T2 (Stego/Prose) : Échappe à l'inspection de la couche brute mais est capturé à la reconstruction (prose visible).
T1b-abl (Prose/Hex) : Échappe à l'inspection de la couche de reconstruction (prose) mais est capturé à l'inspection de la couche brute.
T3 (Stego/Hex) : Échappe aux deux couches.
Ceci confirme que la stéganographie de données et la fragmentation de la couche de reconstruction sont toutes deux nécessaires pour vaincre l'inspection textuelle à double couche.

Performance Spécifique aux Modèles

GPT-5.4 : ASR le plus élevé (68,5 % global, 97,0 % pour T3 sous le classifieur).
Claude Sonnet 4.6 : ASR plus faible (50,8 % global) principalement dû aux refus, bien que T3 ait tout de même atteint 92,3 % d'ASR sous la défense du classifieur.
Strong ASR : Même avec la défense du classifieur, T3 a obtenu un succès structurellement conforme significatif (ex: 81,6 % pour l'injection de métadonnées fabriquées), prouvant que les systèmes en aval peuvent agir sur les marqueurs reproduits même si le modèle « refuse » l'impératif.

Limites de Détection

Zero-Shot Prompt Guard 2 : A détecté 0 % des charges utiles, y compris le texte brut (T0). Les auteurs interprètent cela comme un décalage de portée hors distribution (les modèles de garde ciblent les dépassements impératifs, tandis que les charges utiles sont des métadonnées déclaratives), et non comme une défaillance architecturale générale.
Patch Sensible au Format (Format-Aware Patch) : Un simple détecteur de lignes xxd ajouté à la passerelle de schéma a réduit l'ASR de T3 à 0 %. Cependant, les auteurs notent qu'il s'agit d'une signature spécifique à la présentation, et non d'une défense générale contre la classe de vecteurs.

Signification et Revendications

Le papier ne prétend pas présenter un exploit indétectable ou une vulnérabilité universelle dans tous les pipelines de saisie structurée. Il établit plutôt une frontière d'échec reproductible pour l'inspection uniquement textuelle dans des architectures de pipeline spécifiques.

Limitation des Défenses Centrées sur le Texte : La contribution principale est de démontrer que lorsqu'un pipeline admet un vecteur où le signal malveillant n'est pas visible sous forme de texte avant (ou sauf si) il entre dans le contexte du modèle, les garde-fous uniquement textuels (Prompt Guard, Llama Guard, regex) sont insuffisants.
Vecteur vs Contenu : L'étude prouve que le vecteur détermine la détectabilité, et non le contenu de la charge utile. Le même contenu est bloqué lorsqu'il est visible sous forme de prose, mais réussit lorsqu'il est caché dans des flottants et fragmenté en hexadécimal.
Risque des Métadonnées Déclaratives : L'attaque réussit car les charges utiles sont présentées comme des métadonnées déclaratives (ex: « jetons de configuration d'audit ») plutôt que comme des instructions impératives. Cela contourne les défenses entraînées pour refuser les dépassements impératifs, exploitant un décalage dans les distributions d'entraînement de sécurité.
Portée Modeste : Les auteurs précisent explicitement que la contribution n'est pas un exploit indétectable. L'implémentation actuelle de T3 est détectable via une validation sémantique (vérification de la validité des attracteurs IFS) ou des détecteurs de format spécifiques aux dumps hexadécimaux. La signification réside dans l'identification des conditions spécifiques (reconstruction de confiance de canaux numériques auxiliaires) sous lesquelles les hypothèses de sécurité basées sur le texte échouent.