Servidores MCP sem autenticação: ~40% nos estudos de 2026

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

Segundo os estudos publicados em 2026, a resposta honesta é “não” em cerca de 4 de cada 10 servidores remotos que estão no ar. Uma medição de 2026 encontrou 40,55% de 7.973 servidores MCP ativos sem nenhuma autenticação. Não é um número que eu medi: é o que as pesquisas independentes deste ano vêm registrando, e cito as fontes ao longo do texto.

Eu uso MCP intensamente e 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.

Os números de 2026, com fonte

Os números não saem de um estudo interno. Saem de pesquisas e scans independentes deste ano, cada um medindo um ângulo diferente.

“~40% sem autenticação” significa que, a cada dez servidores, quatro deixam a porta destrancada. A Censys, por outro ângulo, mapeou 12.520 serviços MCP expostos à internet — mas isso é a contagem de exposição, não a taxa de “sem autenticação”. São duas medições diferentes; não misture as duas. Qualquer cliente HTTP consegue pedir a lista de tools de um servidor sem autenticação 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 ~40%. A especificação do MCP declara a autenticação como opcional. “Opcional”, em produção, significa “ninguém vai colocar”. A mesma medição de 2026 que achou 40,55% sem autenticação ainda encontrou, entre os 119 servidores que implementaram OAuth, 325 falhas de configuração — e 9 CVEs saíram daí. Quando não há autenticação, ninguém quebrou o cadeado: o cadeado nunca esteve lá.

CVEs e achados recentes

Um scan de larga escala, o VIPER-MCP, varreu cerca de 40.000 repositórios de servidores e desenterrou 106 zero-days e 67 CVEs. Não é um incidente isolado: é o retrato de um ecossistema quase sem defesa. Vale ler alguns casos com calma — a imprensa tende a embolar tudo em “servidor sem auth”, e nem toda falha é a mesma coisa.

CVE-2025-54136 (MCPoison) — CVSS 7.2 (valor atribuído pelo CNA; o NVD pode registrar outro). Depois que o usuário aprova um arquivo de configuração MCP uma vez, um atacante troca o conteúdo por um comando malicioso sem que haja novo aviso nem nova aprovação. Foi reportada pela Check Point contra o Cursor e corrigida na v1.3. A confiança de “eu já aprovei isso” ficou desprotegida contra a troca posterior do conteúdo, e dela nasce execução de código persistente.

Command injection em MCP de nuvem não oficiais. A Trend Micro encontrou 1.467 servidores de AWS/Azure MCP não oficiais com command injection de CVSS 9.8. Aqui o input do usuário vira comando de sistema por falha de implementação — e quanto mais tool carregada numa sessão, mais maneira de uma puxar o modelo para 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.

Uma pesquisa publicada no arXiv documentou o caso: 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 — por isso o nome Denial-of-Wallet (DoW).

É 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 ~40% é 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. Registre logs das chamadas de tool. Sem telemetria você não reconstrói o que o agente fez depois do incidente. É o mínimo pra transformar “aconteceu alguma coisa” em “aconteceu isso, nesta tool, com este argumento”.
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 aumenta a chance de uma puxar o modelo pra outra.
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 cerca de 40% do ecossistema levou a palavra ao pé da letra. Os 106 zero-days e 67 CVEs do VIPER-MCP, os 1.467 servidores com CVSS 9.8 da Trend Micro e o 142,4× na fatura do DoW 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.

---

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