MCP Enfrenta Problemas de Segurança na Cadeia de Suprimentos

Em julho de 2025, um pesquisador da JFrog encontrou uma maneira de obter execução total de comandos na máquina de um desenvolvedor apenas conectando-se ao servidor errado. A falha estava dentro do mcp-remote, uma pequena ferramenta proxy que permite que clientes de IA como Claude Desktop e Cursor se comuniquem com servidores remotos do Protocolo de Contexto de Modelo. Ela recebeu uma pontuação de 9,6 de 10 em severidade. A JFrog chamou isso de o primeiro caso conhecido de execução remota total de código alcançada na prática através de uma conexão MCP não confiável.

O mantenedor corrigiu isso em poucos dias. O pacote npm foi atualizado para a versão 0.1.16. Todos seguiram em frente.

Nove meses depois, uma equipe de pesquisa diferente encontrou a mesma categoria de falha embutida nos próprios SDKs oficiais do MCP, o código sobre o qual todos os outros servidores MCP são construídos. Não era um pacote desonesto desta vez. A implementação de referência, em Python, TypeScript, Java e Rust. A Anthropic revisou a descoberta e se recusou a mudar a arquitetura, chamando o comportamento de esperado.

Essa é a história real. Não um pacote vulnerável que foi corrigido. Um padrão que continua ressurgindo por causa de como o protocolo trata a confiança.

O que a maioria das equipes pensa que é um servidor MCP

A maioria das equipes de engenharia trata um servidor MCP da mesma forma que trata uma extensão do VS Code: algo que você adiciona de um marketplace, que roda dentro de algum tipo de sandbox, que é seguro por padrão porque outras pessoas já o instalaram. Esse modelo mental está errado, e a lacuna entre o que as pessoas assumem e o que realmente acontece é onde o dano ocorre.

Um servidor MCP é um processo ativo com a capacidade de executar chamadas de ferramentas em seu nome, muitas vezes com o mesmo acesso ao sistema de arquivos, rede e shell que o desenvolvedor que o executa. Ele recebe respostas de onde quer que esteja configurado para olhar, e trata partes dessas respostas como instruções para agir, não apenas dados para ler. Isso não é um bug. É todo o princípio do protocolo: o modelo faz uma pergunta, a ferramenta responde e algo a jusante age sobre essa resposta imediatamente.

O modo de falha tem um nome. É chamado de injeção de comando: quando um programa não separa claramente os dados que está processando das instruções que executa, um atacante que controla os dados pode fazer o programa executar seu comando em vez disso. Foi exatamente isso que aconteceu no mcp-remote. A resposta de autorização de um servidor malicioso continha uma URL manipulada. O cliente não apenas leu isso. Ele passou esse valor diretamente para um comando do sistema.

Uma causa raiz, cinco bases de código diferentes

O mcp-remote não era um caso isolado. Olhe as divulgações do ano passado e o mesmo padrão de falha aparece em projetos não relacionados, construídos por equipes não relacionadas, enviados para propósitos não relacionados.

Em abril de 2026, a OX Security foi mais longe e encontrou a mesma causa raiz dentro dos SDKs oficiais do MCP, as bibliotecas que todos esses projetos e milhares de outros importam diretamente. Sua pesquisa, intitulada "A Mãe de Todas as Cadeias de Suprimento de IA", colocou um número na exposição: mais de 150 milhões de downloads, mais de 7.000 servidores publicamente acessíveis e uma estimativa de 200.000 instâncias vulneráveis no total. Eles identificaram quatro maneiras distintas de acioná-la, incluindo um caminho de zero cliques através da injeção de prompt em IDEs como Windsurf e Cursor que não requer interação do usuário.

A resposta da Anthropic foi deixar a arquitetura como está. Não porque a descoberta estava errada, mas porque corrigi-la no nível do protocolo significaria mudar o comportamento do qual milhares de projetos a jusante agora dependem. Essa é a parte que vale a pena refletir. Não é uma fila de CVEs não corrigidos esperando por atenção. É uma decisão de design que o ecossistema agora tem que construir em torno, porque o guardião do padrão não vai construir a correção para eles.

Servidores MCP pulam a análise que pacotes npm recebem

A segurança da cadeia de suprimento de software passou a última década construindo ferramentas que a maioria dos engenheiros agora considera garantidas. Arquivos de bloqueio. Análise de composição de software. Atestação de proveniência. Uma equipe que adiciona uma nova dependência npm a um serviço de produção pode, no mínimo, executar um scanner contra ela antes de mesclar.

Os servidores MCP em grande parte pulam tudo isso, apesar de rodar com privilégios iguais ou maiores. Adicionar um a Claude Desktop ou Cursor leva cerca de tanta análise quanto instalar uma extensão de navegador: cole um bloco de configuração, reinicie, pronto. Poucas equipes fixam versões. Menos ainda leem o código-fonte de um servidor antes de conceder acesso ao sistema de arquivos ou ao shell.

A BlueRock Security escaneou mais de 7.000 servidores MCP públicos no início de 2026 e encontrou 36,7% potencialmente expostos a falsificação de solicitação do lado do servidor, uma falha onde um atacante engana o servidor para fazer solicitações a sistemas internos que não deveria alcançar. Em um conceito de prova contra o servidor MCP MarkItDown da Microsoft, os pesquisadores usaram exatamente esse caminho para puxar credenciais da AWS diretamente do endpoint de metadados de uma instância EC2. Uma integração de ferramenta mal configurada se tornou uma linha direta para a infraestrutura em nuvem, e nada sobre a exploração exigiu um zero-day.

O Registro não verifica quem está publicando

Nem todo compromisso MCP requer uma vulnerabilidade técnica. Em fevereiro de 2026, os STAR Labs da Straiker documentaram uma operação que pulou falhas de código completamente. Um grupo que se autodenominava SmartLoader passou três meses construindo cinco falsas personas de desenvolvedor do GitHub, cruzando os repositórios uns dos outros para parecer uma comunidade ativa, antes de submeter uma versão trojanizada de um popular servidor MCP do Oura Ring a um registro público.

O fork era funcionalmente idêntico ao servidor legítimo. Ele passou como normal por meses. Uma vez instalado, ele implantou silenciosamente um infostealer que puxava senhas de navegador, tokens de sessão em nuvem, credenciais do Discord, chaves SSH e arquivos de carteira de criptomoeda, disfarçando seu mecanismo de persistência como um processo de áudio do Windows. Sem CVE, sem patch, sem fornecedor para notificar. Apenas paciência e um registro sem moderação entre um desenvolvedor e um armazenamento de credenciais de produção.

Por que as equipes continuam sendo pegas por isso

O padrão por trás de todos os três problemas é o mesmo. Toda a proposta do MCP para as equipes de engenharia é velocidade: conectar um agente a uma nova ferramenta em uma tarde em vez de esperar um ciclo de aquisição ou uma revisão de segurança. Essa velocidade é real, e é por isso que a adoção avançou tão rapidamente. Também é por isso que a etapa de revisão que costumava capturar essa classe de risco foi pulada quase em todos os lugares.

A execução remota de código do GitHub Copilot divulgada em agosto de 2025 mostra o mesmo fator humano de um ângulo diferente. Um atacante não precisava violar uma rede. Ele precisava de um arquivo de configuração, .vscode/settings.json, para ser editado automaticamente por um agente que ninguém estava observando de perto o suficiente para notar. A maioria das equipes não tem uma categoria mental para "um arquivo JSON agora é uma superfície de ataque." Elas estão construindo uma em tempo real, geralmente depois que algo acontece.