SalesBleed a transformé les formulaires de contact Salesforce en voie d’accès silencieuse aux données CRM

Trois vulnérabilités dans Salesforce Agentforce permettaient à des attaquants de dissimuler des instructions malveillantes dans des formulaires Web-to-Lead. Ils pouvaient ainsi dérober des informations du CRM ou diffuser des messages d’hameçonnage dans des canaux Slack internes.

Zenity Labs a regroupé ces failles sous le nom de SalesBleed. Deux d’entre elles permettaient d’exfiltrer des données sans clic après le traitement d’un prospect piégé par Agentforce. La troisième pouvait amener l’agent à publier des contenus d’hameçonnage sous sa propre identité, pourtant considérée comme fiable.

Zenity Labs a signalé les problèmes le 1er juin. Salesforce a confirmé que les trois failles avaient été corrigées au 19 août. Aucun identifiant CVE, score de gravité, plage de versions concernées ni détail sur les mesures correctives n’a toutefois été communiqué.

Un formulaire public comme point d’accès initial

Salesforce Web-to-Lead est un mécanisme officiel permettant de recueillir des informations auprès de clients potentiels et de les transférer directement dans le CRM Salesforce. Cette connexion permettait également à des personnes non authentifiées d’y déposer du texte contrôlé par un attaquant, qu’Agentforce pouvait ensuite traiter.

Un attaquant pouvait soumettre un prospect contenant des instructions soigneusement conçues. Le contenu restait inactif dans le CRM jusqu’à ce qu’un employé demande à un agent Agentforce d’examiner ou de résumer la soumission, ou d’interagir avec elle d’une autre manière.

L’agent pouvait alors interpréter les instructions intégrées comme des commandes, plutôt que comme des données non fiables. Il s’agit d’une forme d’injection indirecte de prompt : l’attaquant ne s’adresse pas à l’agent d’IA par son interface de conversation habituelle, mais insère des instructions dans des informations que l’agent est censé traiter ultérieurement.

La soumission initiale ne suffisait pas, à elle seule, à extraire les données. Il fallait qu’un employé fasse entrer le prospect piégé dans le contexte de l’agent. Une fois qu’Agentforce l’avait traité, en revanche, le transfert des données pouvait s’effectuer sans autre clic, validation ni action volontaire de l’employé.

Des failles dans les URL de confiance permettaient de transmettre des données discrètement

Deux des vulnérabilités SalesBleed concernaient les Trusted URLs, un mécanisme de sécurité destiné à empêcher Agentforce d’afficher des images ou des URL hébergées sur des sources non approuvées.

D’après les conclusions de Zenity Labs sur les vecteurs d’attaque SalesBleed, ce mécanisme ne reconnaissait pas correctement les domaines de premier niveau. Les chercheurs ont également découvert que des séquences de caractères conçues à dessein pouvaient modifier l’interprétation des URL.

Ces failles permettaient au contenu Web-to-Lead piégé de contourner les restrictions prévues sur les destinations. Une fois les instructions malveillantes traitées, Agentforce pouvait récupérer des informations sensibles dans les tables des prospects et des comptes du CRM, puis les intégrer à une requête sortante.

Le mécanisme d’exfiltration reposait sur des balises d’image HTML. Au lieu d’afficher une image ordinaire, la balise déclenchait une requête vers une infrastructure contrôlée par l’attaquant, en incorporant des informations du CRM à cette requête. Le chargement de la ressource externe transmettait ainsi les données.

Cette technique détourne un comportement courant du Web : pour afficher une image, une application doit contacter le serveur indiqué dans la source de l’image. Si des données sensibles sont insérées dans cette URL, le serveur destinataire peut les récupérer dans la requête reçue.

L’attaque générait également un faux sentiment de sécurité. Agentforce pouvait indiquer à l’utilisateur que les règles de l’organisation avaient bloqué le contenu, alors même que la requête sortante avait déjà exposé les informations. Un message rassurant dans l’interface ne prouvait donc pas que la protection avait fonctionné.

Les aperçus de liens Slack ouvraient une deuxième voie d’exfiltration

Une technique apparentée visait les organisations utilisant Agentforce dans Slack. La plateforme de messagerie récupère automatiquement des informations sur les liens afin d’en générer des aperçus, un mécanisme généralement appelé « unfurling ».

SalesBleed exploitait cette récupération automatique. Des liens spécialement conçus, présents dans les réponses d’Agentforce, pouvaient amener Slack à envoyer des requêtes à une infrastructure contrôlée par l’attaquant. Ces requêtes pouvaient contenir des informations extraites du CRM Salesforce.

Aucun employé n’avait besoin d’ouvrir le lien pour que le transfert ait lieu. Le mécanisme de génération des aperçus envoyait automatiquement la requête réseau dès l’apparition du lien : l’exfiltration ne nécessitait donc aucun clic.

