Salesbleed a révélé une défaillance de frontière de confiance dans Salesforce Agentforce qui permettait à des enregistrements Web-to-Lead empoisonnés d’orienter les agents vers l’exfiltration de données CRM et le phishing sur Slack à destination des employés. Zenity a divulgué ces faiblesses le 24 septembre 2026, après que Salesforce a terminé les correctifs. Salesforce a déclaré le 25 septembre 2026 n’avoir trouvé aucune preuve d’exploitation chez les clients.
Qu’est-ce que Salesbleed ?
Salesbleed est un ensemble de faiblesses de Salesforce Agentforce qui permettaient à des instructions contrôlées par un attaquant, stockées dans des soumissions publiques de leads, d’influencer les actions connectées au CRM et à Slack. Selon les recherches de Zenity du 24 septembre 2026, les résultats démontrés comprenaient une exfiltration de données sans clic via des requêtes DNS et des messages de phishing envoyés sous l’identité Slack de confiance d’un agent.
L’injection indirecte de prompts est une technique d’attaque qui place des instructions malveillantes dans des données qu’un IA agent lit ensuite comme du contenu ordinaire. Ici, l’attaquant n’avait pas besoin d’un accès à Salesforce. Salesforce Web-to-Lead a fourni le point d’entrée non authentifié, et le texte empoisonné est resté dans la table Leads jusqu’à ce que les tâches courantes le présentent à Agentforce.
Cette découverte est importante parce que l’agent transformait une entrée de site web non fiable en action au sein de systèmes métier authentifiés. Le texte de l’attaquant passait d’un formulaire public à des enregistrements Salesforce, atteignait des outils ayant un accès plus large aux données, et pouvait ressortir sous la forme d’un message Slack interne. Il s’agit d’un blanchiment de confiance, et non d’une compromission de compte classique.
Salesforce a déclaré à SecurityWeek le 25 septembre 2026 qu’il n’avait aucune preuve que les chemins d’attaque avaient été exploités contre des clients. Dark Reading a rapporté à la même date qu’aucun identifiant CVE, total de clients affectés, nombre d’identifiants volés ou chiffre de pertes financières n’avait été publié.
Comment la chaîne d’attaque Salesbleed fonctionnait-elle ?
La chaîne Salesbleed commençait par la soumission par un attaquant d’instructions malveillantes via Salesforce Web-to-Lead. Lors d’un examen ultérieur du lead, Agentforce interprétait le texte stocké et pouvait invoquer des capacités CRM ou Slack connectées. La preuve de concept de Zenity du 24 septembre 2026 ne nécessitait aucun clic d’employé pour déclencher l’un ou l’autre des chemins d’exfiltration de données démontrés.
La séquence a exposé quatre décisions de confiance distinctes. Chacune semblait raisonnable prise isolément, mais leur combinaison permettait à un contenu externe d’influencer des actions authentifiées :
- Un attaquant plaçait des instructions dans une soumission Web-to-Lead non authentifiée.
- Salesforce stockait la soumission comme un lead ordinaire sans expiration automatique après une interaction d’agent.
- Le sous-agent General CRM par défaut lisait le lead et pouvait interroger à la fois Leads et Accounts via son outil Query Records.
- Agentforce générait une requête d’image externe ou invoquait une action Slack connectée, produisant une requête sortante ou un message à destination des employés.
Aucune escalade de privilèges n’était nécessaire dans la démonstration de Zenity en 2026. Le sous-agent General CRM disposait déjà de l’accès requis pour passer d’un contenu de lead fourni par l’attaquant à des informations de compte. Cette distinction devrait orienter la réponse : corriger un parseur aide, mais réduire les permissions légitimes d’un agent limite ce qu’une future injection peut atteindre.
La persistance est un risque facile à manquer. Un lead malveillant restait un enregistrement CRM normal et pouvait influencer à plusieurs reprises des interactions ultérieures ; il n’était ni consommé ni invalidé après un seul examen. Les équipes de sécurité qui suivent déjà les risques en entreprise liés aux agents IA autonomes devraient donc traiter les enregistrements externes stockés comme des entrées d’attaque durables, et non comme des prompts ponctuels.
Comment Salesbleed pouvait-il extraire des données du CRM Salesforce ?
Salesbleed pouvait encoder des noms d’entreprise Salesforce et des tailles de transactions dans des noms d’hôtes DNS contrôlés par l’attaquant, selon la preuve de concept de Zenity du 24 septembre 2026. Le rendu automatique d’une image HTML externe et le déploiement automatique d’URL de Slack généraient tous deux des recherches DNS, permettant à des informations de quitter l’environnement sans qu’un employé clique sur le lien généré.
Zenity a indiqué en 2026 que le contrôle Trusted URLs de Salesforce pouvait être contourné parce que le rédacteur et le moteur de rendu en aval n’étaient pas d’accord sur la reconnaissance des domaines de premier niveau et la terminaison des URL. La preuve de concept utilisait un .fun domaine que le rédacteur n’a pas réussi à reconnaître. Salesforce a confirmé l’achèvement des correctifs le 18 août 2026, et Zenity a vérifié la correction des URL de confiance le 19 août 2026.
| Chemin de sortie | Comportement automatique | Clic de l’employé requis | Résultat observable |
|---|---|---|---|
| Image HTML externe | Le moteur de rendu a récupéré l’URL de l’image générée | Non | Recherche DNS vers un nom d’hôte contrôlé par un attaquant |
| Prévisualisation d’URL Slack | Slack a traité l’aperçu de l’URL générée | Non | Recherche DNS vers un nom d’hôte contrôlé par un attaquant |
| Réponse dans un fil Slack | Agentforce a publié via une action connectée | Non avant la remédiation | Message destiné aux employés provenant de l’identité de l’agent |
La bande passante était faible par requête, mais non négligeable au fil du temps. Zenity a noté en 2026 qu’un libellé DNS peut contenir jusqu’à 63 caractères et qu’un nom de domaine complet peut en contenir jusqu’à 253. Avec une charge utile simplifiée de 63 caractères par recherche, 100 recherches réussies pourraient transporter 6 300 caractères encodés avant prise en compte de la surcharge d’encodage et des composants du domaine.
Ce calcul explique pourquoi les fuites DNS à faible bande passante méritent malgré tout de l’attention. Des enregistrements empoisonnés persistants peuvent générer des requêtes répétées, tandis que les journaux DNS ordinaires peuvent faire l’objet de moins de surveillance que les exportations d’API. Les programmes de détection devraient relier les invites de l’agent, les appels d’outils, l’activité DNS et la provenance des enregistrements plutôt que d’examiner chaque flux isolément.
Comment Agentforce est-il devenu un outil de phishing Slack ?
Salesbleed a exploité l’action Reply to a Slack Thread du sous-agent Slack Knowledge standard pour transformer des instructions injectées en messages internes. Avant la remédiation en 2026, l’action pouvait envoyer sans confirmation de l’utilisateur ni attribution visible à l’utilisateur invoquant, ce qui faisait apparaître le contenu dirigé par l’attaquant comme provenant d’une identité Agentforce de confiance au sein de Slack.
Zenity a signalé le 24 septembre 2026 que les administrateurs pouvaient ajouter le sous-agent Slack Knowledge et les actions associées à un agent Agentforce en deux clics. Les chercheurs ont également constaté que Markdown pouvait dissimuler une destination d’hameçonnage derrière un texte de lien d’apparence anodine. Un canal de diffusion interne a donné au leurre ainsi créé une crédibilité qu’un message externe non sollicité e-mail n’aurait pas eue.
Les directives d’assistance de Salesforce du 3 juillet 2026 indiquent que les actions Slack d’Agentforce s’exécutent dans le contexte de sécurité de l’utilisateur authentifié qui les invoque, avec une session distincte par utilisateur pour chaque invocation. Pourtant, le seul contexte d’identité ne résolvait pas le problème de présentation : les destinataires devaient voir qui avait amené l’agent à publier, et les utilisateurs devaient avoir la possibilité d’approuver le contenu sortant.
Salesforce a modifié ces deux points. Zenity a vérifié le 20 août 2026 que les réponses dans les fils attribuaient les messages à l’utilisateur appelant, puis a confirmé le 21 septembre 2026 l’activation par défaut de la confirmation pour Reply to a Slack Thread. Zenity a précisé que le paramètre de confirmation pouvait toujours être désactivé d’un clic de configuration après le correctif ; les administrateurs doivent donc vérifier les paramètres effectifs plutôt que de supposer que les valeurs par défaut plus sûres restent activées.
Honnêtement, un agent d’environnement de travail capable d’écrire ne devrait pas publier de contenu sensible pour la sécurité sans approbation simplement parce que la fonctionnalité le permet. L’incident illustre également pourquoi comprendre comment les agents d’IA sélectionnent et invoquent les outils dépasse le simple codage : le choix de l’outil devient une décision de sécurité lorsque la destination est un canal de communication de confiance.
Salesbleed a-t-il été corrigé, et les clients sont-ils toujours exposés à un risque ?
Salesforce a corrigé les vecteurs d’attaque Salesbleed signalés avant la divulgation publique de Zenity le 24 septembre 2026. Zenity a confirmé tous les correctifs signalés au plus tard le 21 septembre 2026, y compris la correction des Trusted URLs, l’attribution des utilisateurs pour les réponses dans les fils Slack et la confirmation par défaut. Les erreurs de configuration et de futures variantes d’injection de prompt nécessitent toujours des contrôles défensifs.
La chronologie de la remédiation est particulièrement utile. Salesforce a confirmé que les correctifs relatifs à l’exfiltration de données étaient finalisés le 18 août 2026. Zenity a vérifié le correctif du contournement d’URL le 19 août et l’attribution des messages le 20 août ; Salesforce a indiqué le 25 août que le travail sur la confirmation par défaut se poursuivait, avant que Zenity n’achève les tests finaux le 21 septembre.
Au 24 septembre 2026, Zenity décrivait les chaînes divulguées comme étant fermées par défaut. Salesforce a ensuite indiqué le 25 septembre qu’il contactait les clients pour examiner les configurations d’Agentforce. Aucun élément public n’a montré une exploitation chez des clients, mais l’absence d’exploitation signalée ne prouve pas que les journaux historiques ne contiennent aucune activité suspecte.
Le contre-argument le plus solide est simple : il s’agissait de conclusions de recherche corrigées, et non d’une violation massive documentée. Néanmoins, rejeter Salesbleed comme un bogue d’analyseur désormais clos ferait manquer la leçon architecturale. Les organisations qui utilisent de larges autorisations d’agent, l’ingestion de données publiques et des actions sortantes non approuvées peuvent recréer la même catégorie de défaillance via un autre modèle ou une autre intégration.
Comment les administrateurs devraient-ils sécuriser les workflows Agentforce ?
Les administrateurs devraient marquer comme non fiables les enregistrements Salesforce provenant de sources externes, restreindre la portée des outils et des données de chaque sous-agent Agentforce, conserver l’approbation pour les messages sortants et consigner l’intégralité de la chaîne allant du déclencheur à l’action. Les recommandations de Zenity en 2026 insistaient plus particulièrement sur la surveillance des actions d’écriture des agents et sur le maintien des exigences de confirmation activées, plutôt que de se fier uniquement aux valeurs par défaut corrigées de Salesforce.
Commencez par la provenance. Les formulaires Web, les feuilles de calcul importées, les tickets d’assistance, Courriels, et les flux de partenaires devraient être accompagnés d’étiquettes de source lisibles par machine qui restent présentes lors de l’ingestion et de la récupération. Un agent ne devrait pas considérer le texte provenant d’un formulaire public comme une instruction simplement parce que Salesforce l’a stocké dans une table de confiance.
Ensuite, séparez la lecture de l’action. Un agent de tri des leads a généralement besoin de certains champs de lead sélectionnés ; il peut ne pas avoir besoin de requêtes de compte sans restriction ni de l’autorisation de publier dans Slack. Dans la base de référence que je privilégie, toute action qui envoie un message, modifie un enregistrement ou contacte un hôte externe reçoit une approbation explicite et enregistre l’utilisateur appelant.
Les pistes d’audit doivent relier l’enregistrement d’origine, le texte récupéré, la décision du modèle, les arguments de l’outil, la destination réseau, l’événement d’approbation et l’action finale. Les journaux SaaS conventionnels ne capturent souvent que des fragments. Les équipes qui évaluent les plateformes de découverte et de surveillance de l’IA fantôme devraient vérifier si les produits préservent cette chaîne causale plutôt que de simplement inventorier les applications.
L’examen rétrospectif a également de la valeur. Recherchez dans les journaux Agentforce de 2026 des domaines externes inhabituels, le rendu d’images à partir de réponses générées, des requêtes d’aperçu Slack, des accès répétés au même lead, et des requêtes de compte ayant suivi une ingestion Web-to-Lead. Le piège que peu vérifient est la récurrence : un enregistrement empoisonné peut rester dangereux après la clôture de la première alerte.
FAQ Salesbleed
Salesbleed a-t-il nécessité des identifiants Salesforce volés ?
Salesbleed n’a pas nécessité d’identifiants volés dans la preuve de concept 2026 de Zenity. L’attaquant a saisi des instructions malveillantes via la fonctionnalité Salesforce Web-to-Lead non authentifiée, tandis que les actions Agentforce ultérieures se sont exécutées via un accès connecté légitime.
Salesbleed a-t-il reçu un CVE ?
Salesbleed n’avait aucun identifiant CVE signalé au 25 septembre 2026, selon Dark Reading. Les rapports publics n’ont pas non plus fourni de nombre de clients affectés ni de total des pertes financières.
Les clients de Salesforce ont-ils perdu des données ?
Salesforce a déclaré le 25 septembre 2026 n’avoir aucune preuve que Salesbleed ait été exploité contre des clients. Zenity a démontré, dans ses recherches, une exfiltration techniquement viable, mais une preuve de concept n’est pas la preuve d’une compromission client.
La désactivation de Web-to-Lead peut-elle empêcher l’attaque ?
La désactivation de Salesforce Web-to-Lead supprime le point d’entrée utilisé dans la démonstration de 2026 de Zenity, mais cela ne résout pas le problème plus large de l’injection indirecte de prompts. D’autres enregistrements externes peuvent contenir des instructions malveillantes, à moins que les workflows Agentforce n’imposent la provenance, des autorisations limitées, des approbations et une journalisation de bout en bout.