MCP-in-SoS: Risk assessment framework for open-source MCP servers

Este artigo apresenta um framework de avaliação de riscos para servidores MCP de código aberto, utilizando análise estática de código e mapeamento de ameaças para identificar vulnerabilidades críticas e propor diretrizes para o desenvolvimento seguro desses sistemas.

O essencial

Imagine que os Modelos de Linguagem (LLMs), como o ChatGPT ou o Claude, são como gerentes de escritório superinteligentes. Eles são ótimos para pensar, escrever e planejar, mas são "cegos" e "mãos atadas": não podem acessar seus arquivos, verificar o clima ou enviar e-mails sozinhos.

Para resolver isso, criaram uma nova tecnologia chamada MCP (Model Context Protocol). Pense no MCP como um sistema de "caixas de ferramentas" universais. Em vez de cada gerente ter que aprender uma linguagem diferente para usar cada ferramenta, o MCP cria uma interface padrão. Assim, o gerente pode pegar qualquer ferramenta (um servidor MCP) da prateleira e usá-la imediatamente.

O problema? Como essas ferramentas são de código aberto (qualquer um pode baixar e usar), muitas foram construídas às pressas, com falhas de segurança. É como se alguém deixasse as portas da casa destrancadas e as janelas abertas para o gerente entrar, sem verificar se o prédio está seguro.

Aqui está o que os autores deste estudo fizeram, explicado de forma simples:

1. O Grande Inventário (O que eles fizeram)

Os pesquisadores decidiram fazer uma "vistoria de segurança" em larga escala. Eles pegaram 222 servidores MCP (essas ferramentas) que estavam disponíveis publicamente no GitHub (um site onde programadores guardam seu código) e analisaram o código deles como se fossem detetives procurando por buracos na cerca.

Eles usaram três tipos de "lentes" diferentes (ferramentas de análise automática) para encontrar erros comuns de programação, chamados de CWE (Enumeração de Fraquezas Comuns).

2. A Metodologia: O "Sistema de Pontuação de Risco"

Não basta apenas achar o erro; é preciso saber o quão perigoso ele é. Para isso, eles criaram um sistema de pontuação inteligente:

• CWE (O Erro): É como identificar que a fechadura da porta está quebrada.
• CAPEC (O Ataque): É como entender como um ladrão usaria essa fechadura quebrada para entrar (chutando a porta, usando um gancho, etc.).
• A Fórmula: Eles combinaram a probabilidade de alguém tentar o ataque com a gravidade do que aconteceria se o ataque tivesse sucesso.
  • Analogia: Se a fechadura está quebrada (erro) e é uma porta de um cofre (impacto alto), o risco é extremo. Se a fechadura está quebrada mas é a porta de um galpão de lixo (impacto baixo), o risco é menor.

3. As Descobertas Chocantes

Os resultados foram preocupantes:

• A Maioria Está Vulnerável: De cada 100 servidores analisados, 86 tinham pelo menos uma falha grave. É como se 86% das casas na rua tivessem a porta destrancada.
• O Perigo Real: A maioria desses servidores caiu nas faixas de "Alto" ou "Muito Alto" risco. Isso significa que, se um hacker mal-intencionado usar um desses servidores, ele pode:
  • Roubar dados secretos (confidencialidade).
  • Alterar ou apagar arquivos (integridade).
  • Parar o serviço completamente (disponibilidade).
• O Efeito Dominó: O estudo descobriu que os erros raramente acontecem sozinhos. Geralmente, há uma falha na "porta de entrada" (Protocolo) que permite ao hacker chegar até as ferramentas (Ferramentas) e aos arquivos (Recursos). É como se a cerca estivesse caída, permitindo que o ladrão chegue até a porta da frente, que também está aberta, para entrar no cofre.

4. As Quatro Áreas de Ataque

Os pesquisadores classificaram os problemas em quatro categorias, como se fossem diferentes pontos de entrada em uma casa:

