Data / IA
Faille SalesBleed : les agents IA de Salesforce jouent au cheval de Troie
Par Laurent Delattre, publié le 25 septembre 2026
Pas besoin de pirater Salesforce quand on peut convaincre son agent IA d’exfiltrer les données pour soi. Avec la faille SalesBleed, les chercheurs de Zenity Labs ont découvert comment de simples données injectées dans le CRM pouvaient pousser Agentforce à exfiltrer des informations clients et à relayer du phishing sur Slack. Les failles sont corrigées, mais la leçon vaut pour tous les agents IA des concurrents.
Il suffisait d’un prospect. Ou plus exactement d’un faux prospect glissé dans Salesforce pour transformer Agentforce en auxiliaire involontaire d’un attaquant. Baptisée SalesBleed, la série de failles dévoilée le 24 septembre par les chercheurs de Zenity Labs montre à quel point l’arrivée des agents IA dans les applications d’entreprise change la donne côté sécurité.
Le problème n’est plus seulement de protéger une base de données ou de filtrer une entrée malveillante. Il faut désormais empêcher une IA disposant de droits légitimes de faire, très efficacement, ce qu’on ne lui a jamais demandé de faire (mais que des attaquants aimeraient bien qu’elle fasse) !
SalesBleed regroupe en réalité trois faiblesses affectant Salesforce Agentforce. Elles permettaient notamment d’exfiltrer des données CRM sans clic de l’utilisateur et d’exploiter l’intégration avec Slack pour diffuser des messages de phishing sous l’identité de l’agent.
Salesforce a corrigé les chaînes d’attaque décrites par les chercheurs. Zenity indique avoir validé les derniers correctifs le 21 septembre. Salesforce a par ailleurs déclaré n’avoir observé aucun signe d’exploitation réelle de ces vulnérabilités jusqu’ici.
Le formulaire commercial qui se transforme en porte d’entrée
L’attaque commence pourtant de façon presque banale : avec Web-to-Lead, le mécanisme Salesforce permettant à un formulaire Web public d’alimenter automatiquement le CRM.
L’attaquant dépose dans un champ du formulaire des instructions destinées non pas à l’utilisateur, mais à l’agent IA. Une injection indirecte de prompt, donc. Le contenu reste tranquillement stocké dans Salesforce jusqu’au jour où un commercial demande à Agentforce quelque chose d’aussi innocent que « analyse mes derniers prospects ».
L’agent lit alors le lead empoisonné… et peut suivre les instructions cachées qu’il contient.
Dans la démonstration de Zenity, Agentforce interrogeait ensuite la table Accounts grâce à ses droits parfaitement légitimes, récupérait des informations telles que le nom d’un client ou le montant d’une affaire, puis les insérait dans une URL contrôlée par l’attaquant. Le chargement automatique d’une image provoquait une requête DNS contenant ces données. Aucun clic. Aucun téléchargement. Et surtout aucune élévation de privilèges : l’agent utilisait simplement les droits qu’on lui avait généreusement accordés pour exfiltrer des données sensibles.
Dit autrement, avec de telles attaques qui dérivent des méthodes « prompts injection« , l’attaquant n’a pas besoin d’entrer dans Salesforce : il persuade simplement l’agent qui y est déjà de travailler pour lui.
Quand Slack apporte le tampon « message interne »
Les chercheurs ont ajouté une seconde corde à leur arc en exploitant Slack. Son mécanisme d’« unfurling », qui récupère automatiquement les URL afin d’en générer un aperçu, pouvait lui aussi déclencher une exfiltration discrète et terrifiante.
Plus gênant encore, l’action Agentforce « Reply to a Slack Thread » ne demandait initialement ni confirmation explicite avant l’envoi ni attribution visible de l’utilisateur ayant déclenché l’action. Une injection placée dans Salesforce pouvait donc conduire l’agent à publier un lien de phishing dans un canal Slack sous sa propre identité.
Pour l’ingénierie sociale, difficile de rêver mieux : le message n’arrive pas depuis une obscure adresse Gmail mais au beau milieu d’une conversation interne, envoyé par un agent que les collaborateurs utilisent quotidiennement.
Salesforce a depuis ajouté l’attribution nécessaire et imposé par défaut une confirmation pour ce type d’actions. Mais Zenity souligne un détail qui mérite d’être affiché en gros dans les consoles d’administration : cette confirmation peut être désactivée. Prudence donc.
Revoir les droits des agents
Il serait tentant de classer SalesBleed dans la catégorie « faille corrigée, dossier suivant ». Mais ce serait manquer l’essentiel.
Les agents IA cumulent précisément les trois propriétés dont rêvent les attaquants : ils consomment des données venant de l’extérieur, accèdent à des informations internes sensibles et disposent désormais d’outils capables d’agir sur d’autres applications.
Aujourd’hui, c’est Salesforce qui a été ciblé. Mais le raisonnement vaut tout autant pour les agents connectés à Microsoft 365, ServiceNow, SAP, Google Workspace ou aux outils métiers maison. Et il ne fait guère de doute que dans tous ces produits aux fonctionnalités agentiques neuves et encore fragile, de nouveaux scénarios d’attaque puissent être élaborés.
Pour les DSI et RSSI utilisant Agentforce, la première urgence consiste à vérifier les configurations, et pas seulement à considérer que le SaaS ayant été corrigé, le problème global n’existe plus. Les actions d’écriture doivent conserver une validation humaine, en particulier celles capables d’envoyer des messages, de modifier des données ou de déclencher des workflows. Les droits des sous-agents doivent aussi être ramenés au strict nécessaire : un agent chargé de traiter des leads n’a pas forcément besoin d’explorer l’ensemble des comptes clients.
Il faut également surveiller les entrées publiques (formulaires, emails, tickets, documents importés) et les considérer comme des sources potentiellement hostiles, rechercher d’éventuels enregistrements contenant des instructions suspectes et conserver une journalisation fine des outils invoqués par les agents.
Enfin, il reste utile de surveiller les requêtes DNS et les connexions vers des destinations inhabituelles. Dans SalesBleed, les données volées étaient glissées dans le nom de domaine de l’URL piégée. Or, avant même de charger l’image, le système doit traduire ce nom de domaine en adresse IP : cette requête DNS aboutissait sur un serveur contrôlé par l’attaquant, qui récupère les données au passage. Bloquer ensuite la connexion HTTP vers le site n’aurait donc rien empêché : les informations avaient déjà fui.
La faille SalesBleed ne démontre donc pas que les agents IA sont impossibles à sécuriser. Mais elle rappelle que leur sécurité ne se limite pas à celle du modèle. Dès qu’on leur donne accès au SI, un connecteur Slack et quelques permissions généreuses, ils deviennent de véritables identités techniques privilégiées. Et une identité privilégiée qui lit tout, comprend presque tout et agit toute seule mérite probablement un peu plus de surveillance qu’un chatbot posé dans un coin.
Photo : pixadot.studio / Shutterstock
À LIRE AUSSI :
À LIRE AUSSI :
