Un agent LLM qui penteste Salesforce Experience Cloud de bout en bout

De quoi s’agit-il ?

Le 8 juin 2026, l’équipe de recherche de Reco a publié un compte-rendu décrivant un agent LLM autonome qui réalise un audit de sécurité de bout en bout des sites Salesforce Experience Cloud. Vous lui fournissez une URL ; il énumère la surface d’attaque, classe ce qui paraît sensible, fuzze les méthodes côté serveur, écrit un exploit fonctionnel, l’exécute, puis réévalue lui-même la gravité de ses trouvailles — sans aucune intervention humaine une fois la cible définie.

La technique visant la plateforme n’est pas inédite. Depuis septembre 2025, le groupe ShinyHunters exploite la même surface — des profils d’utilisateur invité Experience Cloud mal configurés — en détournant AuraInspector, un outil en ligne de commande publié par Mandiant le 12 janvier 2026 pour aider les défenseurs à repérer les failles de contrôle d’accès. La campagne est devenue publique début mars 2026 et aurait touché 300 à 400 organisations. Ce que la démonstration de Reco ajoute, c’est l’étape suivant la reconnaissance : laisser un modèle, et non un humain, piloter l’analyse et l’exploitation.

Comment ça marche

Experience Cloud expose le framework Salesforce Aura aux visiteurs non authentifiés. Par son intermédiaire, un visiteur externe peut énumérer les objets Salesforce (tables de la base), les méthodes de contrôleur Apex (logique côté serveur), les routes publiques et les fichiers. Les deux faiblesses exploitées sont anciennes et ordinaires : un contrôle d’accès défaillant au niveau objet et enregistrement (classes Apex déclarées without sharing, profils invités trop permissifs, fichiers ContentDocument en visibilité AllUsers) et l’injection SOQL issue de requêtes construites par concaténation de chaînes.

L’agent de Reco n’est pas un script monolithique mais un pipeline agentique de compétences, chacune gérant une phase qu’un pentesteur humain suivrait :

Phase             Ce que fait l'agent
----------------  -----------------------------------------------------------
1. Reconnaissance Énumérer objets, méthodes Apex, routes, fichiers via Aura
2. Analyse objets Classer les tables par sensibilité (Contact, Lead > BlogPost)
3. Fuzzing Apex   Déduire les entrées valides ; sonder l'injection SOQL
4. Exploitation   Écrire un PoC autonome, l'exécuter, valider les données
5. Gravité        Auto-évaluer les trouvailles comme un relecteur sceptique

L’effet de levier se situe aux phases 3 à 5. Le modèle raisonne sur ce qu’une méthode nommée getContactInfo(email) attend, réutilise des enregistrements déjà extraits pour construire des entrées valides, et reconnaît un oracle d’injection à partir d’un changement de comportement dans la réponse. Dans un cas anonymisé, il a trouvé une méthode Apex accessible aux invités qui renvoyait une fiche contact complète — nom, téléphone, fonction, adresse de facturation — pour n’importe quelle adresse e-mail, puis a pivoté de lui-même vers LinkedIn pour récolter des noms d’employés, deviner les schémas d’e-mails d’entreprise (prenom.nom@societe.com) et les valider contre l’endpoint afin de compiler une liste de données personnelles. Les primitives d’exploitation elles-mêmes (extraction SOQL en aveugle booléen, comparaison caractère par caractère avec LIKE) sont publiées de longue date et ne sont pas reproduites ici.

Pourquoi c’est important

Le glissement, comme pour la post-exploitation pilotée par LLM, relève du coût, pas de la capacité. Aucune de ces failles n’est nouvelle ; ce qui coûtait cher, c’était le temps humain pour auditer chaque portail, lire chaque signature de méthode et fabriquer un exploit sur mesure. Un agent ramène ce coût au budget d’inférence — de sorte que la longue traîne de configurations « peu exploitables » que les défenseurs avaient dépriorisées devient économiquement intéressante à attaquer en masse. ShinyHunters a déjà démontré la moitié reconnaissance contre 300 à 400 organisations avec un outil d’audit détourné ; greffer un modèle sur la moitié exploitation est la suite logique.

La seconde propriété est l’exhaustivité. L’agent ne rate pas un seul paramètre injectable parmi des dizaines, ni un fichier confidentiel enfoui parmi des centaines, parce qu’il inspecte tout systématiquement. La « sécurité par l’obscurité » — supposer qu’une méthode ou un fichier exposé est sûr parce qu’il est difficile à trouver — ne tient plus quand celui qui cherche est infatigable et bon marché.

Défenses

1. Utilisez des variables liées en SOQL, jamais la concaténation. WHERE Id = :blogId au lieu de WHERE Id = '' + blogId + ''. Une correction d’un caractère ferme toute la classe d’injection ; les cas de Reco remontaient tous à des requêtes dynamiques construites par concaténation.
2. Auditez les classes Apex without sharing. Les développeurs y recourent parce que « tout fonctionne » ; cela contourne la sécurité au niveau enregistrement. Par défaut, with sharing, et justifiez chaque exception, surtout sur une classe accessible aux invités.
3. Verrouillez les permissions de l’utilisateur invité. Traitez le profil invité comme entièrement hostile. Revoyez les permissions d’objets et de champs, l’accès aux méthodes Apex, et rappelez-vous que « les invités ne voient pas le site » contrôle l’accès aux pages, pas aux enregistrements ni aux fichiers.
4. Corrigez la visibilité des ContentDocument. Réglez ContentDocumentLink.Visibility autrement que sur AllUsers et désactivez « laisser les invités voir les fichiers d’actifs » sauf nécessité réelle. L’agent a trouvé de façon fiable l’unique document confidentiel parmi des centaines de fichiers anodins.
5. Mettez les sites Experience Cloud dans le périmètre. Beaucoup de programmes auditent l’application principale mais pas le portail connecté. Lancez le rapport d’accès invité de Salesforce et AuraInspector de Mandiant contre vos propres sites avant l’agent d’un attaquant.
6. Présumez un sondage automatisé et exhaustif. Les décisions d’acceptation du risque qui jugeaient une faille « peu exploitable » à la main sont périmées ; réévaluez-les face à un adversaire qui teste tout.

Statut

Élément	Référence	Date	Notes
Campagne Aura de ShinyHunters publique	Salesforce / Help Net Security	2026-03	Profils invités mal configurés ; scan depuis sept. 2025
Publication d’AuraInspector	Mandiant	2026-01-12	Outil d’audit défensif, ensuite détourné par les attaquants
Ampleur rapportée	Salesforce Ben	2026-03	ShinyHunters revendique 300 à 400 organisations
Agent d’exploitation autonome	Reco	2026-06-08	Pentest agentique de bout en bout, trouvailles divulguées de façon responsable

Les failles ici relèvent de la configuration et du code, pas d’un zero-day de plateforme, et les trouvailles de Reco ont été divulguées de façon responsable avec des organisations anonymisées. Le point n’est pas une nouvelle vulnérabilité — c’est que l’économie de l’exploitation des anciennes vient de changer.