Existe uma cadeia de quatro passos que transforma um recurso banal de servidor MCP em comprometimento de conta de nuvem. Ela não depende de nada exótico. Depende de um servidor que busca uma URL fornecida por quem está do outro lado.
A cadeia, passo a passo
Primeiro, o servidor MCP expõe uma ferramenta que aceita URL — converter documento, buscar página, ler feed. Segundo, ele faz a requisição do lado do servidor, sem validar o destino. Terceiro, ele roda numa instância de nuvem que alcança o endpoint de metadados do provedor. Quarto, alguém aponta a ferramenta para esse endpoint e recebe de volta credencial temporária de IAM.
Isso não é hipotético. A BlueRock Security analisou mais de 7 mil servidores MCP e concluiu que cerca de 36,7% eram potencialmente vulneráveis a SSRF. Na prova de conceito contra o servidor MarkItDown da Microsoft, os pesquisadores extraíram chave de acesso, chave secreta e token de sessão da AWS pelo endpoint de metadados de uma instância EC2.
Um servidor mal configurado virou caminho direto para as credenciais da infraestrutura de nuvem.
Repare no que não aconteceu: nenhum bypass de autenticação, nenhum zero-day, nenhuma manipulação do modelo. SSRF entrou no OWASP Top 10 em 2021 e já era conhecido muito antes disso. O componente é de 2025; a falha é de sempre.
Por que a nuvem torna isso pior
Em servidor tradicional, SSRF te dá acesso a serviços internos — ruim, mas limitado. Em instância de nuvem, o endpoint de metadados é um serviço HTTP sem autenticação, alcançável a partir de qualquer processo da máquina, que entrega credenciais da role anexada. É a diferença entre pular um muro e receber a chave da casa.
E a role anexada a uma instância que roda agente costuma ser generosa, porque ninguém sabia de antemão quais ferramentas o agente ia precisar chamar.
Como cortar a cadeia
Você não precisa quebrar os quatro elos. Um só resolve, e há controles com custo quase zero:
- Exija IMDSv2 e proibia IMDSv1. A versão 2 usa token via PUT com header próprio, o que derruba SSRF ingênuo baseado em GET. Na AWS,
HttpTokens=required. No GCP, o headerMetadata-Flavor: Googlecumpre papel parecido — mas só se você não permitir que a ferramenta controle headers. - Defina
HttpPutResponseHopLimit=1para que a resposta não atravesse camadas de container. - Bloqueie 169.254.169.254 na saída do processo que aceita entrada não confiável. Regra de nftables ou netpol resolve.
- Valide o destino antes de buscar: resolva o DNS, rejeite faixas privadas e link-local, e refaça a checagem após redirecionamento — senão um 302 anula sua validação.
- Elimine a credencial de longa duração com federação de identidade de carga de trabalho. Se não há chave estática na instância, o prêmio do ataque encolhe.
O teste de dez minutos
Liste as ferramentas dos seus servidores MCP e marque as que recebem URL, caminho de arquivo ou host como argumento. Para cada uma, pergunte se o processo consegue alcançar 169.254.169.254. Se conseguir, você tem a cadeia inteira montada esperando alguém percorrê-la.