1. Protocolo (A Cerca): Falhas na comunicação entre o gerente e a ferramenta. É a área mais comum de falhas (57% dos riscos).
2. Recursos (O Cofre): Falhas que expõem dados sensíveis ou arquivos.
3. Ferramentas (As Chaves): Falhas nas próprias funções que o servidor executa (como injeção de código).
4. Prompts (O Comando): Falhas onde o hacker engana o "gerente" para que ele dê ordens erradas (como um funcionário sendo enganado para abrir a porta).

5. A Conclusão e o Aviso

O estudo conclui que, embora o MCP seja uma tecnologia incrível e necessária para o futuro da Inteligência Artificial, ela está sendo implantada de forma insegura.

Os autores não apenas apontaram os problemas, mas também criaram um mapa para que os desenvolvedores saibam onde corrigir. Eles avisaram que, se não corrigirmos essas falhas agora, os agentes de IA do futuro poderão ser usados para causar danos reais e automatizados em larga escala.

Em resumo: É como construir uma cidade futurista onde os robôs podem fazer qualquer coisa, mas os construtores esqueceram de trancar as portas e janelas. Este estudo é o relatório de um inspetor de segurança dizendo: "Ei, 86% das casas estão abertas! Precisamos fechar essas portas antes que os ladrões cheguem."

Resumo técnico

Resumo Técnico: MCP-in-SoS

1. O Problema

O Model Context Protocol (MCP) emergiu rapidamente como um padrão aberto para conectar Agentes de Grandes Modelos de Linguagem (LLMs) a ferramentas e fontes de dados externas. Embora o protocolo ofereça uma interface padronizada e segura por design, a proliferação de servidores MCP de código aberto (open-source) criou um cenário de risco significativo.

• Gap de Pesquisa: Embora existam taxonomias de ameaças e demonstrações de ataques teóricos, não havia estudos anteriores que realizassem uma avaliação sistemática e em larga escala das vulnerabilidades de implementação (nível de código) em servidores MCP reais.
• Risco de Segurança: Servidores MCP operam com privilégios elevados do processo hospedeiro e podem acessar recursos sensíveis (sistema de arquivos, APIs, credenciais). Falhas de implementação comuns podem ser amplificadas pelo ciclo de raciocínio do agente, permitindo cadeias de exploração multi-estágio que comprometem confidencialidade, integridade e disponibilidade.

2. Metodologia (MCP-in-SoS)

Os autores propõem o MCP-in-SoS, um pipeline automatizado de quatro estágios para detectar, normalizar e priorizar vulnerabilidades em servidores MCP. O processo integra análise estática de código com metadados de segurança padronizados.

• Estágio 1: Análise de Código Estático
  • Foram analisados 222 repositórios Python do GitHub que implementam servidores MCP.
  • Utilizaram-se três ferramentas de análise:
    1. CodeQL: Para identificar padrões de vulnerabilidade bem estudados.
    2. Joern: Para gerar um Code Property Graph (CPG) e executar consultas personalizadas alinhadas ao Top 25 CWE de 2025.
    3. Cisco AI Defender MCP Scanner: Usado em um subconjunto para detectar comportamentos de risco específicos de MCP e padrões maliciosos.
• Estágio 2: Preparação de Metadados
  • Integração dos bancos de dados CWE (Common Weakness Enumeration) e CAPEC (Common Attack Pattern Enumeration and Classification) da MITRE.
  • Tratamento de dados faltantes: Como muitos campos de "Probabilidade de Exploração" (CWE) e "Probabilidade de Ataque" (CAPEC) estavam ausentes, os autores desenvolveram um processo de imputação baseado em mapeamentos hierárquicos (ex: herdar atributos de classes pai ou irmãos no CWE).
• Estágio 3: Normalização
  • Consolidação dos resultados das ferramentas, mapeamento para identificadores CWE únicos e eliminação de duplicatas por repositório.
• Estágio 4: Pontuação de Risco (Risk Scoring)
  • Índice de Risco (R): Calculado para cada falha ($w$) usando a fórmula: $R(w) = \text{Likelihood}(w) \times \text{Impact}(w)$.
    • Likelihood: Produto da Probabilidade de Ataque (CAPEC), Probabilidade de Exploração (CWE) e Número de Modos de Introdução.
    • Impact: Produto da Severidade Típica (CAPEC) e Número de Consequências Comuns (CWE).
  • Pontuação do Repositório: Combina a severidade das falhas com a frequência de ocorrência, utilizando uma abordagem de Raiz Média Quadrática (RMS) ponderada e um fator de escala logarítmica para evitar que repositórios com muitas falhas de baixo risco dominem a pontuação.

