Injection de prompt via les métadonnées des fichiers téléversés dans les pipelines RAG
Champs EXIF, propriétés « auteur » des PDF, métadonnées des documents Office : nombreux sont les pipelines RAG à les ingérer aux côtés du texte. Les instructions qu'on y cache sont suivies presque aussi souvent. Un canal d'injection discret.
De quoi s’agit-il ?
La plupart des systèmes de génération augmentée par récupération (RAG) permettent aux utilisateurs de téléverser des documents — PDF, images, fichiers bureautiques — qui sont ensuite analysés, découpés, vectorisés puis restitués à un modèle de langage comme contexte. Le débat sur la sécurité de ce pipeline se concentre presque toujours sur le corps de ces documents. Or un fichier transporte bien plus que son texte visible : les balises EXIF des images, les champs « auteur » et « titre » d’un PDF, les propriétés personnalisées d’un fichier Word ou Excel, les blocs XMP et autres métadonnées structurées voyagent avec lui.
Une observation consignée le 5 juin 2026 dans l’AI Model Vulnerability Tracker d’Axis Intelligence Research (entrée AVI-2026-0091, mise à jour le 4 juillet 2026) rapporte que, dans quatre des six frameworks RAG d’entreprise testés, ces métadonnées sont analysées et concaténées avec le texte du corps avant d’atteindre le modèle — et qu’une instruction placée dans un champ de métadonnées est suivie à un taux de conformité proche de celui d’une instruction rédigée dans le corps du document. C’est un cas précis, et facile à négliger, de la classe d’injection indirecte cataloguée sous LLM01 dans le Top 10 OWASP pour les applications LLM.
Comment ça marche
Le mécanisme n’a rien d’inédit ; c’est le canal de livraison qui l’est. L’injection de prompt indirecte fonctionne parce qu’un modèle ne distingue pas de façon fiable les instructions du développeur ou de l’utilisateur d’un texte qui semble figurer dans un contenu qu’on lui a demandé de traiter. Les métadonnées ne font qu’élargir la surface : c’est du texte que le modèle ingère mais qu’un relecteur humain ne lit presque jamais.
Téléversement → Extraction → Découpage → Vectorisation → Récupération → Assemblage du prompt
│
└── texte du corps ✔ souvent relu / assaini
└── EXIF / XMP ✘ souvent transmis tel quel
└── auteur/titre PDF ✘ souvent transmis tel quel
└── propriétés doc ✘ souvent transmis tel quel
Un attaquant fixe l’un de ces champs à une instruction — par exemple une image dont la « description », ou un PDF dont le champ « auteur », contient [REDACTED : instruction demandant au modèle d'ignorer le contexte précédent et d'effectuer une action]. Lorsque l’extracteur aplatit le fichier en texte pour l’indexer, cette chaîne atterrit dans le corpus récupérable sans aucun marqueur la distinguant du contenu légitime. Il s’agit d’une variante à saveur supply-chain de l’ancienne injection via la couche d’annotation des PDF (AVI-2026-0017 d’Axis, déposée en avril 2026), cohérente avec le tableau empirique plus large de Indirect Prompt Injection in the Wild (arXiv 2604.27202) : les injections se logent de plus en plus dans les canaux que les défenseurs inspectent le moins.
Pourquoi c’est important
Toute organisation exécutant du RAG sur des documents fournis par les utilisateurs ou par des tiers est exposée, et la barrière à l’entrée est basse : modifier un champ de métadonnées ne requiert aucun accès particulier et laisse le document visible intact ; l’attaque survit donc à une relecture humaine sommaire et à de nombreux filtres de modération qui ne scrutent que le corps rendu. Comme la charge utile voyage dans un fichier d’apparence anodine, elle peut rester dormante dans un index et ne se déclencher que lorsqu’une requête pertinente la récupère. L’impact suit ce que l’agent en aval est capable de faire : manipulation de contenu, exfiltration de données via des appels d’outils, ou orientation de la réponse d’un assistant.
Défenses
Le principe fondamental est de traiter toutes les métadonnées extraites comme des entrées non fiables, et non comme des données structurées de confiance.
Retirez ou normalisez les métadonnées avant l’indexation : sauf si un champ est explicitement nécessaire, supprimez les balises EXIF, XMP, les dictionnaires « info » des PDF et les blocs de propriétés documentaires dès l’ingestion. Lorsque des métadonnées doivent être conservées (pour la recherche ou la traçabilité), stockez-les dans un champ distinct et clairement étiqueté qui n’est jamais concaténé au contexte d’instruction du modèle. Appliquez aux métadonnées le même assainissement d’entrée et le même filtrage des résultats d’outils que vous appliquez déjà au texte du corps, et maintenez une séparation quarantaine/privilège afin qu’un contenu récupéré non fiable ne puisse pas piloter directement des actions privilégiées. Enfin, journalisez de quel document et de quel champ provient chaque fragment récupéré, afin qu’une instruction injectée puisse être retracée et le fichier source retiré. Ces mesures correspondent directement aux défenses en couches recommandées par le Top 10 OWASP pour les LLM pour LLM01.
Status
| Élément | Détail |
|---|---|
| Première consignation | 5 juin 2026 (Axis Intelligence Research, AVI-2026-0091) |
| Nature | Injection indirecte au niveau du framework via les champs de métadonnées |
| Concernés | Frameworks RAG analysant les métadonnées dans le contexte du modèle (indépendant du modèle) |
| Responsable du correctif | Mainteneurs de frameworks RAG + intégrateurs (nettoyage des métadonnées à l’ingestion) |
| Classe | OWASP LLM01 — Injection de prompt (indirecte) |
Les dates d’observation reflètent les publications citées. Les résultats issus d’une reproduction en laboratoire unique doivent être validés sur votre propre stack avant d’en tirer des conclusions sur un modèle ou un framework précis.