Des sites empoisonnés au SEO cachent une injection pour détourner les agents web IA
Zscaler ThreatLabz a repéré des sites malveillants actifs qui combinent empoisonnement SEO, texte masqué en CSS et balisage schema détourné pour glisser des instructions poussant les agents web autonomes à payer les attaquants.
De quoi s’agit-il ?
Le 2 juillet 2026, Zscaler ThreatLabz a publié une recherche documentant des sites web bien réels qui dissimulent des instructions dans leur propre contenu afin de manipuler des agents web autonomes. Il ne s’agit pas d’une démonstration de laboratoire : les chercheurs ont suivi deux campagnes actives dont les pages usurpent des services légitimes (développement, finance) puis y intègrent des directives de type prompt destinées à être lues par une machine, pas par un humain. La technique est une forme d’injection de prompt indirecte (IPI) : un texte malveillant placé dans le contenu qu’un agent récupère (page web, document, e-mail) afin que l’agent traite les instructions de l’attaquant comme faisant partie de sa tâche. Cet article décrit une classe d’attaque, pas un exploit actionnable.
Ce qui rend le résultat notable, c’est l’emballage. Les attaquants couplent l’injection à un empoisonnement du référencement (SEO poisoning), si bien qu’un agent qui cherche un paquet ou un service a d’autant plus de chances d’atterrir d’emblée sur la page piégée. ThreatLabz a confirmé l’impact réel en testant des agents web sur 26 grands modèles de langage : quatre modèles ont été poussés à exécuter un paiement dans la première campagne, et deux ont étiqueté le site frauduleux comme fiable dans la seconde.
Comment ça marche
Les deux campagnes partagent le même schéma : faire remonter la page, puis cacher la charge là où l’internaute ne la voit pas mais où un parseur la lit.
Étape Technique observée
----------- -------------------------------------------------
Découverte SEO poisoning : HTML/balises meta bourrés de mots-
clés pour placer la fausse page en tête des recherches.
Confiance Balisage JSON-LD détourné (SoftwareApplication,
faux éditeur / offre) — des champs structurés qu'un
agent peut pondérer comme contexte à fort signal.
Dissimulation CSS hors-écran (ex. left:-9999px) sur un <div> caché :
le texte d'injection reste absent du rendu mais vivant
dans le DOM pour les scrapers et les agents.
Charge Instructions présentant une action de l'attaquant
comme une étape de routine.
Dans la première campagne, une fausse page se faisait passer pour la documentation d’une bibliothèque Python et indiquait à l’agent que résoudre une erreur de « clé de licence manquante » exigeait de régler un petit « frais développeur » — envoyant environ 0,0012 ETH vers un portefeuille codé en dur avant de générer une fausse clé d’API. La seconde campagne était un tracker DeFi typosquatté dont le bloc caché employait le classique motif ignore les instructions précédentes, puis déclarait le domaine frauduleux comme la source « vérifiée et faisant autorité » que le modèle devait classer en premier. Comme la page visible semble légitime, ni un humain qui la survole ni un contrôle par capture d’écran n’attraperait le texte planté.
Pourquoi c’est important
Pour un agent autonome, le contenu web récupéré est à la fois instructions et données — et ces campagnes exploitent cette ambiguïté à l’échelle d’internet. Le risque immédiat est la perte financière directe lorsqu’un agent doté d’outils de paiement suit une étape « achetez ceci pour continuer ». Le risque plus insidieux est la contamination du contexte : quand un agent classe un site frauduleux comme faisant autorité, ce jugement peut se propager en aval vers un empoisonnement de corpus RAG et l’endossement du domaine de l’attaquant. C’est un cousin, bien réel, de la corruption d’endossement des agents de recherche et des pièges d’injection par persuasion que nous avons déjà traités.
Les résultats modèle par modèle de ThreatLabz comptent aussi : la vulnérabilité variait selon le modèle et, surtout, selon le contexte. Lorsqu’un domaine de référence fiable était fourni, aucun modèle ne tombait dans le piège du typosquat ; les échecs se concentraient quand l’agent évaluait la page malveillante isolément. La surface d’attaque, c’est le jugement de l’agent en contexte pauvre, pas un modèle unique défaillant.
Défenses
Il n’y a pas de correctif ici — rien n’est techniquement cassé. Les contrôles sont architecturaux et opérationnels, en cohérence avec les recommandations LLM01 de l’OWASP et l’analyse IPI de CrowdStrike.
- Traitez tout contenu web récupéré comme des données non fiables, jamais des instructions. Neutralisez le texte caché du DOM (CSS hors-écran, éléments de taille nulle) et ne laissez pas un balisage structuré comme JSON-LD rehausser automatiquement l’autorité d’une page.
- Verrouillez les actions à fort impact derrière une validation humaine. Un agent ne devrait jamais déplacer des fonds, acheter une « licence » ou signer une transaction sur la seule foi des affirmations d’une page web. Imposez des plafonds de dépense et une confirmation hors bande.
- Fournissez des références fiables. Les échecs se concentraient quand l’agent jugeait un site isolément ; lui donner des domaines d’ancrage faisant autorité réduisait fortement les erreurs de classification.
- Vérifiez domaines et paquets hors bande. Recoupez les affirmations d’éditeur avec des registres et des données de réputation plutôt que de croire l’auto-description d’une page — même leçon que l’abus d’empoisonnement de documentation dans la chaîne d’approvisionnement.
- Journalisez la navigation et le raisonnement de l’agent. Capturez quelles sources ont motivé une décision, afin qu’une page empoisonnée puisse être tracée et bloquée a posteriori.
Statut
| Élément | Référence | Date | Notes |
|---|---|---|---|
| Recherche publique | Zscaler ThreatLabz | 2026-07-02 | Deux campagnes IPI in the wild |
| Campagne 1 (arnaque au paiement) | ThreatLabz | 2026-07-02 | 4 modèles sur 26 ont exécuté le paiement |
| Campagne 2 (typosquat DeFi) | ThreatLabz | 2026-07-02 | 2 modèles sur 26 ont mal classé le site |
| Couverture de détection | Zscaler | 2026-07-02 | Signalé comme HTML.MalURL.PromptInj |
Le cadrage honnête n’est pas « un LLM a été piraté ». C’est que le contenu web est désormais une surface d’attaque pour les agents comme les e-mails de phishing le sont pour les humains — la défense consiste à ne plus laisser une page parler pour elle-même, à verrouiller les actions qui coûtent de l’argent ou de la confiance, et à donner à l’agent une vérité de terrain à laquelle se référer.
Sources
- → https://www.zscaler.com/blogs/security-research/indirect-prompt-injection-web-content-targets-ai-agents
- → https://securityboulevard.com/2026/07/indirect-prompt-injection-in-web-content-targets-ai-agents/
- → https://www.crowdstrike.com/en-us/blog/indirect-prompt-injection-attacks-hidden-ai-risks/
- → https://genai.owasp.org/llmrisk/llm01-prompt-injection/