Oito correções nos servidores oficiais do MCP mostram onde a ferramenta do agente excede o acesso dado
Os mantenedores do Model Context Protocol corrigiram oito vulnerabilidades nos servidores de referência filesystem, everything e fetch. Cada uma é um limite que cabia à ferramenta, não ao agente.
Ouça este artigo · 5 min
Narração completa do artigo, gerada por IA.
Um desenvolvedor está testando um agente localmente. O servidor MCP que ele usa roda sobre HTTP para que uma segunda ferramenta consiga alcançá-lo, e o shell do desenvolvedor guarda uma chave de nuvem em uma variável de ambiente. Em outra aba do navegador, o desenvolvedor abre uma página comum. Até 25 de outubro, se esse servidor fosse o pacote oficial server-everything, a página podia chamar uma ferramenta que retorna as variáveis de ambiente do processo e ler a chave.
Nenhum modelo errou nesse cenário. As instruções, permissões e guardrails do agente eram irrelevantes. O próprio servidor de ferramentas estava acessível a qualquer um que conseguisse fazer um navegador enviar uma requisição.
Esse caso é uma de oito vulnerabilidades corrigidas em 25 de outubro na versão 2.1.0 do repositório oficial de servidores do Model Context Protocol, em três servidores de referência: filesystem, everything e fetch. Nenhuma delas está na especificação do MCP. Todas estão na camada que transforma “o agente pode usar esta ferramenta” naquilo que a ferramenta de fato alcança.
Cada correção restaura um limite que cabia à ferramenta segurar
| O que deu errado | Limite restaurado | Corrigido em | |
|---|---|---|---|
| filesystem (4 correções) | Trocas de symlink redirecionando escritas, uma verificação de caminho que aparava aspas e espaços, symlinks com variação de maiúsculas, tamanhos de arquivo vazando nas listagens de diretório | Os diretórios permitidos | 2.0.1 |
| everything (1 correção) | Transportes HTTP e SSE abertos a qualquer origem web, sem autenticação | A máquina do desenvolvedor e seus segredos | 2.0.1 |
| fetch (3 correções) | Nome de host verificado de uma forma e conectado de outra, endereços NAT64 envolvendo IPs privados, robots.txt ignorado após redirecionamentos | A rede interna e as regras do site | 2026.10.24 |
Filesystem é o servidor mais provável de ser copiado para agentes reais, já que ler e escrever arquivos é a primeira coisa que as pessoas querem que um agente de código ou de documentos faça. Suas quatro correções tratam da mesma promessa: o agente trabalha dentro dos diretórios que você configurou e em nenhum outro. Uma delas é uma corrida em que um diretório pai trocado por um link simbólico podia mandar uma escrita para fora deles. Os mantenedores observam que essa correção é só parcialmente eficaz no Windows e o advisory descreve como configurar para contornar o que resta. Outra era uma verificação que removia uma aspa ou um espaço no fim, então uma pasta irmã com nome parecido passava como permitida.
Everything é um servidor de teste que exercita todos os recursos do MCP, e é por isso que ele tem uma ferramenta que despeja variáveis de ambiente. O problema não era essa ferramenta; era que os transportes HTTP escutavam em todas as interfaces de rede, aceitavam qualquer origem e não exigiam autenticação. O transporte stdio padrão não foi afetado. O conselho do advisory (GHSA-mvf5-2qqv-rg3c) vale muito além deste pacote: não rode transportes HTTP com credenciais reais no ambiente.
Fetch busca páginas web para um agente, o que o torna um risco clássico de server-side request forgery: o agente pede uma URL e o servidor chega a algum lugar aonde o agente não deveria. Duas de suas correções fecham caminhos para alcançar endereços internos fazendo o endereço que foi verificado diferir do endereço ao qual se conectou.
O caminho de upgrade tem uma armadilha
Os servidores TypeScript passaram de versões baseadas em data (como 2025.9.24) para versões semânticas na 1.0.0. Os gerenciadores de pacotes colocam a 2.0.1 abaixo de qualquer versão 2025.x e 2026.x, então um time que está numa versão de data não vai receber a correção. É preciso instalar a 2.0.1 explicitamente. O servidor fetch, publicado no PyPI, está corrigido na 2026.10.24.
Vale fazer essa busca em repositórios, máquinas de desenvolvedores e imagens de agentes esta semana, porque servidores de referência têm um jeito de acabar em produção. Eles são documentados, fáceis de iniciar e muitas vezes a primeira coisa que um protótipo usa.
Onde fica, de fato, o limite de um agente
Escrevemos que o MCP padroniza como os agentes se conectam a ferramentas, mas não as governa, e que um gateway pode bloquear as ferramentas que um agente chama. Esta versão acrescenta a camada de baixo: até uma chamada de ferramenta permitida é tão segura quanto o servidor que a executa. Um agente com permissão para escrever em /data/reports conta com o servidor filesystem para que isso seja verdade. Um agente com permissão para buscar páginas públicas conta com o servidor fetch para recusar endereços internos.
Para times que rodam MCP em produção, seguem três perguntas práticas:
- Quais servidores MCP rodamos, em quais versões, e quem os atualiza? A maioria das organizações consegue listar seus agentes. Poucas conseguem listar os servidores por trás deles.
- O que garante o limite se o servidor falhar? Um servidor filesystem dentro de um contêiner com apenas o volume permitido montado, ou um servidor fetch em um segmento de rede sem rota para endereços internos, sobrevive ao próximo bug desse tipo.
- Quais servidores escutam em uma porta de rede? Servidores stdio herdam a segurança do processo que os inicia. Servidores HTTP precisam de autenticação, verificação de origem e um endereço de bind escolhido de propósito.
O agente decide qual ferramenta chamar. O servidor de ferramentas decide o que essa chamada alcança. Revisões de segurança que param na primeira decisão estão revisando metade do sistema.