Retour au blog
CVEMicrosoftBingSVGinjection de commandeagents IA

Bing Images CVE-2026-32194 : injection de commande par SVG

Publié le 2026-07-24 · Mis à jour le 2026-10-295 min de lecture
En bref : CVE-2026-32194 et CVE-2026-32191 sont deux injections de commande notées CVSS 9.8 dans la chaîne de traitement d'images de Bing. Un SVG forgé, envoyé par la recherche par image ou récupéré par le robot d'exploration, faisait exécuter une commande au worker, en NT AUTHORITY\SYSTEM sous Windows et en root sous Linux. XBOW les a signalées en privé ; Microsoft a corrigé côté serveur avant la publication des avis du 19 mars 2026, et les détails techniques sont sortis le 23 juillet. Aucune action n'était demandée aux clients.

Que s'est-il passé exactement ?

Selon The Hacker News, XBOW, une start-up de sécurité offensive autonome, a trouvé deux chemins vers le même défaut. CVE-2026-32194 (CWE-77) passe par la fonction publique « Rechercher par image » : le SVG est envoyé en base64 dans le champ imageBin vers /images/kblob. CVE-2026-32191 (CWE-78) passe par le robot d'exploration : l'attaquant héberge un SVG et fournit son URL via le paramètre imgurl, puis bingbot/2.0 va le chercher. Aucune authentification, aucun cookie et aucune interaction n'étaient nécessaires. Microsoft n'a signalé aucune exploitation au moment des avis.

La charge utile était un SVG d'un pixel. Il contenait une référence d'image commençant par un caractère pipe (|). Une couche de conversion transmettait cette référence à un shell via un programme externe appelé « delegate », au lieu de la traiter comme un nom de fichier. La sortie de la commande était renvoyée vers un collecteur contrôlé par XBOW.

Est-ce vraiment une faille de « parsing » de SVG ?

Non, c'est une injection de commande dans une couche de conversion. L'article ne nomme pas ImageMagick comme composant de Bing, mais il rapproche explicitement le mécanisme d'ImageTragick (CVE-2016-3714), où un nom de fichier forgé déclenchait lui aussi un delegate. Cette nuance compte pour la défense : durcir un parseur XML ne suffit pas si un second composant passe des chaînes issues du fichier à un shell.

Qui est concerné ?

Les utilisateurs de Bing n'avaient rien à corriger : les avis indiquent « no customer action to resolve », puisque le code vulnérable tournait uniquement chez Microsoft. Les workers testés tournaient sur Windows Server 2022 Datacenter avec SeImpersonatePrivilege et SeDebugPrivilege actifs, et sous root sur Linux, sur plusieurs hôtes et plages réseau. XBOW dit n'avoir lancé que des commandes inoffensives en lecture seule.

Vous êtes concerné par la classe de bug si votre produit convertit, redimensionne ou analyse des fichiers fournis par des tiers avec ImageMagick, Ghostscript, FFmpeg, LibreOffice ou tout outil appelé en ligne de commande.

Comment détecter ou tester ce type de faille ?

Pour tester votre propre pipeline, utilisez un environnement de test et un domaine de collecte que vous contrôlez :

  1. Listez tous les endroits où un fichier ou une URL fournie par un utilisateur atteint un convertisseur (avatars, aperçus, import de documents, vignettes de liens).
  2. Soumettez un fichier inoffensif dont une référence interne pointe vers votre collecteur, et observez si le worker émet une requête sortante.
  3. Cherchez les erreurs 500 qui accompagnent une requête sortante : XBOW a repéré des workers qui répondaient en erreur tout en récupérant et analysant le fichier, signe d'un composant en aval.
  4. Vérifiez la politique du convertisseur : avec ImageMagick, policy.xml doit refuser les delegates et limiter les formats acceptés.
  5. En production, alertez sur les processus enfants inattendus d'un worker d'images, les connexions sortantes de ce worker et les nouveaux fichiers dans son répertoire de travail.

