3 min de lecture
~7 minutes
Un attaquant anonyme remplit un formulaire Web-to-Lead public. Zéro compte, zéro clic. Quand un commercial demande ensuite à Agentforce de passer en revue les leads récents, l’agent exécute les instructions cachées dans le champ, encode vos données de compte dans une requête DNS, et les envoie chez l’attaquant.
Un formulaire public comme porte d’entrée
Sur la plupart des sites B2B, le formulaire Web-to-Lead est l’endroit le moins surveillé du système d’information. Tout le monde peut le remplir. Un prospect, un concurrent qui teste, un bot qui s’ennuie. On valide les champs, on filtre le spam, et on s’arrête là ; ce que devient ce texte une fois dans le CRM, personne ne s’en soucie.
Zenity Labs vient de prouver qu’on avait tort. Leur chaîne, baptisée SalesBleed, démarre dans ce champ rempli sans authentification. Le texte qu’on y glisse ne s’adresse pas au commercial qui lira la fiche : il vise l’agent IA qui passera dessus plus tard.
Note du PandaRedacteur : le formulaire Web-to-Lead a survécu vingt ans sans qu’on le considère comme une surface d’attaque. Il aura suffi d’un agent IA pour transformer le champ “Commentaires” en shell distant.
Ce qui se passe une fois le lead soumis
Rien. Du moins pas tout de suite. La charge dort dans Salesforce au milieu des autres leads, et attend qu’un utilisateur interne demande à Agentforce d’examiner les leads récents ou de préparer un résumé commercial. Ce délai ruine à peu près toute tentative d’attribution : le jour où l’agent exécute, plus personne ne pense au formulaire rempli la veille par un inconnu.
Cette partie part d'abord aux abonnés Substack, avant d'être publiée intégralement ici.
Vecteurs d’attaque
La charge dormante
Une instruction qui patiente jusqu’à son déclencheur, l’offensif connaît ça depuis longtemps. Ce qui me gêne davantage, c’est la frontière traversée au passage, celle qui sépare la “donnée externe non fiable” de la “commande interne fiable”. Le lead entre par l’extérieur, sans authentification. Il ressort traité comme une entrée légitime, simplement parce qu’un utilisateur de confiance a lancé l’agent dessus.
Query Records détourné
Cette partie part d'abord aux abonnés Substack, avant d'être publiée intégralement ici.
Exemple concret : le scénario que Zenity a démontré
Note du PandaRedacteur : relisez l’étape 4. Le commercial n’a rien fait de travers, il a utilisé l’outil exactement comme on le lui a vendu. Sur ce coup-là, la énième session de sensibilisation ne vous sauvera pas.
Analyse STRIDE
Cette partie part d'abord aux abonnés Substack, avant d'être publiée intégralement ici.
Impact potentiel
Cette partie part d'abord aux abonnés Substack, avant d'être publiée intégralement ici.
Mitigations
Cette partie part d'abord aux abonnés Substack, avant d'être publiée intégralement ici.
Quelques références pour aller plus loin
- GBHackers : Salesforce Agentforce Flaw Enables 0-Click Data Exfiltration via Prompt Injection
- OWASP : Top 10 for Large Language Model Applications
- Votre clé API Claude vaut trois fois plus que ce que vous pensez