Censo do ecossistema MCP encontra exposição de rede sem autenticação e mudanças silenciosas de comportamento em milhares de servidores

O MCP se tornou rapidamente o padrão de facto para conectar aplicações de LLM a ferramentas e serviços externos, mas seu registro público ainda não tem a infraestrutura de vetting que ecossistemas de pacotes mais maduros acumularam ao longo de décadas de incidentes e respostas. O autor buscou quantificar esse gap coletando o snapshot completo do registro público em agosto de 2026 — 21.643 servidores e 72.606 registros de versão —, obtendo código-fonte de 14.353 deles e aplicando um scanner baseado em padrões cobrindo um catálogo de oito classes de ameaça, cuja precisão foi calibrada contra 414 achados rotulados manualmente.

Em prevalência bruta, a classe mais comum é exposição de rede sem autenticação, presente em 9,57% dos servidores escaneados — ou seja, servidores MCP acessíveis publicamente sem qualquer barreira de autenticação antes de expor ferramentas que podem, dependendo da configuração, executar código, acessar arquivos ou fazer chamadas para outros serviços. Depois de corrigir a prevalência observada de achados de severidade alta (11,14%) pela precisão medida do scanner, a taxa real estimada fica em torno de 7,6% — uma correção metodológica importante que mostra o cuidado do autor em não superestimar o problema, mas que ainda assim indica uma fração significativa do ecossistema com problemas sérios.

O achado mais original do estudo, porém, não é sobre nenhuma classe de vulnerabilidade isolada, mas sobre instabilidade: mais da metade dos servidores que já tiveram múltiplas versões publicadas mudaram o que declaram fazer entre uma versão e outra, e em 40,6% dos casos essa mudança não foi comunicada de forma visível. Ainda mais preocupante, 4,2% dos servidores redirecionaram seu endpoint remoto para um host completamente diferente enquanto mantinham a mesma identidade no registro — uma mudança que o protocolo MCP atualmente não expõe de forma alguma para os clientes já instalados, que continuam confiando na mesma "identidade" sem saber que o backend real mudou. Estatisticamente, essa deriva silenciosa está associada a quase o triplo da chance de um achado de severidade alta (odds ratio de 2,96), e a popularidade do servidor (medida em estrelas) oferece proteção muito fraca contra isso.

A implicação prática para quem hoje instala servidores MCP de terceiros em pipelines de agentes é direta: contagem de estrelas ou popularidade no registro não deveria ser tratada como proxy de segurança, e clientes MCP precisam de mecanismos de pinning de versão e de verificação de identidade do endpoint remoto — hoje ausentes na maioria das implementações — para não confiar cegamente em um servidor que pode ter trocado de comportamento, ou até de infraestrutura de backend, sem qualquer sinalização visível ao usuário final.