SalesBleed : exfiltration de données CRM sans clic depuis Salesforce Agentforce

Qu’est-ce que c’est ?

Le 24 septembre 2026, Zenity Labs a publié SalesBleed, un ensemble de trois failles dans la manière dont Salesforce Agentforce filtrait les URL présentes dans les réponses de l’agent. Combinées à une injection de prompt indirecte déposée via un formulaire public Web-to-Lead, elles permettaient une exfiltration de données CRM sans aucun clic : il suffisait que la victime pose une question banale à l’agent. Infosecurity Magazine et Salesforce Ben l’ont relayé le 25 septembre.

Selon la chronologie de Zenity, le problème a été signalé à Salesforce le 1er juin 2026, discuté avec son équipe sécurité le 16 juin, confirmé corrigé le 18 août, puis divulgué le 24 septembre. Aucun identifiant CVE n’est cité dans les sources consultées.

Comment ça fonctionne

Le mécanisme « Trusted URLs » d’Agentforce masque les liens vers des destinations non fiables dans les sorties de l’agent. Zenity a identifié trois écarts entre ce que le filtre considère comme une URL et ce que le navigateur interprète réellement :

• Le filtre ne reconnaissait qu’un ensemble fixe de domaines de premier niveau ; les noms d’hôte sous des TLD inconnus n’étaient pas signalés.
• Le filtre et la surface de rendu divergeaient sur la fin d’une URL : certains crochets et accolades n’étaient pas masqués mais restaient fonctionnels à l’affichage.
• Des URL malformées, non conformes à la RFC 3986, passaient le filtre tout en étant chargées par les navigateurs comme sources d’image.

La chaîne d’attaque, au niveau conceptuel : un tiers soumet un prospect dont le champ libre contient des instructions. Plus tard, un employé interroge l’agent sur les leads et l’agent lit cet enregistrement dans son contexte. Le texte injecté pousse l’agent à interroger les comptes via son outil Query Records, à intégrer le résultat dans un nom d’hôte et à l’émettre comme référence d’image. Lorsque le navigateur tente de charger l’image, la résolution DNS transporte les données vers un serveur contrôlé par l’attaquant. La preuve de concept de Zenity a extrait des noms d’entreprises et des montants de deals, et précise que l’injection « pouvait demander tout ce que l’outil Query Records du sous-agent peut atteindre ». Cet article omet volontairement les charges utiles et les formes exactes d’URL.

Pourquoi c’est important

Le schéma dépasse un seul éditeur. Tout agent qui (1) ingère des enregistrements créés par des tiers non authentifiés, (2) dispose d’un outil de lecture de données et (3) affiche des liens ou des images présente la même structure. Le filtrage de sortie est un analyseur syntaxique, et un analyseur en désaccord avec le moteur de rendu crée des contournements. Le canal d’exfiltration étant une requête DNS déclenchée par l’affichage, il ne demande aucun clic et laisse peu de traces dans les journaux applicatifs.

Défenses

• Limiter les outils à la tâche. Un agent de tri des leads entrants ne devrait pas avoir un accès large à la table des comptes ; appliquez le moindre privilège par agent et par sous-agent.
• Traiter les entrées non authentifiées comme non fiables. Les champs de saisie publics (Web-to-Lead, etc.) doivent être signalés, assainis ou exclus du contexte de l’agent lorsque c’est possible.
• Ne pas se reposer sur la seule redaction. Préférez une liste blanche de destinations exactes à une liste noire de motifs, et désactivez le rendu automatique d’images ou de liens dans les sorties de l’agent lorsqu’il n’est pas nécessaire.
• Un seul analyseur d’URL. Le filtre et le moteur de rendu doivent partager la même logique d’analyse et de normalisation.
• Surveiller les sorties réseau. Alertez sur les schémas DNS inhabituels, comme des sous-domaines longs ou à forte entropie issus de postes utilisateurs.
• Vérifier l’état du correctif. Salesforce indique que le problème est corrigé côté serveur ; les administrateurs doivent néanmoins revoir les sources de données accessibles à leurs agents.

Statut

Élément	Détail
Produit	Salesforce Agentforce
Découvreur	Zenity Labs
Signalement	1er juin 2026
Correctif confirmé	18 août 2026
Divulgation publique	24 septembre 2026
État du correctif	Corrigé par l’éditeur (Trusted URLs renforcé)
CVE	Aucun cité dans les sources