Uma falha crítica no Dialogflow CX, do Google, poderia permitir que um atacante com permissão de edição em um agente com Code Block comprometesse outros agentes com Code Block no mesmo projeto do Google Cloud.
A partir daí, seria possível ler conversas em tempo real, roubar os dados compartilhados pelos usuários e fazer os bots enviarem mensagens escritas pelo atacante, inclusive solicitações para que a vítima digitasse novamente uma senha.
A falha foi descoberta pela empresa de segurança Varonis, que a batizou de Rogue Agent.
O problema afetava apenas organizações que criavam agentes com os Playbooks do Dialogflow e Code Blocks personalizados, recurso que permite aos desenvolvedores adicionar seu próprio Python.
Não se tratava de um ataque remoto e sem autenticação.
Para explorar a brecha, era necessário ter a permissão dialogflow.playbooks.update em um desses agentes.
Na prática, isso restringe o cenário a um insider malicioso ou a uma conta de desenvolvedor comprometida, e não a um desconhecido na internet.
Ainda assim, a partir desse único ponto de entrada, o alcance se estendia a todos os agentes do projeto.
O Google já corrigiu o problema, e tanto a Varonis quanto a empresa afirmam não haver indícios de que a falha tenha sido usada em um ataque real.
Um único arquivo gravável executava os Code Blocks de todos os agentes
Os Code Blocks do Dialogflow permitem que desenvolvedores adicionem Python personalizado ao fluxo de conversa de um chatbot para verificar entradas, controlar o comportamento e acionar ferramentas definidas.
Esse código roda em um ambiente Cloud Run gerenciado pelo Google, e todos os agentes que usam Code Blocks no mesmo projeto do Google Cloud compartilham uma única instância desse ambiente.
O Google administra esse ambiente, o cliente não pode vê-lo nem controlá-lo, e a Varonis não encontrou isolamento real entre os agentes dentro dele.
Quando um agente executa um Code Block, o código do desenvolvedor é anexado a um código interno de preparação e passado para a função exec() do Python.
Esse código de preparação define as variáveis e funções que o bloco pode acessar.
Entre as variáveis estão o histórico completo da conversa e o estado da sessão, como o ID da sessão.
Entre as funções está respond(), usada para fazer o bot responder com uma determinada mensagem.
A Varonis encontrou o arquivo responsável por esse empacotamento, code_execution_env.py, no ambiente compartilhado com permissão de escrita.
Como esse arquivo podia ser gravado, um único Code Block era capaz de substituí-lo.
Esse bloco baixava uma versão modificada de code_execution_env.py de um servidor controlado pelo atacante e sobrescrevia o original dentro do contêiner em execução.
A partir daí, a versão do atacante passava a ser executada em todas as execuções de Code Block em todos os agentes que compartilhassem aquele ambiente.
Ela ficava no mesmo escopo do código legítimo, com acesso ao histórico, ao estado e à função respond().
Isso permitia ler cada conversa, enviá-la discretamente ao servidor do atacante e fazer o bot publicar mensagens escritas por ele.
Um exemplo é o phishing: o bot pede ao usuário que revalide o login, e o atacante coleta tudo o que for digitado.
Para encobrir os rastros, o atacante restauraria o Code Block original no console do Dialogflow.
Isso alteraria apenas o que o console exibe, porque o arquivo sobrescrito já estaria em execução no contêiner e continuaria funcionando em segundo plano.
O sandbox também vazava por mais dois caminhos
A Varonis relatou dois problemas relacionados, e nenhum deles exigia sobrescrever o arquivo.
Primeiro, o ambiente de Code Block tinha acesso irrestrito à internet de saída.
Usando a biblioteca nativa urllib, os pesquisadores enviaram dados diretamente para um servidor externo e também puderam receber comandos de volta.
A Varonis afirma que isso contorna o VPC Service Controls, o perímetro do Google Cloud criado para impedir que dados saiam de serviços protegidos.
O ambiente fica fora desse perímetro e consegue acessar a internet aberta, o que o transforma em um canal tanto para roubo de dados quanto para controle remoto.
Segundo, e menos grave, o ambiente expunha o Instance Metadata Service (IMDS), um endpoint normalmente interno que fornece credenciais de cloud.
Ao consultá-lo, foi retornado um token de uma conta de serviço gerenciada pelo Google.
Essa conta tinha poucos privilégios, portanto o risco direto era limitado.
O ponto principal, porém, é que um sandbox de execução de código não deveria conseguir acessar o IMDS.
Quase nada chegou aos logs
A sobrescrita ocorreu dentro do ambiente do Google, onde os clientes não têm visibilidade, e o Cloud Logging não registrou a alteração do arquivo nem o código injetado.
Isso dificulta, embora não impossibilite, a detecção pelo lado do cliente.
As ações de preparação ainda deixam rastros, e as verificações abaixo se apoiam justamente neles.
A Varonis comunicou a falha ao Google por meio do Vulnerability Reward Program em novembro de 2025.
O Google lançou uma correção inicial em abril de 2026 e resolveu totalmente o problema em junho de 2026, cerca de sete meses entre a denúncia e a correção completa.
Nenhum CVE foi atribuído.
O que verificar se você usou Code Blocks
Se você executou agentes do Dialogflow CX com Playbooks e Code Blocks antes da correção e quer confirmar que não foi alvo, comece pelo controle de acesso.
A permissão dialogflow.playbooks.update é o ponto de entrada, então audite quais funções e contas a possuem.
Depois:
- Revise seus logs de auditoria DATA_WRITE para a API do Dialogflow em busca de atualizações inesperadas de playbooks e correlacione esses eventos com usuários incomuns, endereços IP suspeitos ou horários de acesso fora do padrão.
- Execute uma consulta no Cloud Logging para requisições de usuários com falha, pois as mensagens de erro podem revelar exceções geradas por Code Blocks maliciosos.
- No console do Dialogflow, abra os Playbooks de cada agente e confirme se todos os Code Blocks são realmente os que você aprovou.
Um tipo diferente de falha em IA
Muitas falhas recentes de segurança em IA funcionaram enganando o modelo.
Os próprios ataques Reprompt e SearchLeak, da Varonis, transformaram um único clique em roubo de dados no Copilot da Microsoft.
O ForcedLeak, da Noma Security, ocultou instruções em um formulário web do Salesforce para extrair dados do CRM.
Pesquisadores da Microsoft mostraram que a injeção de prompt podia evoluir para execução de código no framework Semantic Kernel.
O Rogue Agent não tocou no modelo em si.
Ele abusou de um recurso normal de desenvolvimento e de um ambiente de execução compartilhado e invisível, acessível com uma permissão comum de edição.
Em um cenário assim, uma permissão que parece apenas servir para editar conteúdo na prática equivale a uma permissão de execução de código.
Quem consegue adicionar um Code Block pode executar Python arbitrário dentro de um ambiente compartilhado que o cliente não consegue inspecionar.
Trate permissões de edição de agentes como o que elas realmente são: controles de execução.
Mesmo quando o provedor diz que nada precisa ser corrigido, os clientes continuam sem qualquer forma de enxergar esse ambiente por conta própria.
Publicidade
Tenha acesso aos melhores hackers éticos do mercado através de um serviço personalizado, especializado e adaptado para o seu negócio. Qualidade, confiança e especialidade em segurança ofensiva de quem já protegeu centenas de empresas. Saiba mais...