MCP sem autenticação: 38% e 30 CVEs em 60 dias

Começo pela pergunta embaraçosa: você olhou a autenticação do último servidor MCP que ligou no Claude Desktop?

Pela amostra que a Wiz Research escaneou, a resposta honesta é "não" em 38 de cada 100 casos. Trinta e oito por cento dos servidores MCP expostos vieram sem autenticação. No mesmo intervalo de 60 dias, foram publicados 30 CVEs apontando para servidores, clientes e tools do protocolo. O pior deles chegou em CVSS 9.6, e veio pelo lado do cliente que confia no servidor, não pelo servidor mal configurado.

Eu venho usando MCP intensamente desde o começo do ano. Fiz um inventário dos meus próprios servidores pra escrever este post e descobri que eu mesmo deixei coisa aberta por hábito. O protocolo é cômodo demais pra parar de usar. Mas o reflexo de "npm install, rodou, pronto" é exatamente o que esses números estão medindo.

Antes de ganhar o próximo slot no seu mcpServers, o protocolo merece dez minutos de atenção.

Três escaneios independentes, mesma linha

O número vem de três investigações independentes que mediram a mesma coisa por ângulos diferentes e convergiram.

Fonte	Amostra	Sem autenticação
Wiz Research	500+ servidores MCP escaneados	38%
Censys	12.520 MCP expostos à internet	~40%
Auditoria do registry oficial	518 servidores do registry oficial	41%

Quando três amostras independentes produzem a mesma curva, para de ser dado ruidoso e vira linha de base do ecossistema. Com a amostra da Censys, isso significa cerca de 5.000 servidores MCP expostos aceitando qualquer conexão. Qualquer cliente HTTP consegue pedir a lista de tools e, em muitos casos, executar. Quem prefere não virar notícia tem motivo pra olhar o próprio mcpServers esta semana.

Por que a superfície do MCP é maior do que a de uma API comum

Antes das categorias, uma pergunta estrutural: por que o MCP quebra diferente. A resposta está na arquitetura do protocolo: ele junta quatro propriedades que raramente convivem numa API tradicional.

Primeiro, comunicação bidirecional: o servidor MCP pode pedir coisas ao LLM usando sampling, não só responder. Segundo, multi-tool: na mesma sessão convivem vários servidores MCP ao mesmo tempo, e nenhum sabe o que os outros fazem. Terceiro, controle via linguagem natural: a descrição textual de uma tool diz ao modelo como se comportar, e essa descrição é um vetor de ataque em si. Quarto, permissões altas: MCP costuma ter acesso ao filesystem, bancos de dados e APIs externas. Comprometer um servidor MCP abre portas para o resto do ambiente, e a maioria das tools vem com "tudo habilitado" por padrão. Esse arranjo é a norma do ecossistema hoje.

Se você está começando no protocolo, já escrevi sobre o handshake de 27K tokens em quatro servidores conectados. Lá eu olhei a conta de tokens. Hoje olho a conta de risco.

OWASP MCP Top 10: as três categorias que mais machucam hoje

A OWASP publicou o MCP Top 10 em versão beta no fim de 2025. São dez categorias, mas na prática três concentram os incidentes reais que estão aparecendo este ano.

MCP03 — Tool Poisoning. O atacante enfia instruções escondidas dentro da descrição de uma tool. A descrição é texto que o modelo lê como parte do contexto operacional, então uma linha inserida ali funciona como um prompt privilegiado. A Invariant Labs documentou um servidor de clima com instruções ocultas na descrição. O usuário perguntava o tempo. A conversa saía pela porta dos fundos. Ninguém auditou a descrição porque, sejamos honestos, ninguém lê descrição de tool.

MCP06 — Prompt Injection via payload de contexto. O LLM não distingue "essa frase foi digitada pelo usuário" de "essa frase veio dentro de um documento que eu li". Basta a pauta de um e-mail, uma célula escondida de spreadsheet ou um ticket de Jira trazer instruções pro agente tratar como ordem. Quando há vários servidores MCP conectados, a injection consegue pular entre eles: o input entra por uma tool e a ação sai por outra.

MCP07 — Autenticação e autorização insuficientes. É aqui que entra o famoso 38%. A especificação do MCP declara a autenticação como opcional. "Opcional", em produção, significa "ninguém vai colocar". O caso mais claro publicado em 2026 é o CVE-2026-32211, uma falha no Azure MCP Server onde faltava a camada de autenticação inteira. Não quebraram o cadeado: o cadeado nunca esteve lá.

CVEs recentes, atribuídos como manda

