Dez das onze ferramentas mais populares de IA para código aberto possuem uma falha que permite executar comandos destrutivos no seu computador. O problema não está nos modelos de IA. Está no filtro de segurança que deveria impedir comandos perigosos de chegar ao terminal — e falha por um truque de shell que existe há décadas. A pesquisa, publicada pela Adversa AI em 30 de junho, recebeu o nome de GuardFall.

O que é o GuardFall

Assistentes de código como Cline, Goose, Aider e Roo-Code funcionam assim: o modelo de IA lê o seu repositório, propõe alterações e executa comandos no terminal com os seus privilégios totais — incluindo acesso a chaves SSH, credenciais de nuvem e tudo que está na sua pasta home. Para evitar desastres, essas ferramentas incluem um filtro que bloqueia comandos perigosos. O filtro compara o texto do comando contra uma lista de padrões proibidos — um denylist baseado em regex.

O problema é que o filtro inspeciona o texto bruto, mas o bash reescreve esse texto antes de executá-lo. O shell remove aspas, expande variáveis e processa atalhos. O filtro e o shell acabam olhando para duas coisas diferentes. O exemplo mais simples: um filtro que bloqueia “rm” não detecta “r”m”, porque para um comparador de texto essas strings são diferentes. O bash remove as aspas vazias e executa “rm” normalmente.

Segundo a The Hacker News, esse truque de shell é conhecido há décadas na literatura de segurança. O que muda é o alvo: pela primeira vez, ele é aplicado sistematicamente contra agentes de IA que executam comandos com privilégios de administrador.

Os 10 agentes afectados

A Adversa AI testou os onze agentes de código aberto mais populares por contagem de estrelas no GitHub, com aproximadamente 548 mil estrelas combinadas em maio de 2026. O resultado: dez falharam. Apenas um, o Continue, resistiu a todos os payloads testados.

Agente Tipo de falha Vulnerável
opencode Guarda existe e é derrotado Sim (16/16 vazamentos)
Goose Guarda existe e é derrotado Sim (22/23 vazamentos)
Hermes Agent Guarda existe e é derrotado Sim
Cline Guarda tokenizado com vazamentos Sim (2/13 a 8/13)
Roo-Code Guarda tokenizado com vazamentos Sim
Aider Sem guarda estático Sim
Plandex Sem guarda estático Sim (demonstrado end-to-end)
Open Interpreter Sem guarda estático Sim
OpenHands Opt-out de sandbox documentado Sim
SWE-agent Opt-out de sandbox documentado Sim
Continue Defende por design Não

A SC World observou que a falha é classificada pela Adversa AI não como um bug individual, mas como uma “convenção perigosa e uma classe de problemas”. Adicionar mais padrões ao denylist não resolve — é preciso mudar a arquitectura.

Como funciona o ataque

Para o GuardFall funcionar, dois factores precisam alinhar. O primeiro é a própria ferramenta de IA gerar o comando malicioso. Um pedido directo como “execute rm -rf” costuma ser recusado pelo modelo. Mas o mesmo comando escondido dentro de uma tarefa aparentemente normal — como um build file ou a resposta da ferramenta a um README — é emitido como passo rotineiro. O segundo é o agente rodar em modo automático, com auto-execute activado ou sandbox desactivado, configurações comuns em pipelines de CI/CD.

A Adversa AI demonstrou o ataque completo contra o binário de produção do Plandex usando o Claude Sonnet 4.6 como modelo backend. O mesmo padrão funcionou contra oito outros agentes. Os testes cobriram vectores realistas: servidores MCP maliciosos, READMEs envenenados, alvos de Makefile e ficheiros de configuração shipping dentro do repositório, como o .aider.conf.yml.

O TrustFall e o padrão maior

O GuardFall não é um incidente isolado. Antes dele, a mesma equipa da Adversa AI publicou o TrustFall, demonstrando que Claude Code, Cursor CLI, Gemini CLI e GitHub Copilot CLI partilham uma vulnerabilidade similar. Segundo a Ciphers Security, o TrustFall explora o facto de todas essas ferramentas exibirem um diálogo de confiança quando o utilizador abre um novo repositório — mas com o valor padrão definido como “Sim/Confia”. Um único toque no Enter concede acesso total ao conteúdo malicioso.

Outras descobertas correlatas incluem o AutoJack e o Agentjacking (que já cobrimos no ciberseguranca.org), onde conteúdo envenenado é convertido em comandos executados com os privilégios do proprietário do agente. O fio condutor é sempre o mesmo: texto não confiável chega a uma shell real antes de o filtro entender o que o bash vai executar.

O que fazer agora

Nenhum quick fix é solução completa, mas reduzem a exposição até que um guarda robusto seja implementado:

1. Execute agentes com $HOME numa pasta descartável. Assim, segredos como ~/.ssh e ~/.aws ficam fora do alcance do agente.

2. Desactive auto-execução. Desligue flags como --auto-exec, --auto-run, --auto-test e dangerously-skip-permissions a menos que a tarefa genuinamente não possa pausar para validação humana.

3. Não permita agentes em pull requests de forks. É o caminho mais directo de um ficheiro de um atacante aos seus segredos.

4. Trate ficheiros de configuração dentro de repositórios como código não confiável. Um .aider.conf.yml malicioso pode despoletar o ataque na primeira edição aceite.

5. Prefira o Continue ou sandbox container. O Continue é a única ferramenta que defende por design no modo padrão de IDE. Alternativamente, execute outros agentes dentro de um container descartável onde o workspace pode ser destruído sem impacto.

A Adversa AI estima que implementar a defesa correcta — parsear o comando como o bash faz antes de decidir se é seguro — é um trabalho de aproximadamente dois dias para um engenheiro experiente. A questão é quantos dos 548 mil utilizadores vão esperar até que essa correcção chegue.

Leia também

Referências