Um servidor MCP pode ler arquivos, consultar bancos de dados e executar comandos para um modelo de IA, então um único ponto fraco expõe muita coisa. Veja como portas abertas, prompt injection, tool poisoning, pacotes maliciosos e segredos vazados funcionam em incidentes reais, além das correções que realmente resolvem.
Um servidor MCP é um pequeno programa com uma tarefa grande: ele dá a um modelo de IA o poder de ler arquivos, consultar bancos de dados, enviar e-mails e executar comandos de shell. É exatamente por isso que as vulnerabilidades de servidores MCP continuam aparecendo em comunicados de segurança. Em cerca de um ano após o protocolo se tornar popular, pesquisadores publicaram falhas críticas de execução remota de código, identificaram um pacote malicioso que copiava discretamente cada e-mail enviado e contaram 1.862 servidores expostos na internet pública, dos quais uma amostra de 119 permitia que desconhecidos listassem suas ferramentas sem um único login.
Este artigo percorre as falhas de segurança mais comuns do MCP, mostra os incidentes reais por trás de cada uma e termina com uma lista de verificação que você pode aplicar hoje. Cada seção associa uma falha à correção que realmente funciona, para que você feche as brechas em vez de apenas se preocupar com elas.
Uma API web comum faz uma tarefa restrita. Um servidor MCP se parece mais com uma régua de tomadas: ele conecta um sistema de arquivos, um cliente git, um banco de dados, um navegador e uma conta de e-mail a uma única conexão, e o modelo decide qual tomada usar. Servidores locais geralmente rodam como processo filho com as mesmas permissões da sua conta de usuário. Uma ferramenta comprometida pode, portanto, ler configurações SSH, perfis de navegador, credenciais de nuvem e todas as pastas de projetos da máquina.
Servidores remotos não são mais seguros. Eles costumam guardar tokens OAuth de vários serviços ao mesmo tempo, o que transforma uma única violação em acesso a muitos sistemas.
Softwares clássicos têm uma única fronteira de confiança: entra uma entrada não confiável, sai um dado validado. O MCP tem pelo menos quatro.
Modelos como o Claude Sonnet 5 e o GPT 5.6 Sol são feitos para seguir instruções, e não conseguem separar de forma confiável uma instrução do usuário de uma instrução escondida dentro de um documento que lhes foi pedido para resumir. Essa fraqueza única sustenta a maioria dos ataques abaixo.
💡 Regra prática: trate cada string que chega ao modelo como código não confiável, mesmo quando ela vier de uma ferramenta que você mesmo instalou.
O erro mais antigo da segurança aparece de novo: serviços que respondem a qualquer um que bata na porta.
Muitos servidores MCP locais se vinculam a 0.0.0.0 em vez de 127.0.0.1, o que os torna acessíveis a qualquer pessoa na mesma rede Wi-Fi. Os pesquisadores apelidaram o ataque que se segue de NeighborJacking. O MCP Inspector oficial, uma ferramenta de depuração, mostrou o tamanho do problema: as versões anteriores à 0.14.1 não tinham autenticação entre o cliente do navegador e o proxy local. Isso resultou no CVE-2025-49596, uma falha de execução remota de código com severidade 9,4, na qual uma página web maliciosa podia enviar comandos para a máquina de um desenvolvedor enquanto o Inspector estava aberto em outra aba.
A internet pública parece pior. A varredura da Knostic encontrou 1.862 servidores MCP expostos. Dos 119 que testaram, nenhum exigia autenticação antes de devolver sua lista de ferramentas. Qualquer pessoa com um navegador ou um script podia ver o que cada servidor fazia e, em muitos casos, chamá-lo.
Mesmo servidores protegidos por login muitas vezes autenticam a conexão e não autorizam nada depois. Quem entra pode chamar todas as ferramentas, inclusive as destrutivas. A especificação do MCP define um fluxo de autorização baseado em OAuth para servidores remotos, mas ele é opcional, e muitos desenvolvedores o pulam em uma demonstração rápida que depois vira produção.
As correções são simples:
127.0.0.1 e valide o cabeçalho Origin nos transportes HTTP para bloquear o DNS rebinding.delete_record.
A falha mais perigosa do MCP não é um bug de programação. É texto. O pesquisador de segurança Simon Willison chama a configuração arriscada de trifeta letal: um agente que pode ler dados privados, ingerir conteúdo não confiável e enviar informações para fora. Dê os três a um único agente e o atacante só precisa plantar algumas frases.
Dois casos reais mostram o padrão:
Nenhum dos dois servidores tinha uma vulnerabilidade clássica. Ambos fizeram exatamente o que foram mandados fazer, pela pessoa errada.
O tool poisoning leva o ataque para os metadados da própria ferramenta. A Invariant Labs publicou o método em abril de 2025: uma ferramenta que parece uma função inofensiva de add traz instruções ocultas em sua descrição, mandando o modelo ler arquivos privados de SSH e enviá-los para fora por meio de um parâmetro. O usuário vê "somar dois números" na janela de aprovação. O modelo vê a descrição completa e obedece.
Variantes escondem a carga com caracteres Unicode de largura zero ou blocos Base64, então uma revisão visual rápida não encontra nada de errado.
O rug pull é a versão paciente. Um servidor se comporta bem no primeiro dia, coleta aprovações e depois publica novas definições de ferramentas por meio da notificação tools/list_changed. A maioria dos clientes não pede uma segunda aprovação, não fixa a versão nem compara um hash. Um truque relacionado, o tool shadowing, permite que um servidor malicioso reescreva como o modelo usa as ferramentas de um servidor confiável, porque todas as descrições caem na mesma janela de contexto.
O que funciona contra essa família de ataques:
Servidores MCP são instalados com um único comando, geralmente npx ou uvx, que baixa e executa código de um registro público. Em setembro de 2025, a Koi Security relatou o que foi descrito como o primeiro servidor MCP malicioso encontrado na natureza: um pacote npm chamado postmark-mcp que copiava uma biblioteca de e-mail real. A versão 1.0.16 acrescentou uma única linha que enviava uma cópia oculta de cada e-mail de saída para um endereço controlado pelo atacante. O pacote foi baixado 1.643 vezes antes de ser removido.
Uma linha bastou, porque quase ninguém lê o código-fonte de um servidor que instalou para economizar cinco minutos.
A segunda família é a injeção de comandos clássica. Uma ferramenta recebe um nome de arquivo, uma URL ou o nome de uma branch e o insere em uma string de shell. O proxy mcp-remote caiu nesse padrão com o CVE-2025-6514, com nota 9,6: conectar-se a um servidor MCP não confiável podia disparar comandos arbitrários do sistema operacional na máquina que executava o proxy.
Seus primos estão em toda parte:
| Tipo de bug | Gatilho típico | Padrão mais seguro |
|---|---|---|
| Injeção de shell | Nome de arquivo ou URL colado em uma string de comando | Passe os argumentos como array, nunca por um shell |
| Path traversal | Sequências ../ ou links simbólicos em um caminho de arquivo | Resolva o caminho real e depois compare com uma raiz permitida |
| SSRF | Uma ferramenta de fetch apontada para endereços internos | Bloqueie faixas de IP privadas e endpoints de metadados da nuvem |
| Injeção de SQL | Consultas escritas pelo modelo executadas com todos os direitos | Consultas parametrizadas e uma função de banco somente leitura |
Uma configuração MCP típica cola um token de acesso diretamente em um JSON de configuração. Esse arquivo acaba sendo commitado em um repositório, sincronizado com um drive na nuvem ou lido por uma ferramenta envenenada que foi instruída a procurá-lo. O log piora tudo: servidores que imprimem o payload completo das requisições gravam tokens em arquivos de log que ninguém rotaciona.
A limpeza é rotineira, mas raramente feita. Carregue os segredos de variáveis de ambiente ou de um gerenciador de segredos, emita tokens de vida curta, rode a varredura de segredos no CI e remova os cabeçalhos de autorização de cada linha de log.
Um servidor que só precisa ler uma tabela recebe um token de função de serviço para o banco inteiro. Um token do GitHub que alcança todos os repositórios transforma um issue injetado em um vazamento completo. A própria documentação do Supabase recomenda, por padrão, o modo somente leitura com escopo no projeto, que é o instinto certo para todo servidor.
Dois erros no nível do protocolo merecem nome:
💡 Teste rápido: se o token de um servidor fosse colado em um chat público hoje, quanto dano ele poderia causar? Reduza a resposta até que doa menos.
Aqui está o artigo inteiro resumido em uma tabela que você pode colar em um modelo de pull request.
| Falha | Como se apresenta | Correção |
|---|---|---|
| Portas abertas | Servidor vinculado a 0.0.0.0, sem login | Vincule ao localhost e exija tokens |
| Prompt injection | Agente obedece a texto em um chamado ou issue | Separe os poderes de leitura e envio e aprove ações de saída |
| Tool poisoning | Descrições de ferramentas longas ou estranhas | Mostre o texto completo e remova caracteres invisíveis |
| Rug pull | Ferramentas mudam depois da aprovação | Fixe versões e calcule o hash das definições |
| Pacote malicioso | Nome parecido com o original no npm | Verifique o publicador, fixe a versão e revise os diffs |
| Injeção de comandos | Entrada do usuário dentro de strings de shell | Arrays de argumentos e listas de permissão |
| Vazamento de segredos | Tokens em JSONs de configuração e logs | Gerenciador de segredos e vida útil curta |
| Escopos excessivos | Token de administrador para uma tarefa de leitura | Privilégio mínimo por servidor |
Registre cada chamada de ferramenta com seus argumentos e a identidade por trás dela. Emita alerta quando uma nova ferramenta aparecer ou uma definição mudar. Limite a taxa de uso das ferramentas caras, rotacione os tokens em um cronograma e mantenha um interruptor de emergência que desconecte todos os servidores de uma vez. Revise os logs após a primeira semana, pois é quando comportamentos surpreendentes costumam aparecer.
O Llama Guard 4 12B é um classificador de segurança que você pode rodar no PicassoIA. Ele devolve um veredito de seguro ou inseguro, além da categoria de dano em que se enquadrou. Não é um detector dedicado de prompt injection, então trate-o como um alarme extra para descrições de ferramentas e saídas de ferramentas, e não como um portão em que você confie sozinho.
Aqui está um fluxo de trabalho que leva alguns minutos:
| Configuração | Valor sugerido | Por que ajuda |
|---|---|---|
| Temperature | 0 a 0,2 | Vereditos consistentes para o mesmo texto |
| Max Completion Tokens | 512 ou menos | O veredito é curto, então mais espaço não acrescenta nada |
| System Prompt | Regras curtas e específicas | Regras estreitas geram respostas menos vagas |
| Image Input | Opcional | Útil quando é preciso verificar a captura de tela de uma janela de ferramenta |
💡 Peça uma segunda opinião: cole o mesmo texto no Gemini 3.5 Flash e peça que liste cada frase que dá uma instrução a um assistente de IA. Dois modelos diferentes discordando é um sinal útil.
Análises de segurança, runbooks e apresentações internas de treinamento precisam de imagens que pareçam vida real, e não clichês de banco de imagens. O Picasso IA transforma uma descrição em texto em uma imagem fotorrealista em segundos, então você pode criar um visual para cada falha deste artigo sem fazer uma sessão de fotos.
Experimente o p-image para cenas rápidas e nítidas, o Seedream 4.5 para muitos detalhes ou o Flux 2 Pro quando quiser controle preciso da composição. Descreva o assunto, a luz e a lente, depois gere a imagem e ajuste um detalhe por vez. Veja todas as opções em picassoia.com/en/all-models, escolha um modelo e crie sua primeira imagem hoje.
Escolha seu idioma
