Milhares de servidores MCP expostos a falhas críticas de segurança estão acendendo um alerta vermelho para toda a cadeia de suprimentos de IA. Esses servidores, baseados no Protocolo de Contexto de Modelo (MCP) e amplamente usados para conectar grandes modelos de linguagem (LLMs) a sistemas externos, foram identificados como vulneráveis a uma série de ataques graves, como acesso arbitrário a arquivos, injeção de comandos, SSRF (Server-Side Request Forgery), injeção de SQL e negação de serviço.
Uma análise em larga escala examinou 9.695 servidores MCP hospedados em diretórios e repositórios populares, incluindo grandes plataformas de código e catálogos de extensões para agentes de IA. O resultado desmonta uma suposição muito comum no mercado: métricas como número de estrelas, popularidade do projeto, frequência de commits ou até selos de verificação não são bons indicadores de segurança. Em outras palavras, o que parece confiável nem sempre é seguro – e isso expõe organizações a riscos sistêmicos justamente no momento em que a adoção de agentes de IA dispara.
Do universo analisado, 5.832 servidores apresentaram algum tipo de problema de segurança, e 2.259 deles continham vulnerabilidades efetivamente exploráveis, bem além de meros deslizes de autenticação. No total, foram mapeadas 4.982 vulnerabilidades distintas, um número que revela o tamanho da superfície de ataque hoje disponível para atores maliciosos.
Entre as falhas identificadas, destacam-se 880 casos de acesso arbitrário a arquivos, permitindo que um atacante leia ou modifique dados sensíveis; 476 vulnerabilidades de injeção de comandos, que abrem brecha para execução remota de código; 422 instâncias de SSRF, que podem ser usadas para atingir serviços internos não expostos à internet; e 211 casos de injeção de SQL, com potencial para comprometer bancos de dados inteiros. Somam-se ainda 490 vulnerabilidades de negação de serviço, capazes de derrubar serviços críticos ou degradar fortemente o desempenho de agentes de IA em produção.
O levantamento também encontrou 155 ataques de cross-site scripting (XSS), falhas de bypass de autorização e 185 ocorrências de injeção de prompts classificadas como comportamento malicioso. Esse último ponto é particularmente preocupante no contexto de LLMs, já que a injeção de prompts pode levar o modelo a executar ações inesperadas, vazar informações ou interagir de forma indevida com sistemas conectados.
Um dado especialmente alarmante: 2.054 servidores MCP não implementavam qualquer mecanismo de autenticação. Isoladamente, a ausência de autenticação não foi tratada como uma vulnerabilidade por si só, pois alguns usos podem ser intencionais e internos. No entanto, quando combinada com outras falhas – como acesso arbitrário a arquivos ou execução de comandos – essa lacuna multiplica o impacto potencial, transformando erros de configuração em brechas graves de segurança.
Os servidores MCP atuam como uma camada intermediária entre agentes de IA e ativos sensíveis: sistemas de arquivos, bancos de dados corporativos, APIs internas, serviços em nuvem, ferramentas de produtividade e até sistemas legados. É por ali que passam os chamados “fluxos de trabalho de agentes”, responsáveis por executar códigos, automatizar rotinas, buscar dados e orquestrar integrações complexas. Esse papel central torna o MCP um ponto extremamente atrativo para atacantes: quem controla o servidor MCP, muitas vezes, controla o que o agente de IA pode ver, fazer e acessar.
A pesquisa mostrou que as vulnerabilidades não aparecem de forma isolada, mas em padrões recorrentes de combinação. Casos de acesso arbitrário a arquivos associados à ausência de autenticação, ou injeção de comandos somada a falhas de validação de entrada, apontam para problemas estruturais de design inseguro. Mais do que erros pontuais de programação, o que se observa é a falta de práticas de desenvolvimento seguro desde o início do projeto: ausência de modelagem de ameaças, pouca atenção a princípios de privilégio mínimo e validação insuficiente de dados recebidos do agente ou de usuários.
Um dos mitos derrubados pelo estudo é a ideia de que “popularidade é sinônimo de segurança”. Projetos com mais de 50 estrelas em grandes plataformas – muitas vezes considerados “confiáveis” pela comunidade técnica e amplamente adotados em ambientes corporativos – se mostraram justamente alguns dos mais arriscados. Quanto mais utilizados, maior o impacto potencial de uma única vulnerabilidade: um bug explorável em um servidor MCP popular pode afetar, em cadeia, milhares de instâncias e integrações.
Esses servidores mais conhecidos tendem a oferecer integrações ricas em funcionalidades, acessando múltiplos serviços externos, APIs e fontes de dados. Essa complexidade adicional frequentemente vem acompanhada de falhas de SSRF, problemas de injeção de prompts e exposição indevida de arquivos locais. Já os servidores de “médio porte”, com algo entre 10 e 49 estrelas, são os mais numerosos no ecossistema e exibem a maior variedade de vulnerabilidades, refletindo um equilíbrio preocupante entre adoção relevante e falta de maturidade em segurança.
Surpreendentemente, nem os repositórios menos visíveis estão livres de risco. Projetos com pouca ou nenhuma estrela – muitas vezes usados em ambientes experimentais, provas de conceito ou aplicações internas – ainda assim apresentaram vulnerabilidades críticas, como execução remota de comandos. A baixa visibilidade não significa menor perigo: se esses servidores forem expostos acidentalmente à internet, ou reutilizados em ambientes de produção sem revisão, tornam-se portas de entrada silenciosas para invasores.
Outro ponto que caiu por terra foi a crença de que alta atividade no repositório – medida pelo número de commits e atualizações – estaria ligada a uma postura mais robusta de segurança. A análise demonstrou que projetos com mais de 100 commits exibiam taxas de vulnerabilidade semelhantes às de repositórios com histórico bem mais modesto. Um possível motivo é que a evolução constante do código aumenta a complexidade e, com ela, o número de caminhos pelos quais uma falha pode surgir, sem que isso venha acompanhado, necessariamente, da implementação de controles de segurança mais rigorosos.
Nem mesmo os mecanismos de verificação oferecidos por diretórios de servidores MCP se mostraram capazes de mitigar significativamente o risco. Ferramentas de inspeção de código automatizadas, validação de propriedade de repositório e selos de “verificado” criam uma percepção de segurança que nem sempre se sustenta na prática. Servidores marcados como verificados apresentaram, em média, números de vulnerabilidades muito próximos aos não verificados, o que reforça a necessidade de auditorias independentes e avaliações de risco específicas para cada caso de uso.
Esse cenário levanta uma preocupação maior: a segurança da cadeia de suprimentos de IA. À medida que empresas conectam seus LLMs a um número crescente de servidores MCP desenvolvidos por terceiros, muitas vezes de código aberto, aumenta a dependência de componentes que nem sempre foram projetados com foco em segurança corporativa. Um único servidor MCP vulnerável pode atuar como vetor inicial de ataque, permitindo movimentação lateral para dentro de redes internas, acesso a dados confidenciais ou manipulação de fluxos automatizados.
Para as organizações, o recado é claro: não basta escolher servidores MCP populares ou “bem avaliados” e presumir que estão prontos para produção. É fundamental estabelecer um processo formal de due diligence de segurança, incluindo revisão de código, testes de penetração, validação de configurações e, sempre que possível, a adoção de ambientes de sandbox para limitar o impacto de um comprometimento.
Também se torna essencial aplicar princípios clássicos de segurança a esse novo contexto: segmentar redes, restringir permissões de acesso a arquivos e bancos de dados, isolar dados sensíveis, registrar e monitorar atividades de agentes de IA e de servidores MCP, além de estabelecer políticas de atualização e correção ágeis. Controles como autenticação forte, uso de tokens de acesso, listas de permissão cuidadosas e logs detalhados devem ser vistos como requisitos mínimos, não opcionais.
Desenvolvedores de servidores MCP, por sua vez, precisam incorporar práticas de segurança desde o início do ciclo de vida do software. Isso inclui validação rigorosa de entrada, tratamento seguro de parâmetros vindos de prompts, limitação clara de recursos expostos ao agente, implementação de mecanismos de autenticação e autorização, bem como revisões de código focadas em encontrar padrões típicos de vulnerabilidades web – de injeções diversas a falhas de exposição de dados.
Outro ponto sensível é a gestão de “ferramentas” oferecidas ao LLM via MCP. Cada nova funcionalidade – seja acesso a um sistema de arquivos, execução de scripts ou integração com uma API interna – deve ser vista como uma ampliação da superfície de ataque. Políticas de privilégio mínimo, limites estritos de escopo e controles de contexto (por exemplo, definir o que o agente pode ou não fazer em determinados cenários) ajudam a reduzir drasticamente o potencial de abuso.
À medida que agentes de IA passam a tomar decisões e executar ações de forma cada vez mais autônoma, a confiança no ecossistema que os cerca se torna crucial. Os dados levantados sobre os milhares de servidores MCP vulneráveis funcionam como um alerta antecipado: a segurança da IA não se resume ao modelo em si, mas a toda a infraestrutura que o conecta ao mundo real. Ignorar esse aspecto é abrir mão de uma das camadas mais importantes de proteção em um cenário de ameaças cada vez mais sofisticado.
No fim, a mensagem central é direta: a adoção de MCP e de agentes de IA deve caminhar lado a lado com uma estratégia sólida de segurança. Popularidade, atividade e selos de verificação não substituem auditoria, teste e governança. Quem investe em IA sem tratar a segurança dos servidores MCP como prioridade está construindo automação avançada sobre uma base potencialmente frágil – e, mais cedo ou mais tarde, essa fragilidade pode ser explorada.