O Ataque Rug Pull do MCP: A Ameaça que Altera suas Ferramentas Após a Aprovação

Você instalou um servidor MCP. Você revisou as descrições das ferramentas. Tudo parecia legítimo. Você aprovou.

Seis semanas depois, o servidor enviou uma atualização silenciosa. A ferramenta que seu agente estava chamando — aquela que você aprovou — agora contém instruções que seu agente não pode ignorar e que você não pode ver.

Esse é o ataque de rug pull do MCP, e não é teórico. Aconteceu com milhares de equipes em 2025.

O que é um ataque de rug pull do MCP?

Um ataque de rug pull do MCP é um ataque à cadeia de suprimentos no qual um servidor MCP malicioso ou comprometido altera silenciosamente a definição ou o comportamento de uma ferramenta após um desenvolvedor ou sistema já ter aprovado. Como a maioria dos clientes MCP verifica as ferramentas no momento da instalação, mas não re-alerta quando as definições mudam, o agente continua chamando o que acredita ser uma ferramenta confiável — enquanto executa uma versão que foi silenciosamente armada. A aprovação aconteceu uma vez. O ataque ocorre toda vez que o agente é executado.

Isso explora algo fundamental sobre como a confiança no MCP funciona hoje: a aprovação é um evento, não um estado contínuo. Uma vez que uma ferramenta é marcada como confiável, ela permanece confiável — não importa o que o servidor por trás dela se tornou. Essa é a lacuna onde o rug pull vive.

Como funciona um ataque de rug pull do MCP?

Existem quatro fases, e a paciência necessária para a fase dois é parte do que a torna eficaz.

Passo 1: Publique algo genuinamente útil. O atacante envia um servidor MCP com uma ferramenta que realmente funciona — um conector de banco de dados, uma integração de busca na web, um ambiente de execução de código. As descrições das ferramentas são limpas. Nada levanta bandeiras. Um desenvolvedor a revisa, a integra, e os agentes começam a chamá-la.

Passo 2: Espere. Este passo não recebe atenção suficiente. A ferramenta precisa acumular uso rotineiro — o tipo de confiança implícita que vem de chamar algo quinhentas vezes e ter o retorno correto. Agentes que chamam uma ferramenta diariamente constroem um padrão. Sistemas de alerta aprendem esse padrão como normal. Quando a carga útil cai, a ferramenta é essencial.

Passo 3: Envie a atualização. O atacante modifica a definição da ferramenta — seja através de uma atualização direta do servidor ou comprometendo o próprio servidor. A nova versão incorpora instruções nos metadados da ferramenta que o modelo de IA processará como parte de seu contexto. Um humano que revisa o nome público da ferramenta não veria nada diferente. O modelo vê tudo.

Passo 4: Cada sessão a partir daqui está comprometida. O agente chama a ferramenta como sempre fez. Do ponto de vista do modelo, esta é a mesma ferramenta confiável que ele tem usado por semanas. As instruções incorporadas entram em contexto e o modelo as segue — porque é isso que os modelos fazem com instruções de fontes confiáveis. O usuário não vê mudança. O agente vê novas instruções. A lacuna entre eles é onde o ataque vive.

Um detalhe que é fácil de perder: na maioria dos casos documentados, a ferramenta envenenada não toma a ação maliciosa diretamente. Ela instrui o modelo a usar outras ferramentas legítimas para completar o ataque — lendo arquivos, chamando APIs, enviando mensagens. O dano acontece através de ferramentas que a organização já confia, invocadas em uma sequência que ninguém jamais autorizou.

Por que isso é pior do que injeção de prompt?

A injeção de prompt é limitada à sessão. Um usuário elabora uma mensagem maliciosa, o agente a processa, a sessão termina. Raio de explosão: uma conversa.

Um rug pull do MCP é persistente. Uma vez que a definição da ferramenta é silenciosamente atualizada, cada sessão de agente que chama essa ferramenta está executando a versão envenenada — não apenas a sessão onde a atualização ocorreu. Uma equipe com cinquenta agentes usando uma ferramenta comprometida está executando cinquenta infecções simultâneas a partir de um único evento de cadeia de suprimentos. Limpar uma sessão e você não fez nada; a ferramenta ainda está servindo a má definição na próxima chamada.

