Exposto por Design: uma auditoria em tempo real de 414 servidores MCP expostos à internet encontrou 68 vulnerabilidades

Em 31 de julho de 2026 Nicolás Padilla publicou Exposed by Design (arXiv:2608.00150), um preprint de 13 páginas que descreve o que ele chama de primeira avaliação dinâmica de segurança comportamental de servidores Model Context Protocol expostos à internet. Quatro rodadas de medição naquele mês confirmaram 640 servidores de produção ativos, dos quais 414 foram testados ativamente; os testes produziram 68 vulnerabilidades reportáveis, todas registradas junto aos mantenedores como GitHub Security Advisories. 380 dos 414 — 91,8% — não tinham autenticação OAuth, e 687 instâncias de ferramentas anunciavam execução de shell sem controles de acesso. Padilla não relata evidência de que qualquer uma delas estivesse sendo explorada: os testes permaneceram em prova de conceito, nenhuma credencial foi obtida e nenhum dado foi exfiltrado. A lista completa de fontes do registro, a nota de gravidade e a avaliação de confiança estão em o arquivo de incidentes de IA, ao lado de outras descobertas de MCP e infraestrutura registradas em torno dele.

O que a auditoria realmente fez

O Model Context Protocol é a interface que permite a um agente de IA chamar ferramentas hospedadas em outro lugar — uma busca de documentos, uma consulta a banco de dados, um auxiliar de shell. Um servidor que o utiliza via HTTP e é acessível pela internet é, na prática, uma superfície de ferramentas que qualquer pessoa pode endereçar. O artigo de Padilla argumenta que a população desses servidores nunca foi contada adequadamente e que contá-los é o objetivo: a descoberta é a parte difícil, e todo levantamento anterior examinou uma fatia diferente.

A sua etapa de descoberta combinou onze fontes — crt.sh, Hugging Face, GitHub, npm, Smithery, PyPI, Censys, FOFA, Shodan, glama.ai e pulsemcp.com — com o argumento de que nenhuma delas, isoladamente, captura a população. A etapa ativa usou Corvus, um framework que Padilla criou para o estudo: 34 módulos de teste cobrindo 10 classes de vulnerabilidade específicas de MCP, divididos em 13 estáticos e 21 dinâmicos. Ele está publicado no GitHub sob a organização CobaltoSec e no PyPI como cobaltosec-corvus, e o próprio arquivo de estatísticas do repositório registra a mesma contagem de 34 módulos.

As quatro execuções ocorreram em 15, 18, 21 e 24 de julho de 2026. As execuções anteriores contribuíram apenas com números de confirmação; as três últimas examinaram 3.485, 3.948 e 4.110 candidatos e confirmaram 140, 464 e 296 servidores ativos, respectivamente. A desduplicação de 972 observações brutas com 332 aparições repetidas deixou 640 servidores únicos confirmados, dos quais 414 — 64,7% — aceitaram testes dinâmicos completos. Padilla considera 640 um limite inferior. A Censys, uma das fontes de descoberta, tinha estimado mais de 21.000 endpoints relacionados a MCP em todo o mundo em maio de 2026, e ele usa isso como estimativa de escala, e não como uma contagem do que testou.

Lidos como um funil, os números são o verdadeiro argumento do artigo: uma passagem ampla e barata encontra candidatos mais rápido do que uma passagem cuidadosa consegue testá-los. Apenas 414 dos 640 servidores confirmados foram totalmente exercitados, e Padilla não afirma que o subconjunto testado se assemelhe ao restante não testado.

O que encontrou

A principal conclusão é a autenticação, ou a ausência dela. Dos 414 servidores testados, 380 (91,8%) não tinham OAuth. O artigo afirma que a maioria dos restantes usava tokens bearer estáticos ou chaves de API, frequentemente previsíveis ou vazios — um servidor que aceita uma string fixa também não está autenticado de forma significativa. Como a auditoria testou apenas servidores que eram publicamente acessíveis sem credenciais, este número descreve a população exposta por construção; não é uma estimativa para servidores MCP em geral.

Os 68 achados reportáveis se dividem por classe, e as contagens por classe se sobrepõem em vez de particionar o total: 380 deficiências de autenticação, 52 instâncias de aceitação de fuzzing de protocolo, 47 envenenamento de ferramentas, 38 injeção de comando, 31 bypass de esquema, 29 falsificação de solicitação do lado do servidor, 24 manipulação de URI de recurso, 22 injeção de prompt, 18 exposição de token e 14 indicadores de cadeia de suprimentos. Módulos de negação de serviço foram escritos, mas deliberadamente não executados contra servidores de produção, que Padilla exclui por questões éticas. Os quatro tipos de vulnerabilidade nomeados no resumo — injeção de SQL, SSRF contra serviços de metadados na nuvem, injeção de template de prompt e path traversal via manipulação de cursor — aparecem cada um dentro dessas classes.

O dado sobre execução de shell exige uma ressalva que o artigo não resolve. Em sua seção de resultados, 687 instâncias de ferramentas com execução de shell e sem autenticação são contabilizadas no conjunto confirmado de 640 servidores. Na discussão, o mesmo número é introduzido com as palavras “dos 414 servidores auditados dinamicamente” e depois é feita referência ao “conjunto confirmado mais amplo”. As duas formulações não concordam, e o artigo nunca fornece uma contagem total de ferramentas para os servidores testados, então 687 não pode ser convertido em porcentagem.