Comment corriger et durcir ?

Le correctif de Microsoft était côté serveur. Chez vous, les recommandations de l'article convergent :

  • Refuser les delegates dans policy.xml et n'autoriser que les formats utiles.
  • Isoler la conversion dans un conteneur ou un bac à sable, sans accès réseau sortant.
  • Faire tourner le worker avec un compte à privilèges minimaux, jamais en root ni en SYSTEM.
  • Limiter les destinations des récupérations côté serveur par une liste blanche.
  • Assainir le SVG côté serveur avant tout traitement, et ne jamais l'afficher en ligne sur votre domaine sans filtrage.

Que change la présence d'un agent IA dans ce scénario ?

Un agent IA qui peut déposer, générer ou récupérer des fichiers transforme ce bug local en chaîne automatisable. Voici les points à examiner :

  • L'agent comme courroie de transmission. Un agent qui télécharge une image ou un document depuis une page web, un e-mail ou une base documentaire, puis le passe à un convertisseur, exécute sans le savoir le fichier d'un attaquant. L'attaquant n'a plus besoin d'accéder à l'interface d'upload : il lui suffit de placer le fichier là où l'agent ira le chercher. C'est le schéma de l'injection de prompt indirecte.
  • Les outils de conversion exposés en tant qu'outils. Si un agent dispose d'un outil « convertir ce fichier » ou « générer une vignette », ses arguments sont du texte choisi par le modèle, donc potentiellement par l'attaquant. Une chaîne de type |commande dans un nom de fichier devient un vecteur d'injection de commande indirect.
  • Les secrets présents dans le contexte et l'environnement. Un worker compromis en SYSTEM lit les variables d'environnement, les jetons et les clés d'API. Si le même hôte héberge l'agent ou ses identifiants (clés de modèle, jetons de calendrier, accès à la messagerie), un fichier piégé devient une prise de contrôle des actions de l'agent.
  • Les actions automatiques. Un agent qui envoie des e-mails, ouvre des tickets ou modifie des documents après avoir traité un fichier peut propager la compromission sans validation humaine. C'est la zone de risque décrite par OWASP sous LLM06 (Excessive Agency).
  • L'absence de trace lisible. Les journaux montrent « l'agent a converti un fichier », pas une commande injectée. Il faut journaliser les arguments exacts passés aux outils.

Pour réduire ce risque, donnez à l'agent des outils étroits (un format, une taille maximale, aucun argument libre), exécutez la conversion dans un bac à sable sans réseau, et exigez une validation humaine pour toute action qui sort du périmètre. Le détail des vecteurs est dans notre page sur la sécurité des agents IA et sur la sécurité MCP.

Comment tester ce risque sur un agent IA ?

Un test d'agent reprend la démarche ci-dessus : on dépose des fichiers piégés dans les sources que l'agent lit (e-mails, documents partagés, pages web), on observe quels outils il appelle et avec quels arguments, et on vérifie si une commande ou une action non prévue en sort. Le Red Team Agent Express couvre ce périmètre en 5 jours pour 1 900 €, avec un rapport de preuves exploitable par vos équipes. Pour démarrer, un rendez-vous découverte de 30 minutes (gratuit) permet de examiner quels formats de fichiers votre agent convertit et avec quels arguments.

Votre produit embarque un agent IA ? CleanIssue teste ce qu’un inconnu peut lui faire faire avec le Red Team Agent Express (5 jours, 1 900 €), ou un red team sur mesure pour plusieurs agents et serveurs MCP. Premier échange : un rendez-vous découverte de 30 minutes, gratuit.

Sachez ce que votre agent peut faire avant un attaquant.

Rendez-vous découverte de 30 minutes, gratuit : vous décrivez votre agent, je vous dis ce que je testerais et à quel prix. Cinq études de cas sont publiées.

Prendre rendez-vous