Permissão de edição em um único agente com Playbooks e Code Blocks abria caminho para leitura de conversas, exfiltração de dados e mensagens maliciosas em todo o ambiente compartilhado do projeto Google Cloud
| Componente | Google Dialogflow CX com Playbooks e Code Blocks personalizados em Python, executados em ambiente Cloud Run compartilhado por todos os agentes do mesmo projeto Google Cloud |
| Vetor | Conta com permissão dialogflow.playbooks.update em um agente que usa Code Blocks; sobrescrita do arquivo code_execution_env.py no runtime compartilhado, com vetores auxiliares de saída irrestrita para internet e acesso ao IMDS |
| Impacto | Leitura de conversas ativas, coleta de dados fornecidos pelos usuários, envio de mensagens controladas pelo invasor — incluindo solicitações de reautenticação — e canal de exfiltração que contornava VPC Service Controls |
| Prioridade | Confirmar aplicação da correção de junho de 2026, auditar titulares de dialogflow.playbooks.update, revisar logs DATA_WRITE da API Dialogflow e inspecionar manualmente todos os Code Blocks aprovados nos Playbooks |
| Versões | Agentes com Code Block Playbooks anteriores à correção completa de junho de 2026; correção inicial em abril de 2026 |
| Mitigação | Google corrigiu a falha após divulgação via Vulnerability Reward Program em novembro de 2025; nenhum CVE atribuído; sem evidência de exploração em ambiente real segundo Google e Varonis |
Pesquisadores da Varonis identificaram uma falha crítica no Google Dialogflow CX, batizada de Rogue Agent, que transformava uma permissão aparentemente limitada de edição de conteúdo em controle efetivo sobre todos os chatbots de um mesmo projeto Google Cloud. O problema afetava exclusivamente organizações que construíram agentes com Playbooks contendo Code Blocks personalizados em Python — um recurso que permite inserir lógica própria no fluxo conversacional para validar entradas ou chamar APIs externas.
A exploração não era remota nem anônima. Era necessária a permissão dialogflow.playbooks.update em pelo menos um agente que utilizasse Code Blocks, o que restringe o cenário realista a insider malicioso ou conta de desenvolvedor comprometida. A partir desse único ponto de apoio, porém, o alcance se estendia a cada agente do projeto que compartilhasse o mesmo ambiente de execução. O invasor podia ler conversas em andamento, extrair dados compartilhados pelos usuários e fazer os bots enviarem mensagens arbitrárias — inclusive pedidos para o usuário digitar novamente credenciais. A Google corrigiu o problema, e tanto a fabricante quanto a Varonis afirmam não haver indícios de uso em ataque real. Nenhum identificador CVE foi atribuído à falha.
Os Code Blocks do Dialogflow CX executam código Python em um ambiente Cloud Run gerenciado pela Google. Agentes distintos dentro do mesmo projeto Google Cloud que utilizam Code Blocks compartilham uma única instância desse ambiente — infraestrutura invisível e incontrolável pelo cliente. A Varonis constatou ausência de isolamento efetivo entre agentes nesse runtime compartilhado.
Quando um Code Block é acionado, o código do desenvolvedor é concatenado a um trecho interno de configuração e passado à função exec() do Python. Esse código de configuração define variáveis acessíveis ao bloco — incluindo o histórico completo da conversa e o estado da sessão, como o identificador de sessão — e funções como respond(), que pública a resposta do bot. O arquivo responsável por esse empacotamento, code_execution_env.py, residia no ambiente compartilhado com permissão de escrita.
Um único Code Block malicioso podia substituir esse arquivo: o bloco baixava uma versão modificada de code_execution_env.py de um servidor controlado pelo invasor e sobrescrevia o original dentro do contêiner em execução. A partir daí, a versão adulterada passava a ser invocada em toda execução de Code Block de todos os agentes que compartilhavam aquele ambiente, operando no mesmo escopo do código legítimo com acesso a history, state e respond(). Isso permitia ler cada conversa, enviá-la silenciosamente a infraestrutura externa e injetar mensagens no fluxo — por exemplo, solicitando ao usuário que revalidasse o login enquanto o invasor capturava o que fosse digitado.
Para encobrir a ação, o invasor podia restaurar o Code Block original no console do Dialogflow. Essa reversão alterava apenas o que o console exibia; o arquivo já sobrescrito no contêiner continuava ativo e executando. A alteração ocorria dentro do ambiente gerenciado pela Google, sem registro no Cloud Logging da troca de arquivo ou do código injetado, o que dificultava a detecção pelo lado do cliente.
Além da sobrescrita de arquivo, a Varonis documentou dois problemas correlatos que não dependiam dessa técnica. O ambiente de Code Blocks possuía acesso de saída irrestrito à internet: usando a biblioteca urllib integrada, os pesquisadores enviaram dados diretamente a um servidor externo e receberam comandos de retorno. Esse comportamento contornava VPC Service Controls, o perímetro do Google Cloud destinado a impedir a saída de dados de serviços protegidos, porque o runtime ficava fora desse perímetro e alcançava a internet aberta. O segundo achado, de severidade menor, expunha o Instance Metadata Service: consultas ao endpoint interno retornavam token de uma conta de serviço gerenciada pela Google, de privilégio reduzido — mas ainda assim representando falha de isolamento, já que um sandbox de execução de código não deveria alcançar o IMDS.
A falha incidia sobre a interseção entre Dialogflow CX, Playbooks com Code Blocks e a arquitetura de runtime compartilhado por projeto. Organizações que não utilizavam Code Blocks personalizados ficavam fora do escopo. Da mesma forma, contas sem dialogflow.playbooks.update em nenhum agente vulnerável não tinham vetor de entrada para a cadeia principal.
O impacto potencial abrangia todos os agentes do projeto que compartilhavam o ambiente Cloud Run, não apenas o agente onde a permissão foi exercida. Conversas ativas, dados inseridos pelos usuários durante o atendimento e a integridade das respostas do bot ficavam expostos. O canal de saída irrestrito ampliava o risco para qualquer dado processado dentro dos Code Blocks, independentemente da sobrescrita do arquivo de configuração.
- Projetos Google Cloud com múltiplos agentes Dialogflow CX usando Code Blocks no mesmo runtime compartilhado
- Contas e papéis IAM com dialogflow.playbooks.update em agentes que empregam Playbooks com Python personalizado
- Fluxos conversacionais que tratam credenciais, dados pessoais ou informações corporativas sensíveis via chatbot
- Ambientes que dependem de VPC Service Controls para restringir exfiltração a partir de serviços Google Cloud gerenciados
A ausência de registro no Cloud Logging para a troca de code_execution_env.py ou para o código injetado limita a visibilidade direta sobre a exploração da sobrescrita de arquivo. A detecção depende de correlacionar sinais periféricos: permissões, auditoria de API e anomalias no comportamento dos agentes. A permissão dialogflow.playbooks.update constitui o ponto de entrada inteiro da cadeia — qualquer titular dessa permissão em agentes com Code Blocks deve ser tratado como potencial operador de código arbitrário no runtime compartilhado.
Antes da correção, equipes que operavam agentes com Code Block Playbooks e desejavam verificar se houve tentativa de abuso devem priorizar a revisão de acessos e a inspeção manual dos blocos configurados.
- Auditar papéis e contas com dialogflow.playbooks.update, correlacionando usuários incomuns, endereços IP atípicos ou horários de acesso fora do padrão
- Consultar logs de auditoria DATA_WRITE da API Dialogflow em busca de atualizações inesperadas de playbooks
- Executar consultas no Cloud Logging sobre requisições de usuário com falha, cujas mensagens de erro podem revelar exceções lançadas por Code Blocks maliciosos
- Abrir Playbooks de cada agente no console Dialogflow e confirmar que todo Code Block corresponde a código previamente aprovado pela equipe
- Monitorar padrões de saída de rede anômalos originados do ambiente de execução de Code Blocks, quando telemetria de rede estiver disponível no perímetro do projeto
A Varonis divulgou a falha pelo Vulnerability Reward Program da Google em novembro de 2025. A Google publicou correção inicial em abril de 2026 e encerrou a resolução completa em junho de 2026, intervalo de aproximadamente sete meses entre o relatório e o fechamento. Organizações que operaram agentes com Code Block Playbooks antes da correção de junho devem validar que o ambiente recebeu a atualização e não confiar apenas na ausência de alertas visíveis no console.
A lição arquitetural transcende este incidente isolado. Em plataformas de agentes conversacionais, uma permissão classificada como edição de conteúdo pode equivaler a direito de execução de código em runtime opaco e compartilhado. Mesmo após a correção do fornecedor, o cliente permanece sem capacidade de inspecionar diretamente o interior desse ambiente. Tratar permissões de edição de agentes como controles de runtime — e não como simples direitos editoriais — é requisito para reduzir a superfície em cenários semelhantes.
- Confirmar aplicação da correção de junho de 2026 em todos os projetos que utilizam Dialogflow CX com Code Blocks
- Revisar e restringir dialogflow.playbooks.update ao conjunto mínimo de contas e papéis estritamente necessários
- Implementar revisão periódica dos Code Blocks em Playbooks, comparando o conteúdo visível no console com registros de controle de versão internos
- Correlacionar logs DATA_WRITE e falhas de requisição para detectar atividade de configuração ou execução anômala em agentes críticos
- Reavaliar fluxos conversacionais que solicitam credenciais ou dados sensíveis, considerando que a integridade das respostas do bot pode ter sido comprometida em ambientes afetados antes da correção
0 Comentários