A rotatividade é o achado que mais altera a forma como os números devem ser lidos. Dos 464 servidores confirmados em 21 de julho, 193 — 41,6% — já não existiam quando a quarta execução verificou três dias depois. Nove dos 41 servidores com um achado CRÍTICO também haviam desaparecido. Padilla interpreta isso como implantação sem revisão; também significa que um achado confirmado na segunda-feira pode não ter dono para corrigi-lo até quinta-feira.

Os três estudos de caso e o que pode ser verificado

Três descobertas estão documentadas em detalhe, cada uma com um identificador de Aviso de Segurança do GitHub. Uma injeção de SQL em lectorium-corpus-mcp (GHSA-m8qh-p8m5-8c48, classificada como CRÍTICA) foi confirmada com o payload ' OR 1=1 -- e um diferencial no tamanho da resposta, sem que nenhum conteúdo de documento tenha sido lido ou retido. Um SSRF em epwforge (GHSA-r9fx-qwmc-rvx3, ALTA) foi confirmado por temporização: 11,9 segundos contra um endereço interno de metadados versus uma linha de base de 0,3 segundo, sem que nenhum conteúdo da resposta de metadados tenha sido armazenado. Uma injeção de template de prompt em frootai (GHSA-5h8f-r9g8-5w5p, ALTA) completa o conjunto.

Dois dos três podem ser verificados diretamente. Em 30 de outubro de 2026, as duas primeiras páginas de avisos resolveram publicamente no repositório de avisos da CobaltoSec, ambas publicadas em 20 de agosto de 2026, ambas ainda listando "Patched versions: None" e nenhum CVE. O terceiro, GHSA-5h8f-r9g8-5w5p, retornou como não encontrado nesse endereço. O repositório da CobaltoSec listava 46 avisos publicados na mesma data, abrangendo servidores MCP e ferramentas de IA adjacentes; o artigo contou 19 como divulgados publicamente e 49 ainda sob embargo quando foi escrito. Um artefato de varredura de frootai datado de 28 de julho de 2026 está no repositório Corvus, então o teste aconteceu; apenas o aviso não está visível.

O processo de divulgação em si é descrito em linhas gerais, e não em detalhes. Todos os 68 achados foram enviados aos mantenedores por meio de GitHub Security Advisories privados, sob um embargo coordenado de 90 dias, e, quando o relato privado não estava disponível, Padilla abriu uma issue pública no repositório. O artigo relata, de forma anecdótica, que alguns mantenedores aplicaram correções em até 24 horas, outros ficaram semanas sem responder, e alguns repositórios foram abandonados. Não informa o número de mantenedores contatados nem apresenta uma tabela de taxas de resposta, afirmando que esses dados serão apresentados integralmente no momento da submissão.

O que o artigo não estabelece

Exposed by Design é um preprint de autor único. O arXiv lista a versão 1, submetida em 31 de julho de 2026, sem referência a periódico e sem declaração de revisão por pares. O arquivo atribui ao registro a confiança B — documentado, mas proveniente de uma única fonte — e essa classificação vale para todo este texto: cada número acima vem do artigo de Padilla ou de artefatos que ele publica, não de uma medição independente.

Nenhuma redação independente parece ter noticiado o estudo. Existe cobertura — uma análise escrita por IA no forkast.news, publicações no LinkedIn e no Medium, um blog de segurança em chinês, um texto explicativo em japonês —, mas ela parafraseia o preprint sem entrevistar o autor, verificar os avisos ou acrescentar dados. Cobertura derivada não é corroboração.

O próprio Padilla declara os limites, e estes são invulgarmente específicos. Apenas foram testados transportes HTTP; os servidores stdio, o caso local comum, estão fora do âmbito. A descoberta é feita com o melhor esforço possível, pelo que 640 é um limite inferior. Os 226 servidores confirmados que não foram totalmente testados foram excluídos devido a respostas 403, redefinições de ligação, respostas JSON-RPC não conformes ou simplesmente por estarem offline, e o artigo afirma que o viés de seleção resultante não pode ser delimitado. A deteção assenta em heurísticas — oráculos de temporização, respostas diferenciais, inspeção de esquemas — sem qualquer benchmark rotulado e sem precisão ou recall publicados para os 34 módulos. A rotatividade que documenta compromete a validade temporal das constatações individuais. E um único investigador a realizar verificação manual introduz um risco de viés de confirmação que ele nomeia e não quantifica.

O que mudou depois

O resultado prático até agora é a ferramenta e o fluxo de avisos. O Corvus é instalável e está documentado, e o repositório de avisos da CobaltoSec contava com 46 entradas publicadas em 30 de outubro de 2026, contra as 19 divulgações públicas contabilizadas pelo artigo no final de julho. Dois dos próprios estudos de caso do artigo ainda não têm uma versão corrigida — para esses servidores, a divulgação produziu um registro público, mas ainda não uma correção.

Para quem defende sistemas, a parte útil do estudo é o seu método e não o seu resultado de destaque. Um valor de 91,8% obtido apenas a partir de servidores que responderam sem credenciais diz algo estreito e real: a maior parte do que está exposto nunca foi protegida, e a rotatividade de três dias sugere que muito disso foi montado para uma demonstração, um protótipo ou um teste e nunca recebeu reforço de segurança. O que o artigo não pode afirmar é se o mesmo se aplica aos servidores MCP com que as organizações realmente contam, porque esses nunca estiveram na amostra.