3. Principais Contribuições

1. Avaliação em Larga Escala: A primeira análise sistemática de 222 repositórios públicos de servidores MCP Python.
2. Pipeline Reprodutível: Um fluxo de trabalho que combina analisadores estáticos (CodeQL, Joern) com verificação assistida por LLM para mapear descobertas para classes CWE/CAPEC.
3. Consultas Joern Personalizadas: Um conjunto de 54 consultas alinhadas ao CWE Top 25 de 2025, geradas e refinadas para detectar padrões de fraqueza específicos em servidores MCP Python.
4. Modelo de Pontuação de Risco: Um modelo baseado em metadados CWE-CAPEC que gera métricas de risco tanto no nível da falha quanto no nível do repositório.
5. Taxonomia de Superfícies de Ameaça: Uma classificação alinhada ao MCP (Protocolo, Ferramenta, Recurso, Prompt) e uma análise de co-ocorrência condicional que revela cadeias de exploração.

4. Resultados Chave

• Prevalência de Vulnerabilidades: 86,0% (191 de 222) dos repositórios analisados continham pelo menos uma fraqueza mapeada.
• Nível de Risco: A maioria dos repositórios (47,6%) caiu na faixa de Alto Risco, e 18,3% foram classificados como Risco Muito Alto. Apenas 0,5% foram classificados como "Muito Baixo".
• Fraquezas Mais Comuns: As cinco classes CWE mais frequentes representaram 75,7% de todas as falhas encontradas:
  1. CWE-862 (Falta de Autorização) - 30,4%
  2. CWE-200 (Exposição de Informações Sensíveis) - 15,9%
  3. CWE-306 (Falta de Autenticação) - 15,3%
  4. CWE-287 (Autenticação Improper) - 7,4%
  5. CWE-89 (SQL Injection) - 6,7% (Notável por ser frequente e de alto risco).
• Superfícies de Ameaça:
  • A superfície de Protocolo dominou tanto a prevalência (56,9% das falhas) quanto a exposição de risco (57,1%).
  • Falhas em Ferramentas (Tools) e Recursos (Resources) são menos frequentes, mas contribuem desproporcionalmente para o risco devido ao seu potencial de impacto.
• Cadeias de Exploração (Co-ocorrência):
  • As fraquezas raramente ocorrem isoladamente.
  • 87% dos repositórios com falhas em Ferramentas também tinham falhas no Protocolo.
  • 88% dos repositórios com falhas em Recursos tinham falhas no Protocolo.
  • Isso indica que falhas de controle de acesso no protocolo atuam como um "multiplicador de alcance", permitindo que atacantes explorem falhas subsequentes em ferramentas e recursos.

5. Significância e Conclusão

O estudo demonstra que o ecossistema atual de servidores MCP open-source apresenta uma exposição de segurança substancial. A abordagem "seguro por design" ainda não é a norma na implementação desses servidores.

• Implicações: A dependência de servidores MCP para agentes de IA em produção exige uma revisão urgente das práticas de desenvolvimento. A combinação de falhas de protocolo com falhas de ferramentas cria vetores de ataque complexos que podem levar a vazamento de dados ou execução de código não autorizado.
• Recomendações: Os autores enfatizam a necessidade de auditorias automatizadas, implementação de controles de acesso rigorosos e a adoção de práticas de segurança (como arquivos SECURITY.md) para facilitar a divulgação responsável de vulnerabilidades.
• Limitações: O estudo focou apenas em servidores Python; a distribuição de fraquezas pode variar em outras linguagens (ex: TypeScript). Além disso, a pontuação de risco baseia-se em metadados teóricos, que podem divergir do risco real em contextos de implantação específicos.

O trabalho fornece uma base empírica sólida para pesquisadores e desenvolvedores priorizarem a segurança no desenvolvimento de agentes de IA e seus conectores de ferramentas.