Entre janeiro e fevereiro de 2026, saíram mais de 30 CVEs apontando para o ecossistema MCP. A categoria mais comum, segundo o Practical DevSecOps, é shell injection, 43%. Em outubro de 2026 o contador acumulado já passou de 40, e vale ler alguns deles com calma — a imprensa tende a embolar tudo em "servidor sem auth", e não é a mesma coisa.

CVE-2025-6514 — CVSS 9.6. O mais grave até agora, e não é um problema de autenticação do servidor: é OS command injection no cliente mcp-remote (pacote npm com mais de 437.000 downloads). Quando o cliente se conectava a um servidor MCP não confiável, um authorization_endpoint fabricado com cuidado executava comandos arbitrários na máquina do usuário. Afeta versões 0.0.5 a 0.1.15, corrigido em 0.1.16. A lição desconfortável: a superfície de ataque do MCP inclui o cliente que confia no que o servidor devolve, não só o servidor.

CVE-2026-105697 — Langflow RCE, CVSS 9.9. Publicada em 5 de outubro de 2026. Executa comandos sem allowlist. O relatório do mês mostra que outubro bateu recorde porque a mesma falha reaparece em servidor atrás de servidor.

Palo Alto Unit 42 publicou outro dado pra tirar o sono: com cinco servidores MCP conectados, um único servidor comprometido chega a 78,3% de sucesso em influenciar o comportamento do cliente. Quanto mais tool carregada, mais maneira de uma puxar o modelo pra outra.

O ataque que mira a fatura, não os dados

Até 2025 os ataques MCP miravam dado: vazar token, exfiltrar arquivo, roubar sessão. Em 2026 apareceu outra família que mira direto no bolso.

Chama Overthinking Loop e está documentado no arXiv 2602.14798. Um servidor MCP malicioso, co-registrado junto a tools normais, induz o modelo a entrar em ciclos de raciocínio que parecem razoáveis passo a passo. Nenhuma chamada individual parece esquisita. O agregado explode a conta: os autores mediram até 142,4× mais tokens que a execução legítima. É um DoS que, em vez de derrubar o serviço, infla a fatura. A comunidade apelidou de Denial-of-Wallet (DoW). O nome não está no paper, a mecânica está.

É o tipo de ataque que um dashboard de "erros 5xx" nunca pega. Tudo respondeu 200. Tudo demorou o que tinha que demorar. Só que custou 142 vezes mais.

Seis defesas pra endurecer hoje

Fechar 100% desse espaço é impossível. Sair do grupo dos 38% é tarefa de uma tarde. Essas seis ações são as que aplico primeiro quando reviso um mcpServers alheio, priorizadas por esforço/dano evitado.

1. Exija autenticação em cada servidor MCP que você exponha. OAuth 2.1, mTLS ou no mínimo API key com rotação. Se não suporta nenhum dos três, não coloca atrás de endpoint público.
2. Atualize o mcp-remote pra 0.1.16+ se o seu cliente usa (CVE-2025-6514). Quase todo tutorial de instalação que o Google traz ainda aponta pra versão vulnerável.
3. Menor privilégio nas tools. Não habilite o "combo completo" de uma integração; ative só as tools que o agente realmente precisa. Cada tool extra amplifica os 78,3% da Unit 42.
4. Audite as descrições de tool no olho. É chato. É o único MCP03 que dá pra matar sem ferramenta comercial. Cinco minutos por servidor, uma vez por mês.
5. Trave versão de dependência. Ataque de supply chain (typo-squatting tipo mcp-server-s1ack) é o vetor barato favorito. package-lock.json não é enfeite.
6. Humano no loop pra operação sensível. Escrita em produção, transferência, delete. Se o agente consegue fazer sozinho às 3 da manhã, alguém pode fazer por ele às 3 da manhã.

Nenhuma das seis pede orçamento. Todas pedem trocar o reflexo "conectei porque funcionou" por "conectei depois de olhar". Essa é a troca cara.

O que fica

MCP está entrando na infra de agentes no ritmo em que o Kubernetes entrou na de contêiner. A diferença é que o Kubernetes teve dez anos pra fazer autenticação virar padrão. O MCP, hoje, trata como opcional, e 38% do ecossistema levou a palavra ao pé da letra. Os 30 CVEs em 60 dias, o CVSS 9.6 no cliente, o 142,4× na fatura e o 78,3% de sucesso com cinco servidores não são previsão catastrófica: são medição deste ano, cada uma com fonte. A boa notícia é que a lista mínima de defesa cabe em seis itens e numa tarde.

Se quiser o mapa completo das dez categorias OWASP MCP com cenário de ataque e contramedida por camada, publiquei um livro sobre isso (por enquanto só em inglês): MCP Security in Practice. Começou como anotação depois de usar MCP em produção. Terminou como o material que eu teria querido antes de conectar o primeiro servidor.

---

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews