Un defecto crítico en Dialogflow CX de Google podría haber permitido que un atacante con derechos de edición en un agente habilitado para Code Block comprometiera a otros agentes habilitados para Code Block en el mismo proyecto de Google Cloud.
Desde allí, podían leer conversaciones en vivo, robar los datos compartidos por los usuarios y hacer que los bots enviaran mensajes escritos por los atacantes, incluidas solicitudes para volver a ingresar una contraseña.
Empresa de seguridad varonis Lo encontró y lo nombró Agente rebelde. La falla afectó solo a las organizaciones que crearon agentes con los Playbooks de Dialogflow y bloques de código personalizados, que permitieron a los desarrolladores agregar su propio Python. Y no fue un ataque remoto y no autenticado.
Para lograrlo, se necesitaba el permiso dialogflow.playbooks.update en uno de esos agentes, lo que limita al atacante realista a un interno malicioso o una cuenta de desarrollador comprometida, no a un extraño en Internet. Sin embargo, desde ese único punto de apoyo, el alcance se extendió a todos los agentes del proyecto.
Google lo ha solucionado, y tanto Varonis como Google dicen que no hay señales de que la falla haya sido utilizada alguna vez en un ataque real.
Un archivo grabable ejecutó los bloques de código de cada agente
Los bloques de código de Dialogflow permiten a los desarrolladores agregar Python personalizado al flujo de conversación de un chatbot para verificar la entrada, controlar el comportamiento e invocar herramientas definidas. Ese código se ejecuta en un entorno Cloud Run administrado por Google y cada agente que usa bloques de código en el mismo proyecto de Google Cloud comparte una instancia del mismo.
Google maneja ese entorno, el cliente no puede verlo ni controlarlo, y Varonis no encontró un aislamiento real entre los agentes dentro de él.
Cuando un agente ejecuta un bloque de código, el código del desarrollador se agrega al código de configuración interno y se pasa a la función exec() de Python. Ese código de configuración define las variables y funciones que el bloque puede tocar. Las variables incluyen el historial de la conversación completa y el estado de los detalles de la sesión, como el ID de la sesión. Las funciones incluyen responder(), que hace que el bot responda con una cadena determinada.
Varonis encontró el archivo que realiza este ajuste, code_execution_env.py, en el entorno compartido con acceso de escritura.
Como ese archivo se podía escribir, un solo bloque de código podría reemplazarlo. Ese bloque descarga un code_execution_env.py modificado desde un servidor controlado por un atacante y sobrescribe el original dentro del contenedor en ejecución.
A partir de ese momento, la versión del atacante se ejecuta para cada ejecución de bloque de código en cada agente que comparte ese entorno. Se encuentra en el mismo alcance que el código legítimo, con el mismo acceso al historial, estado y respuesta().
Eso le permite leer cada conversación, enviarla silenciosamente al servidor del atacante y hacer que el bot publique mensajes escritos por el atacante. Un ejemplo es el phishing: el bot le pide al usuario que vuelva a verificar su inicio de sesión y el atacante recopila todo lo que escribe.
Para cubrir las pistas, el atacante restaura el bloque de código original en la consola de Dialogflow. Eso cambia sólo lo que muestra la consola; el archivo sobrescrito ya se está ejecutando en el contenedor y sigue ejecutándose debajo.
La caja de arena se filtró de dos maneras más
Varonis informó dos problemas relacionados y ninguno necesitaba sobrescribir el archivo. Primero, el entorno Code Block tenía acceso saliente a Internet sin restricciones. Utilizando la biblioteca urllib incorporada, los investigadores enviaron datos directamente a un servidor externo y pudieron recibir comandos.
Varonis dice que esto pasa por alto los controles de servicio de VPC, el perímetro de Google Cloud destinado a evitar que los datos abandonen los servicios protegidos. El entorno se encuentra fuera de ese perímetro y puede llegar a Internet abierto, lo que lo convierte en un canal tanto para el robo de datos como para el control remoto.
En segundo lugar, y menos grave, el entorno expuso el Servicio de Metadatos de Instancia (IMDS), un punto final normalmente interno que entrega credenciales de nube. Al consultarlo se devolvió un token para una cuenta de servicio administrada por Google.
Esa cuenta tenía pocos privilegios, por lo que el riesgo directo era limitado; El verdadero punto es que un entorno limitado de ejecución de código no debería poder llegar a IMDS en absoluto.
Casi nada llegó a los registros.
La sobrescritura se produjo dentro del entorno de Google, donde los clientes no tienen visibilidad y Cloud Logging no registró el cambio de archivo ni el código inyectado.
Eso hace que sea difícil, aunque no imposible, captar la situación por parte del cliente. Las acciones de configuración aún dejan rastros, en los que se basan las comprobaciones siguientes.
Varonis reveló la falla a través del Programa de recompensa por vulnerabilidades de Google en noviembre de 2025. Google envió una solución inicial en abril de 2026 y la resolvió por completo en junio de 2026, aproximadamente siete meses desde el informe hasta la resolución. No se asignó ningún CVE.
Qué verificar si usaste bloques de código
Si ejecutó agentes de Dialogflow CX con Code Block Playbooks antes de la solución y desea confirmar que no fue el objetivo, comience con el acceso.
El permiso dialogflow.playbooks.update es el punto de entrada completo, así que audite qué roles y cuentas lo tienen.
Entonces:
- Revise sus registros de auditoría DATA_WRITE para la API de Dialogflow en busca de actualizaciones inesperadas del manual y correlacione con usuarios, direcciones IP u tiempos de acceso inusuales.
- Ejecute una consulta de Cloud Logging para solicitudes fallidas de usuarios, donde los mensajes de error pueden revelar excepciones generadas por bloques de código maliciosos.
- En la consola de Dialogflow, abra Playbooks para cada agente y confirme que cada bloque de código sea uno que haya aprobado.
Un tipo diferente de falla de la IA
Muchas fallas de seguridad recientes de la IA han funcionado engañando al modelo.
El propio Reprompt y SearchLeak de Varonis convirtieron un solo clic en robo de datos en Copilot de Microsoft. ForcedLeak de Noma Security ocultó instrucciones en un formulario web de Salesforce para extraer datos de CRM.
Los investigadores de Microsoft demostraron una inyección rápida convirtiéndose en ejecución de código en el marco del kernel semántico. Rogue Agent no tocó el modelo en absoluto. Abusó de una característica normal del desarrollador y de un tiempo de ejecución invisible y compartido, al que se puede acceder con un permiso de edición normal.
En una configuración como esta, un permiso que parece un derecho de edición de contenido es en realidad un derecho de ejecución de código. Cualquiera que pueda agregar un bloque de código puede ejecutar Python arbitrario dentro de un entorno compartido que el cliente no puede inspeccionar.
Trate los permisos de edición del agente como los controles de tiempo de ejecución que son. Incluso cuando el proveedor dice que no es necesario arreglar nada, los clientes todavía no tienen forma de mirar dentro de ese tiempo de ejecución por sí mismos.