As taxas de sucesso do ataque a partir de pesquisas reais devem tornar essa leitura desconfortável. O benchmark MCPTox testou 20 agentes de IA proeminentes contra ataques reais de envenenamento de ferramentas em 45 servidores MCP e 353 ferramentas autênticas. A taxa de sucesso do ataque contra o o1-mini: 72,8%. Claude 3.7-Sonnet teve a maior taxa de recusa de qualquer modelo testado — e ainda assim recusou esses ataques menos de 3% das vezes.

Isso não é uma falha de segurança do modelo. Os modelos são projetados para seguir instruções de fontes de contexto confiáveis. Uma definição de ferramenta envenenada é exatamente isso — confiável, por definição, porque passou pela aprovação. Você não está lutando contra o comportamento do modelo aqui. Você está lutando contra uma arquitetura que trata a aprovação como permanente.

Como foram os incidentes reais?

A classe de ataque passou de teórica para documentada na segunda metade de 2025, rapidamente.

Setembro de 2025 — o backdoor postmark-mcp. Um pacote NPM com backdoor servindo como um conector MCP para a API de email Postmark foi enviado a desenvolvedores que haviam instalado e aprovado o original. A atualização maliciosa se propagou silenciosamente. Nada no fluxo padrão de instalação ou aprovação sinalizou a mudança.

Outubro de 2025 — o ataque à cadeia de suprimentos da Smithery. Smithery é um dos registros de servidores MCP hospedados mais amplamente utilizados — que é exatamente o que o torna um alvo valioso. Os atacantes exploraram uma vulnerabilidade de travessia de caminho no sistema de configuração de build para executar código arbitrário durante as builds. Tokens de API e credenciais foram exfiltrados de mais de 3.000 aplicações hospedadas antes que a violação fosse contida. A escala foi uma função direta de quão profundamente a Smithery havia sido confiada e integrada.

CVE-2025-54136 (MCPoison). Um rug pull demonstrado aplicado a arquivos de configuração do MCP em um grande ambiente de desenvolvimento. Um atacante comete um arquivo de configuração benigno para um projeto, ele é revisado e aprovado uma vez, então a carga útil é trocada por uma versão maliciosa. A ferramenta confiou no nome da chave que havia sido aprovado — não no conteúdo do comando que havia mudado — então a versão maliciosa foi executada silenciosamente em cada projeto subsequente aberto.

A thread em todos os três não é uma técnica sofisticada. É a mesma aposta estrutural: que a confiança, uma vez concedida, não será reexaminada.

Por que "apenas fixar suas versões" não é suficiente?

A fixação de versões é o instinto correto, e ajuda. Mas tem dois modos de falha reais e uma armadilha operacional.

O primeiro modo de falha: muitas estruturas de agentes resolvem dependências de ferramentas em tempo de execução. Uma versão fixada em sua configuração pode não ser o que está realmente executando em produção se sua execução a resolver dinamicamente. Saber qual versão você declarou não é o mesmo que saber qual versão está em execução.

O segundo modo de falha é o cenário de comprometimento de conta. Quando as credenciais de um mantenedor legítimo são roubadas e a atualização maliciosa é enviada da conta original, o histórico de fixação de versões parece limpo — porque a atualização veio de um editor legítimo. O ataque da Smithery seguiu esse padrão. A verificação padrão de versões não tinha nada para sinalizar.

A armadilha operacional: se você se comprometer a nunca atualizar, acumula vulnerabilidades não corrigidas nas ferramentas das quais depende. Portanto, as equipes atualizam periodicamente, o que reabre a janela que a fixação pretendia fechar.

A fixação é uma captura estática. O que realmente é necessário é a verificação em tempo de execução — algo que compara o que uma ferramenta atualmente afirma ser com o que foi aprovado, no momento da execução, em cada execução. Esse é um problema de governança, não um problema de gerenciamento de pacotes.

Como é uma defesa real?

O ataque é um problema de continuidade de confiança: o sistema confia no estado atual de uma ferramenta porque uma vez confiou no estado passado daquela ferramenta. Não há mecanismo que reexamine