A vulnerabilidade combinava criação permitida de arquivos, validação insuficiente no find_by_name e execução antecipada da busca antes das restrições do Strict Mode.
| Componente | IDE agentivo Google Antigravity, especificamente a ferramenta nativa find_by_name, o parâmetro Pattern e o uso subjacente do utilitário fd. |
| Vetor | Injeção de prompt direta ou indireta capaz de fazer o agente criar um arquivo no workspace e depois acionar uma busca manipulada antes da aplicação efetiva das restrições do Strict Mode. |
| Impacto | Execução arbitrária de binários ou scripts contra arquivos do workspace quando opções indevidas eram repassadas ao fd por falta de validação estrita da entrada. |
| Prioridade | Aplicar a correção disponibilizada pelo Google, tratar conteúdo externo como não confiável e revisar agentes que executam ferramentas locais com parâmetros derivados de texto ingerido. |
| Mitigação | A falha foi reportada em 7 de janeiro de 2026 e corrigida em 28 de fevereiro de 2026. |
| Artefatos | find_by_name, Pattern, fd, Strict Mode, criação de arquivo no workspace e busca de arquivos como etapa de acionamento. |
O Google corrigiu uma vulnerabilidade no Antigravity, um ambiente integrado de desenvolvimento com recursos agentivos, que permitia transformar uma operação aparentemente restrita de busca de arquivos em execução de código. O problema não dependia de uma falha isolada de permissão ampla; a cadeia surgia da combinação entre uma ação permitida ao agente, a criação de arquivos no workspace, e a validação insuficiente de entrada na ferramenta nativa find_by_name. O parâmetro Pattern, destinado a receber padrões de nomes de arquivos e diretórios, podia carregar opções interpretadas pelo utilitário subjacente fd, abrindo espaço para execução de binários contra arquivos encontrados.
O ponto crítico era a ordem de execução. A chamada ao find_by_name ocorria antes de as restrições associadas ao Strict Mode serem efetivamente aplicadas. Esse modo foi descrito como uma configuração de segurança destinada a restringir acesso de rede, impedir escrita fora do workspace e garantir execução de comandos dentro de um contexto de sandbox. Na prática, porém, a busca manipulada era tratada como invocação nativa da própria ferramenta, e não como uma ação bloqueada pelas políticas posteriores. Essa diferença entre intenção de segurança e fronteira real de execução criou uma passagem para que instruções injetadas em conteúdo externo fossem convertidas em comportamento operacional do agente.
A falha é relevante para equipes que estão avaliando IDEs com agentes de IA porque demonstra um padrão recorrente: ferramentas concebidas para operações limitadas deixam de ser limitadas quando recebem parâmetros sem normalização, validação e separação rígida entre dado e instrução. O risco não está apenas no texto malicioso em si, mas na capacidade do agente de transformar esse texto em chamadas a ferramentas locais com acesso ao workspace. Quando o agente também possui permissões para criar arquivos, a cadeia passa a ter uma etapa de preparação e uma etapa de acionamento, ambas dentro de atividades que podem parecer compatíveis com um fluxo normal de desenvolvimento.
A exploração descrita parte de uma condição simples: o agente processa conteúdo controlado por um atacante, seja por uma interação direta com uma instrução maliciosa, seja por uma injeção indireta escondida em um arquivo trazido de uma origem não confiável. Esse conteúdo pode instruir o agente a preparar um arquivo dentro do workspace, aproveitando uma capacidade permitida do Antigravity. Em seguida, a mesma cadeia direciona a ferramenta find_by_name a executar uma busca em que o parâmetro Pattern não se limita a um padrão de nome, mas influencia a linha de invocação do fd. O detalhe operacional de payload foi omitido, mas o efeito técnico confirmado é o uso de uma opção de execução em lote do utilitário de busca para acionar binários ou scripts sobre arquivos correspondentes.
O desenho defensivo esperado seria que uma busca de arquivos aceitasse somente padrões de busca e rejeitasse qualquer entrada com semântica de opção, controle de execução ou metacaracteres relevantes para o programa chamado. A falha ocorria porque a entrada era repassada ao componente subjacente sem uma validação estrita suficiente. Assim, a ferramenta de busca deixava de ser apenas uma consulta passiva sobre nomes de arquivos e passava a carregar significado operacional para o binário chamado. Em um agente de IA, esse tipo de bug é agravado porque a origem da entrada pode ser um documento, comentário ou arquivo aparentemente benigno, e não necessariamente uma ação explícita de um usuário tentando executar código.
A variante indireta é particularmente importante para AppSec e engenharia de plataforma. Nela, o atacante não precisa comprometer a conta do usuário nem assumir controle prévio do ambiente. O usuário pode apenas importar, abrir ou sincronizar um arquivo de origem não confiável que contenha comentários ocultos ou instruções estruturadas para o agente. Quando o agente interpreta esse conteúdo como tarefa válida, ele pode encadear a criação do artefato local e a busca manipulada sem uma nova decisão humana no momento crítico. O problema expõe a fragilidade de controles baseados na expectativa de que o operador perceberá uma ação suspeita, pois agentes autônomos podem executar etapas intermediárias em alta velocidade e com baixa visibilidade contextual.
O caso também se encaixa em um conjunto mais amplo de falhas observadas em ferramentas de desenvolvimento e automação assistidas por IA. Foram descritos ataques em fluxos de revisão de código, ações de GitHub, agentes que processam comentários de issues e pull requests, sistemas que mantêm memória entre sessões e ferramentas que consomem dados externos com acesso a segredos ou recursos de execução. Em todos esses exemplos, o padrão técnico é semelhante: dados não confiáveis são tratados como instruções por um agente que possui ferramentas, identidade, permissões ou acesso local suficientes para produzir impacto real.
A superfície principal envolve instalações do Antigravity que tenham executado versões anteriores à correção de 28 de fevereiro de 2026 e que usem o Strict Mode como barreira de contenção para operações agentivas. O risco se concentra em workspaces onde o agente pode criar arquivos e depois acionar a ferramenta find_by_name com entrada derivada de conteúdo externo. Repositórios clonados de terceiros, exemplos de código recebidos de canais externos, arquivos com comentários extensos, documentação importada e materiais copiados para dentro do projeto são entradas relevantes porque podem carregar instruções ocultas destinadas ao agente, ainda que pareçam dados comuns para o desenvolvedor.
Ambientes de desenvolvimento com segredos locais, chaves em variáveis de ambiente, tokens em arquivos de configuração, credenciais de repositório, chaves de assinatura ou acesso a pipelines são mais sensíveis, mesmo quando a falha documentada se limita à execução de código no contexto do workspace e do host do desenvolvedor. O material analisado não confirma exfiltração para essa falha específica do Antigravity, portanto o impacto deve ser tratado como execução local condicionada às permissões do processo e ao conteúdo acessível naquele ambiente. A prioridade defensiva é reduzir a capacidade de um agente converter texto externo em chamadas de ferramenta com efeitos colaterais, especialmente quando essas chamadas ocorrem antes da aplicação completa de políticas de sandbox.
- IDE Google Antigravity com a falha ainda não corrigida antes de 28 de fevereiro de 2026.
- Workspaces onde o agente tinha permissão para criar arquivos e acionar buscas por nome.
- Arquivos importados de origem não confiável contendo instruções ocultas para o agente.
- Uso do Strict Mode como principal barreira de segurança para restringir rede, escrita fora do workspace e execução em sandbox.
A detecção deve se concentrar na diferença entre uma busca legítima e uma busca que altera o comportamento do utilitário subjacente. Em logs do próprio IDE, registros de ferramentas agentivas e trilhas de auditoria de automação, equipes devem procurar chamadas ao find_by_name com valores de Pattern incompatíveis com padrões normais de nome de arquivo. Entradas que se parecem com opções de linha de comando, acionamento de execução, encadeamento de ações ou uso incomum de caracteres de controle devem ser tratadas como suspeitas. Quando houver telemetria de processo no endpoint, a criação de processos filhos a partir do fluxo do IDE ou do utilitário fd durante uma operação de busca merece investigação.
No endpoint, o hunting deve correlacionar três eventos: criação recente de arquivo pelo processo do IDE ou agente, chamada subsequente à ferramenta de busca e execução de um interpretador, binário local ou script no mesmo intervalo temporal. A ausência de um comando interativo explícito do usuário não reduz a gravidade, pois o cenário relevante é justamente a execução mediada por agente. Em repositórios e workspaces, vale revisar arquivos recém-importados que contenham comentários longos, texto oculto, instruções dirigidas a assistentes de IA ou conteúdo que tente redefinir regras de execução. Esses sinais não provam exploração por si só, mas ajudam a separar atividade de desenvolvimento normal de uma cadeia de injeção indireta.
Para equipes que administram agentes de código, a telemetria também deve registrar qual conteúdo foi ingerido antes de cada chamada de ferramenta, quais permissões estavam ativas e se a ferramenta executada possui efeitos colaterais. Essa rastreabilidade é essencial porque ataques de injeção de prompt raramente deixam um único indicador de rede ou hash estável. O comportamento suspeito aparece mais claramente na sequência de decisões: texto não confiável entra no contexto do agente, o agente prepara um artefato local, uma ferramenta de busca recebe parâmetro anômalo e o host executa algo que uma busca passiva não deveria executar.
- Chamadas ao
find_by_namecomPatterncontendo semântica de opção ou execução, em vez de simples padrão de nome. - Processos filhos iniciados durante operações de busca de arquivos pelo IDE, pelo agente ou pelo utilitário
fd. - Criação de arquivo no workspace imediatamente antes de uma busca anômala acionada por agente.
- Arquivos externos com comentários ou instruções ocultas voltadas a assistentes de IA.
- Diferença entre ações aprovadas pelo usuário e ações encadeadas automaticamente após ingestão de conteúdo não confiável.
A ação principal é garantir que o Antigravity esteja em versão corrigida, considerando a atualização disponibilizada em 28 de fevereiro de 2026. Em paralelo, equipes devem revisar a configuração de agentes de desenvolvimento para limitar ferramentas com efeitos colaterais, registrar chamadas de ferramenta e impedir que parâmetros vindos de conteúdo não confiável sejam repassados diretamente a utilitários locais. Para ferramentas internas, a correção técnica deve incluir listas de permissões de argumentos, separação explícita entre padrões de busca e opções de execução, rejeição de entradas ambíguas e uso de APIs estruturadas quando possível, em vez de composição de comandos por texto.
A contenção operacional deve assumir que repositórios, documentos, comentários e tickets podem carregar instruções hostis para agentes. Workspaces usados com assistentes de IA não devem conter segredos persistentes desnecessários, e tokens de desenvolvimento devem ter escopo mínimo, expiração curta e rotação viável. Quando houver suspeita de exploração, a resposta deve preservar logs do IDE, histórico de chamadas de ferramenta, eventos de processo e arquivos recém-criados no workspace. Em seguida, a equipe deve isolar o ambiente afetado, remover artefatos suspeitos, rotacionar credenciais potencialmente acessíveis e reconstruir o workspace a partir de uma origem confiável.
A lição técnica para engenharia é tratar agentes como orquestradores de ferramentas, não como simples interfaces de texto. Uma política de sandbox só é efetiva quando cobre a primeira chamada perigosa, não apenas comandos posteriores. Ferramentas de busca, revisão, automação de pull request, leitura de comentários, acesso a memória e integração com sistemas externos precisam separar dados de instruções em todas as camadas. Isso inclui sanitização de entrada, validação de parâmetros, bloqueio de opções não esperadas, observabilidade de chamadas e testes adversariais com conteúdo externo malicioso em ambientes controlados.
- Atualizar o Antigravity para a versão que contém a correção de 28 de fevereiro de 2026.
- Bloquear repasse direto de parâmetros não validados de agentes para ferramentas locais como
fd. - Registrar chamadas de ferramentas agentivas com origem do conteúdo, parâmetros e processos derivados.
- Remover segredos persistentes de workspaces usados por agentes e reduzir privilégios de tokens locais.
- Investigar qualquer execução de processo associada a operações de busca de arquivos em períodos anteriores à atualização.
- Testar ferramentas internas de IA contra injeção indireta em comentários, documentos, issues, pull requests e arquivos importados.
0 Comentários