Cómo un solo permiso de edición podía secuestrar todos los chatbots de Dialogflow CX de un proyecto

¿Qué es esto?

El 7 de julio de 2026, Varonis Threat Labs divulgó públicamente una falla que bautizó como Rogue Agent en Dialogflow CX, la plataforma gestionada de Google Cloud que muchas organizaciones utilizan para construir chatbots de cara al cliente. El hallazgo, reportado por Varonis y cubierto por The Hacker News, mostraba que un atacante con derechos de edición sobre un único agente podía tomar el control de todos los chatbots del mismo proyecto de Google Cloud: leer conversaciones en vivo, exfiltrar lo que los usuarios escribían y hacer que los bots enviaran mensajes redactados por el atacante, como falsas solicitudes de reingreso de contraseña.

No se trataba de un ataque remoto y no autenticado, y no hay evidencia de que se explotara alguna vez en la práctica. La explotación requería el permiso dialogflow.playbooks.update sobre un agente que usara la función Playbooks y los Code Blocks personalizados de Dialogflow, lo que limita de forma realista al atacante a un infiltrado malicioso o una cuenta de desarrollador comprometida. Varonis reportó el problema en noviembre de 2025; Google desplegó una primera corrección en abril de 2026 y lo resolvió por completo en junio de 2026. No se asignó ningún CVE.

Cómo funciona

Los Code Blocks permiten a los desarrolladores insertar Python personalizado en el flujo conversacional de un chatbot, para validar una entrada o llamar a una API. Ese código se ejecuta en un entorno Cloud Run gestionado por Google, y ahí está el problema estructural: todos los agentes que usan Code Blocks en un mismo proyecto comparten una única instancia de ese entorno, sin aislamiento real entre los agentes.

Cuando un agente ejecuta un Code Block, el fragmento del desarrollador se añade a código de inicialización interno y se pasa a la función exec() de Python. Varonis encontró el archivo que realiza ese envoltorio —code_execution_env.py— con permiso de escritura dentro del contenedor compartido. Al ser modificable, un Code Block podía sobrescribirlo con una versión descargada desde un servidor controlado por el atacante.

un permiso de escritura ──▶ el Code Block sobrescribe el archivo del runtime compartido
                                       │
                                       ▼
        el Code Block de cada agente ejecuta ahora el código de init modificado
        (mismo alcance, mismo acceso al historial y a la función de respuesta)

A partir de ahí, el runtime modificado se ejecuta para todas las llamadas de Code Block de todos los agentes del proyecto, en el mismo alcance que el código legítimo. Dos debilidades relacionadas lo empeoraban: el entorno aislado tenía acceso saliente a Internet sin restricciones —eludiendo los VPC Service Controls y convirtiéndose en un canal de exfiltración y de comando— y podía alcanzar el Servicio de Metadatos de Instancia (IMDS), que devolvía un token de una cuenta de servicio gestionada por Google (de bajos privilegios). Este artículo no contiene ningún payload operativo; la lección es el mecanismo, no un script.

Por qué importa

La conclusión incómoda es de modelo de privilegios. Aquí, un permiso que parece un derecho de edición de contenido —«puede añadir un Code Block»— era en realidad un derecho de ejecución de código dentro de un runtime que el cliente no podía ver ni controlar. Peor aún: el radio de impacto cruzaba las fronteras entre agentes: un único agente modificable comprometía a sus vecinos a través de un entorno de ejecución compartido.

También rompe las suposiciones habituales de los defensores sobre la visibilidad. La sobrescritura ocurría dentro del entorno gestionado por Google, y Cloud Logging no registraba ni el cambio del archivo ni el código inyectado. Un atacante podía incluso restaurar el Code Block original en la consola para guardar las apariencias, mientras el archivo sobrescrito seguía ejecutándose por debajo. Cuando el runtime es invisible y multiinquilino dentro de tu propio proyecto, «el proveedor dice que no hay nada que corregir» no equivale a «estás a salvo».

Defensas

Trata los permisos de edición de agentes como controles de runtime. Si un rol puede añadir o modificar bloques ejecutables, playbooks o código de herramientas, encuádralo como un derecho de despliegue de código, no de contenido. Audita con precisión quién posee dialogflow.playbooks.update (y sus equivalentes en otras plataformas) y aplica el mínimo privilegio.

Asume que los runtimes gestionados compartidos no están aislados hasta que se demuestre lo contrario. Cuando una plataforma ejecuta código del cliente, pregunta al proveedor cómo se separan los inquilinos y los proyectos, si el sistema de archivos de ejecución es modificable y si un agente puede afectar a otro. Basa tu modelo de amenazas en las respuestas, no en el marketing.

Restringe la salida y el acceso a metadatos. Un entorno aislado de ejecución de código no debería tener acceso saliente abierto a Internet ni poder alcanzar el IMDS. Donde la plataforma lo permita, restringe la salida y bloquea los endpoints de metadatos; donde no, considera cualquier dato que toque el agente como potencialmente exfiltrable y minimiza lo que le entregas.

Compensa el vacío de registro con lo que sí puedes ver. Aunque el cambio interno al runtime sea invisible, las acciones de preparación dejan rastros. Revisa los registros de auditoría DATA_WRITE en busca de actualizaciones de playbooks inesperadas, correlaciónalas con usuarios, IP y horarios de acceso inusuales, consulta las solicitudes fallidas cuyos errores revelen excepciones de Code Blocks, y confirma periódicamente que cada Code Block de la consola sea uno que hayas aprobado.

Separa los proyectos por frontera de confianza. Como el radio de impacto era el proyecto, coloca los chatbots más sensibles en su propio proyecto en lugar de coubicarlos con agentes experimentales o de menor confianza que compartan un runtime.

Estado

Elemento	Detalle
Producto	Google Cloud Dialogflow CX (Playbooks + Code Blocks personalizados)
Descubridor	Varonis Threat Labs («Rogue Agent»)
Requisito	dialogflow.playbooks.update sobre un agente con Code Block (infiltrado / dev comprometido)
Impacto	Toma de control entre agentes en un proyecto: robo de conversaciones, phishing vía mensajes del bot, canal de exfiltración
Divulgación	Reportado nov. 2025; primera corrección abr. 2026; resuelto jun. 2026
CVE	Ninguno asignado
Explotación activa	Ninguna conocida según Varonis y Google

Este artículo resume, con fines defensivos, investigación divulgada públicamente y corregida por el proveedor, y no contiene instrucciones operativas de ataque.