Ce vecteur montre aussi pourquoi des contrôles axés uniquement sur les clics directs dans un navigateur peuvent laisser passer des fuites de données impliquant l’IA. La connexion externe peut provenir d’une intégration côté serveur ou d’une plateforme collaborative, plutôt que du poste de travail d’un employé.

Aucun domaine contrôlé par les attaquants, schéma de requête, exemple de journal ou autre indicateur de compromission n’a été publié. Les organisations ne disposent donc d’aucun ensemble d’indicateurs propre à SalesBleed à rechercher.

L’identité de l’agent pouvait servir à hameçonner des employés

La troisième vulnérabilité touchait l’intégration Agentforce–Slack. Elle visait à usurper une identité plutôt qu’à extraire directement des données par le biais d’une image ou d’une requête d’aperçu.

L’agent ne permettait pas d’identifier l’utilisateur à l’origine d’un message. Un attaquant pouvait exploiter cette absence d’attribution en soumettant un formulaire Web-to-Lead malveillant, prendre le contrôle du comportement de l’agent et lui faire publier des messages d’hameçonnage dans des canaux Slack internes.

Ces messages apparaissaient sous l’identité de l’agent. Or, les employés peuvent accorder davantage de confiance à un contenu publié par un outil d’automatisation d’entreprise approuvé qu’à un message envoyé par un utilisateur inconnu.

Si un destinataire suivait un lien d’hameçonnage et divulguait ses identifiants, les conséquences pouvaient dépasser le cadre de Salesforce. L’identité compromise pouvait donner accès à la messagerie professionnelle, à Slack, aux dépôts de code source et à d’autres applications d’entreprise accessibles à cet employé.

La faille créait donc deux niveaux de risque. Le problème immédiat était l’envoi non autorisé de messages par Agentforce. Les dommages qui pouvaient en découler dépendaient ensuite de la réaction des destinataires face aux contenus d’hameçonnage et des droits associés aux identifiants dérobés.

Produits, versions et gravité non précisés

Les vecteurs d’attaque décrits impliquaient trois composants interconnectés :

• Salesforce Agentforce
• Salesforce CRM
• L’intégration Agentforce–Slack

Les versions exactes concernées n’ont pas été communiquées. On ignore également si l’exploitation dépendait de configurations particulières d’Agentforce, d’actions activées, de permissions CRM, de paramètres Slack ou de règles Trusted URL.

Aucun identifiant CVE n’a été attribué aux trois vulnérabilités. Il est donc impossible, au vu des informations disponibles, d’établir leur statut dans le catalogue Known Exploited Vulnerabilities de la Cybersecurity and Infrastructure Security Agency des États-Unis.

Aucune évaluation officielle de la gravité n’a été publiée non plus. L’absence de score ne change rien aux conséquences démontrées : deux failles pouvaient exposer des données du CRM sans clic de l’utilisateur, tandis que la troisième pouvait exploiter la confiance accordée à un agent interne pour diffuser des messages d’hameçonnage.

Aucune information n’a été publiée sur d’éventuelles attaques en dehors des tests des chercheurs. On ignore donc si des attaquants ont exploité SalesBleed dans des environnements de production avant que Salesforce ne corrige les failles.

Salesforce affirme avoir corrigé les failles, mais les consignes restent limitées

Salesforce a confirmé que les trois vulnérabilités avaient été corrigées au 19 août. L’entreprise n’a communiqué aucun identifiant de correctif, numéro de version corrigée, changement de configuration ni consigne de contournement.

Les clients devraient vérifier auprès de leur support Salesforce et de leurs équipes d’administration que leur environnement Agentforce bénéficie bien des protections concernées. Cette vérification est particulièrement importante lorsque Web-to-Lead, l’accès aux données du CRM et l’intégration Slack sont activés simultanément.

En l’absence d’indicateurs publiés, les équipes de défense peuvent examiner l’historique des connexions sortantes générées lorsqu’Agentforce traitait des données de prospects provenant de sources externes. Elles peuvent aussi rechercher dans Slack des liens ou messages inattendus liés à Agentforce, même si aucun schéma de détection propre à SalesBleed n’a été communiqué.

Les administrateurs devraient également évaluer la quantité d’informations du CRM qu’Agentforce peut récupérer et les actions que l’intégration Slack est autorisée à effectuer. Limiter les permissions de l’agent et surveiller les requêtes sortantes automatisées peut réduire l’exposition si une voie d’injection de prompt comparable venait à apparaître.

La faille centrale de SalesBleed ne se limitait pas au modèle de langage. L’attaque reposait sur la combinaison de données CRM non fiables, de failles dans la validation des URL, des permissions de l’agent, du rendu HTML et du comportement réseau automatique de Slack. Une fois ces composants interconnectés, une soumission via un formulaire public pouvait franchir plusieurs périmètres de confiance au sein d’une entreprise.