Comment une seule permission d'édition pouvait détourner tous les chatbots Dialogflow CX d'un projet

De quoi s’agit-il ?

Le 7 juillet 2026, Varonis Threat Labs a divulgué publiquement une faille baptisée Rogue Agent dans Dialogflow CX, la plateforme managée de Google Cloud que de nombreuses organisations utilisent pour construire des chatbots destinés à leurs clients. La découverte, rapportée par Varonis et relayée par The Hacker News, montrait qu’un attaquant disposant de droits d’édition sur un seul agent pouvait prendre le contrôle de tous les chatbots du même projet Google Cloud — lire les conversations en direct, exfiltrer ce que les utilisateurs saisissaient, et faire envoyer aux bots des messages rédigés par l’attaquant, comme de fausses demandes de ressaisie de mot de passe.

Il ne s’agissait pas d’une attaque distante et non authentifiée, et rien n’indique qu’elle ait jamais été exploitée dans la nature. L’exploitation nécessitait la permission dialogflow.playbooks.update sur un agent utilisant la fonctionnalité Playbooks et les Code Blocks personnalisés de Dialogflow, ce qui limite réalistement l’attaquant à un initié malveillant ou à un compte développeur compromis. Varonis a signalé le problème en novembre 2025 ; Google a déployé un premier correctif en avril 2026 et l’a entièrement résolu en juin 2026. Aucun CVE n’a été attribué.

Comment ça marche

Les Code Blocks permettent aux développeurs d’insérer du Python personnalisé dans le flux conversationnel d’un chatbot — pour valider une entrée ou appeler une API. Ce code s’exécute dans un environnement Cloud Run managé par Google, et c’est là qu’est le problème structurel : tous les agents qui utilisent les Code Blocks dans un même projet partagent une seule instance de cet environnement, sans isolation véritable entre les agents.

Lorsqu’un agent exécute un Code Block, l’extrait du développeur est ajouté à du code d’initialisation interne puis passé à la fonction exec() de Python. Varonis a trouvé le fichier qui réalise cet emballage — code_execution_env.py — accessible en écriture dans le conteneur partagé. Parce qu’il était modifiable, un Code Block pouvait l’écraser par une version téléchargée depuis un serveur contrôlé par l’attaquant.

une permission en écriture ──▶ le Code Block écrase le fichier du runtime partagé
                                       │
                                       ▼
        le Code Block de chaque agent exécute désormais le code d'init modifié
        (même portée, même accès à l'historique et à la fonction de réponse)

À partir de là, le runtime modifié s’exécute pour tous les appels de Code Block de tous les agents du projet, dans la même portée que le code légitime. Deux faiblesses connexes aggravaient la situation : le bac à sable disposait d’un accès sortant à Internet sans restriction — contournant les VPC Service Controls et se transformant en canal d’exfiltration et de commande — et pouvait atteindre le service de métadonnées d’instance (IMDS), qui renvoyait un jeton pour un compte de service Google (à faibles privilèges). Cet article ne contient aucun payload opérationnel ; c’est le mécanisme, pas un script, qui est la leçon.

Pourquoi c’est important

L’enseignement inconfortable relève du modèle de privilèges. Ici, une permission qui ressemble à un droit d’édition de contenu — « peut ajouter un Code Block » — était en réalité un droit d’exécution de code dans un runtime que le client ne pouvait ni voir ni contrôler. Pire : le rayon d’impact franchissait les frontières entre agents — un seul agent modifiable compromettait ses voisins via un environnement d’exécution partagé.

Cela met aussi à mal les hypothèses habituelles des défenseurs sur la visibilité. L’écrasement se produisait à l’intérieur de l’environnement managé par Google, et Cloud Logging n’enregistrait ni la modification du fichier ni le code injecté. Un attaquant pouvait même restaurer le Code Block d’origine dans la console pour l’apparence, tandis que le fichier écrasé continuait de s’exécuter en dessous. Quand le runtime est invisible et multi-tenant au sein même de votre propre projet, « le fournisseur dit qu’il n’y a rien à corriger » ne signifie pas « vous êtes en sécurité ».

Défenses

Traitez les permissions d’édition d’agent comme des contrôles de runtime. Si un rôle peut ajouter ou modifier des blocs exécutables, des playbooks ou du code d’outil, cadrez-le comme un droit de déploiement de code, pas comme un droit de contenu. Auditez précisément qui détient dialogflow.playbooks.update (et ses équivalents sur d’autres plateformes) et appliquez le moindre privilège.

Supposez que les runtimes managés partagés ne sont pas isolés jusqu’à preuve du contraire. Quand une plateforme exécute du code client, demandez au fournisseur comment les tenants et les projets sont séparés, si le système de fichiers d’exécution est modifiable, et si un agent peut en affecter un autre. Fondez votre modèle de menace sur les réponses, pas sur le marketing.

Restreignez le trafic sortant et l’accès aux métadonnées. Un bac à sable d’exécution de code ne devrait pas avoir d’accès Internet sortant ouvert ni pouvoir atteindre l’IMDS. Là où la plateforme le permet, restreignez la sortie et bloquez les points de terminaison de métadonnées ; là où elle ne le permet pas, considérez toute donnée touchée par l’agent comme potentiellement exfiltrable et minimisez ce que vous lui fournissez.

Compensez le trou de journalisation par ce que vous pouvez voir. Même si la modification interne au runtime est invisible, les actions de préparation laissent des traces. Examinez les journaux d’audit DATA_WRITE à la recherche de mises à jour de playbooks inattendues, corrélez-les avec des utilisateurs, des IP et des horaires d’accès inhabituels, recherchez les requêtes en échec dont les erreurs révèlent des exceptions de Code Block, et vérifiez périodiquement que chaque Code Block de la console est bien approuvé par vous.

Séparez les projets par frontière de confiance. Comme le rayon d’impact était le projet, placez les chatbots à forte sensibilité dans leur propre projet plutôt que de les co-localiser avec des agents expérimentaux ou moins fiables partageant un runtime.

Statut

Élément	Détail
Produit	Google Cloud Dialogflow CX (Playbooks + Code Blocks personnalisés)
Découvreur	Varonis Threat Labs (« Rogue Agent »)
Prérequis	dialogflow.playbooks.update sur un agent Code Block (initié / dev compromis)
Impact	Prise de contrôle inter-agents dans un projet : vol de conversations, phishing via messages du bot, canal d’exfiltration
Divulgation	Signalé nov. 2025 ; premier correctif avr. 2026 ; résolu juin 2026
CVE	Aucun attribué
Exploitation active	Aucune connue selon Varonis et Google

Cet article résume, à des fins défensives, des recherches publiquement divulguées et corrigées par l’éditeur, et ne contient aucune instruction d’attaque opérationnelle.