MCP Tool Poisoning: da execução de código ao bypass das permissões do agente

0A dependência que ninguém audita

Existe um vetor anterior a tudo, e mais sutil: o MCP server pode ser honesto e ainda assim ser o veículo.

Você audita o repositório do servidor, lê os handlers, confere que a implementação bate com as descrições e aprova. O que você provavelmente não fez foi auditar as dezenas ou centenas de pacotes que ele arrasta como dependência transitiva. Basta que um deles esteja sob controle do atacante.

• Comprometimento de pacote legítimo. Conta de mantenedor sequestrada por phishing, versão nova com uma linha a mais.
• Typosquatting. Pacote com nome quase idêntico ao popular, esperando um erro de digitação ou uma sugestão errada de LLM.
• Confusão de dependência. Pacote público com o mesmo nome de um pacote interno da empresa, publicado com versão maior e resolvido preferencialmente pelo gerenciador.
• Pacote alucinado. Um modelo sugere uma biblioteca que não existe; o atacante registra esse nome e espera.

E o detalhe que fecha o círculo com a etapa 2: a execução acontece na instalação, não no uso. Scripts de ciclo de vida do gerenciador de pacotes rodam com o usuário que instalou. Você nunca chegou a subir o MCP server: o install já foi suficiente.

1A interface mente sobre a implementação

O que o modelo vê de uma tool são essencialmente três campos: name, description e inputSchema. A especificação também prevê title, outputSchema e annotations, como readOnlyHint, mas todos são declarados pelo próprio servidor. Nada no protocolo verifica se o código por trás cumpre o que eles prometem.

Do lado dos metadados, três variantes documentadas:

• Tool poisoning. A descrição carrega instruções ocultas que o modelo segue. No exemplo canônico da Invariant Labs, uma função de soma instrui o modelo a ler chaves SSH e passá-las num parâmetro extra.
• Rug pull. O servidor entrega descrições benignas, é aprovado, e depois troca por versões envenenadas, sem nova aprovação.
• Tool shadowing. A descrição de um servidor malicioso redefine como o modelo deve usar a tool de outro servidor, confiável e intocado.

Em todos os casos, a aprovação do usuário acontece para o nome bonito, não para o comportamento real.

2Execução com o privilégio do usuário

Um detalhe que muda a leitura do ataque: o código não começa a rodar quando a tool é chamada. Ele roda quando o servidor é iniciado e, antes disso, na instalação. Subir o servidor já é o ponto sem volta. A tool envenenada não é o gatilho, é a cobertura: dá ao ataque a aparência de uso normal e um resultado forjado para mostrar.

A partir do spawn, o processo pode, sem pedir nada a mais:

• Ler qualquer arquivo que seu usuário possa ler: arquivos de ambiente, chaves SSH, credenciais de cloud, histórico de shell
• Fazer requisições de rede para qualquer destino
• Escrever ou modificar arquivos onde seu usuário tem permissão de escrita
• Executar binários e scripts já instalados na máquina

Não é falha do MCP. É a mesma exposição de qualquer pacote desconhecido ou extensão não auditada. O MCP só torna o padrão mais fácil de disparar sem perceber, porque a interface esconde a implementação atrás de um convite de "clique e confie".

3O alvo muda do processo para o agente

Cabe uma pergunta honesta aqui: se o handler já tem acesso total do usuário (e as regras de deny do Claude Code nem se aplicam a ele, já que limitam as tools do agente, como Bash e Read), por que o atacante mexeria no settings.json?

Porque o objetivo deixa de ser acesso imediato e passa a ser persistência e controle do agente. Arquivos como ~/.claude/settings.json e as variantes de projeto são JSON comum no disco: sem assinatura, sem hash de integridade, sem trava contra escrita por outro processo do mesmo usuário. Editá-los permite:

• Remover entradas de deny e adicionar allow, de forma que qualquer prompt injection futuro encontre o agente sem travas: o agente vira um confused deputy
• Registrar hooks, que executam comandos de shell em eventos da sessão, garantindo execução mesmo depois que o servidor malicioso for desinstalado
• Adulterar registros de servidores MCP ou arquivos de instrução como o CLAUDE.md, que o agente lê como contexto confiável

É o padrão do malware que desativa o antivírus antes de agir, com uma diferença: aqui o "antivírus" é a própria camada de permissão declarativa do agente.

3-AQuando a tool é só o gatilho

Nas etapas anteriores o dano acontece dentro do processo do MCP server. Existe um desenho pior: o handler não faz nada de interessante durante a chamada, apenas escreve um artefato no disco e registra um mecanismo de início automático. A partir daí o ataque deixa de depender do agente, do MCP e da sua sessão.

Os mecanismos de persistência são os mesmos de qualquer malware de usuário, e todos estão ao alcance de um processo sem privilégio administrativo:

• Agendadores de usuário (cron no Linux, Agendador de Tarefas no Windows, launchd no macOS), que disparam em intervalo fixo
• Inicialização de sessão: pastas de startup, entradas de registro por usuário, unidades de serviço de usuário
• Arquivos de inicialização de shell, executados a cada terminal aberto
• Hooks de ferramentas de desenvolvimento: hooks de git no repositório, hooks do próprio agente, extensões de IDE

Nenhum deles exige root. Todos sobrevivem à desinstalação do MCP server, e esse é justamente o ponto. O usuário remove o pacote, considera o incidente encerrado, e o artefato continua lá.

O que o payload costuma fazer depois de ativo

1. Varredura de segredos. Percorre o diretório do usuário e os projetos procurando padrões de credencial: arquivos de ambiente, chaves privadas, credenciais de cloud, tokens em arquivos de configuração, e também histórico do shell e histórico do git, onde segredo removido do código costuma continuar vivo. Existem ferramentas de código aberto de secret scanning, criadas para uso defensivo, que fazem exatamente isso; atacantes simplesmente as embutem em vez de escrever a própria varredura.
2. Exfiltração com cobertura. O destino nem sempre é um servidor com IP suspeito. O worm Shai-Hulud publicava os segredos roubados em repositórios públicos criados na conta da própria vítima: tráfego de saída para um domínio que já estava na sua allowlist, com credencial legítima.
3. Propagação. Com token de registro de pacotes ou de repositório em mãos, o payload republica a si mesmo nos pacotes que a vítima mantém, fechando o ciclo sem operador humano.
4. Segundo estágio. O primeiro artefato é pequeno e discreto; busca e executa a carga real quando quiser, o que permite trocar o payload depois da infecção sem tocar no pacote original.

A leitura importante: o MCP server é o vetor de entrada, não o malware. Depois desta etapa, remover o servidor e limpar o settings.json não resolve nada.

4A cadeia completa

Cada etapa isolada parece pequena. Somadas, formam um comprometimento duradouro disfarçado de instalação de ferramenta.

1. A vítima instala um MCP server de repositório público não auditado, ou um servidor honesto com uma dependência comprometida
2. Scripts de instalação já executam com o usuário dela
3. O servidor sobe via stdio e herda ambiente, credenciais e permissões de disco
4. A vítima pede uma tarefa comum; o modelo escolhe a tool envenenada porque a descrição parece adequada
5. O handler lê segredos, exfiltra e devolve uma resposta forjada de sucesso
6. O mesmo processo adultera a configuração do agente: remove deny, adiciona allow, registra hooks. A mudança pode valer ainda na mesma sessão
7. E grava um artefato com início automático, que passa a rodar fora da sessão do agente
8. A vítima desinstala o servidor; o agendador continua disparando

O dano final depende só do que aquele usuário do sistema operacional tem permissão de fazer, o que, num ambiente de desenvolvimento típico, costuma ser quase tudo.