O SSRF do Azure MCP Server pode vazar seu token de identidade gerenciada para uma URL

A Microsoft publicou a CVE-2026-26118 em 10 de março de 2026: uma falha de falsificação de solicitação do lado do servidor no Azure MCP Server Tools, o pacote que permite que agentes de IA e clientes MCP atuem em recursos do Azure em linguagem natural. Um atacante que consiga interagir com um agente baseado em MCP poderia enviar uma URL maliciosa no lugar de um identificador normal de recurso do Azure; o servidor então enviaria uma solicitação de saída para esse endereço e, nas palavras da Microsoft, “pode incluir seu token de identidade gerenciada” — entregando ao chamador uma credencial que ele nunca deveria ver. A Microsoft atribuiu à falha CVSS 8.8 e classificou-a como Importante, e os pacotes que contêm a correção são 1.0.2 e 2.0.0-beta.17. O aviso não registra exploração nem divulgação pública antes da correção, e nenhum dano real é registrado para ela. Este incidente é uma entrada no o Orca AI Incident Archive, que contém o registro completo com suas fontes citadas, classificação de gravidade e avaliação de confiança.

O que o aviso realmente diz

O registro do Microsoft Security Response Center é sucinto, e quase todos os detalhes publicados sobre esta falha derivam dele ou das respostas da Microsoft a um punhado de perguntas de acompanhamento. A descrição completa: “A falsificação de solicitação do lado do servidor (SSRF) no Azure MCP Server permite que um atacante autorizado eleve privilégios por meio de uma rede.” O registro CVE reservou o identificador em 11 de fevereiro de 2026 e o tornou público em 10 de março às 14:00 UTC; a nota de lançamento da Microsoft e a entrada da NVD trazem ambas essa data. A NVD analisou o registro e o publicou às 18:18 UTC na mesma tarde. O único aviso regulatório encontrado para este artigo veio de Marrocos: a unidade maCERT da DGSSI incluiu o CVE-2026-26118 em um boletim datado de 11 de março de 2026, listando o Azure MCP Server Tools entre os produtos afetados em seu próprio nível de risco Importante, sem pontuação separada e com uma referência à nota de lançamento da Microsoft.

A fraqueza está mapeada para CWE-918, falsificação de solicitação do lado do servidor, e a classificação de impacto é elevação de privilégio. A pontuação base da Microsoft é 8,8 no vetor CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, com uma pontuação temporal de 7,7 em E:U/RL:O/RC:C — o componente E:U significa que nenhum código de exploração era conhecido pela Microsoft quando a pontuação foi definida, e RL:O significa que uma correção oficial estava disponível. O NVD traz a mesma pontuação base e a classifica como Alta; a própria escala de três etapas da Microsoft a chama de Importante.

Dois campos importam tanto quanto a pontuação. O registro da Microsoft diz Explorado: Não e Divulgado publicamente: Não. O registro de decisão do SSVC da CISA na entrada do NVD, com carimbo de data e hora de 5 de março de 2026, concorda quanto à exploração — nenhuma — enquanto avalia o impacto técnico total e automatizável não. O modelo FIRST EPSS colocou a probabilidade de exploração nos próximos 30 dias em cerca de 1,0%, no percentil 62,8, em uma extração datada de 3 de novembro de 2026. Esta é uma falha que foi encontrada e corrigida, não uma que se saiba ter sido usada.

Como um identificador de recurso se torna uma requisição de saída

O Azure MCP Server é a implementação da Microsoft do Model Context Protocol, a interface que agentes de IA usam para chamar ferramentas. Suas ferramentas recebem os parâmetros fornecidos por um agente — um nome de conta de armazenamento, um identificador de assinatura, um nome de banco de dados — e os transformam em chamadas aos planos de gerenciamento e de dados do Azure. A documentação da Microsoft descreve o servidor como autenticando-se por meio do Entra ID usando “suas credenciais de usuário do Azure ou identidade gerenciada”, com acesso limitado pelo controle de acesso baseado em função do Azure.

A falha está no ponto em que um parâmetro que deveria nomear um recurso do Azure é aceito como uma URL. A própria explicação da Microsoft: um atacante “poderia explorar esse problema enviando entrada especialmente criada para uma ferramenta do Azure Model Context Protocol (MCP) Server que aceita parâmetros fornecidos pelo usuário. Se o atacante conseguir interagir com o agente baseado em MCP, ele poderá enviar uma URL maliciosa no lugar de um identificador normal de recurso do Azure.” O servidor então envia a solicitação para onde foi instruído, em vez de para onde a ferramenta pretendia.

A parte que transforma um incômodo em escalada de privilégios é o que vem junto. A Microsoft afirma que a solicitação de saída “pode incluir seu token de identidade gerenciada”, o que permite ao atacante capturar esse token “sem exigir acesso administrativo”. Um token de identidade gerenciada é uma credencial do tipo bearer: quem o detém pode apresentá-lo aos serviços do Azure para os quais essa identidade está autorizada, até que ele expire. A metade mitigadora do mesmo parágrafo é igualmente importante — o atacante obtém “as permissões associadas à identidade gerenciada do MCP Server” e, nas palavras da Microsoft, “não ganha permissões mais amplas no nível de locatário ou de administrador; apenas aquelas vinculadas à identidade gerenciada comprometida”. O raio de impacto é tudo aquilo que alguém concedeu àquela identidade, o que, na prática, costuma ser mais do que uma única ferramenta precisava.

A Microsoft não nomeia a ferramenta ou o parâmetro afetados, e nenhuma fonte revisada para este artigo o faz. Essa omissão é, por si só, um detalhe: o aviso descreve uma classe de ferramenta — uma que aceita parâmetros fornecidos pelo usuário e pode ser induzida a buscar uma URL — em vez de um único endpoint.

A correção, e os pacotes que a carregavam

Esta não foi uma atualização do Windows. O Azure MCP Server Tools é distribuído como um pacote NuGet para .NET, um pacote npm e um pacote Python no PyPI, e a correção é um aumento de versão naquele que uma implantação usar. O aviso da Microsoft lista os intervalos afetados como 1.0.0 até, mas sem incluir, 1.0.2, e 2.0.0-beta.1 até, mas sem incluir, 2.0.0-beta.17, nas distribuições NuGet, npm e PyPI.

As datas do registro npm mostram que as builds corrigidas estavam no registro antes do aviso. A versão 1.0.2 do @azure/mcp foi publicada em 6 de março de 2026, quatro dias antes de a CVE se tornar pública; a 2.0.0-beta.17 foi publicada em 6 de fevereiro de 2026, cinco dias antes de a Microsoft reservar o identificador da CVE e um mês antes de o aviso aparecer. Qualquer que seja a sequência dentro da Microsoft, o código corrigido não foi escrito em resposta ao dia da publicação. O NVD e o banco de dados de avisos do GitHub concordam quanto a esses limites superiores. Eles diferem ligeiramente na parte inferior do intervalo do PyPI — o NVD diz 2.0.0-beta.1, o aviso do GitHub diz 2.0.0b14 — uma discrepância que os dois registros carregam desde a publicação e que afeta apenas até onde uma implantação em Python precisa olhar para trás.

O próprio aviso foi revisado em 20 de março de 2026, dez dias após a publicação, com uma nota de que a Microsoft havia “adicionado à tabela Security Updates produtos que documentam os diversos métodos de empacotamento usados para fornecer o Azure MCP Server Tools.” Em outras palavras, a primeira versão do aviso nomeava o produto, mas não todos os canais pelos quais ele era distribuído, o que importa quando a remediação é “atualizar o pacote” em vez de “instalar este KB.”

O que não está estabelecido

Quem o encontrou. Nem o comunicado da Microsoft nem o registro do CVE.org citam quem reportou; o campo de créditos no CVE está vazio. Isso não é prova de que ninguém tenha sido creditado em particular, apenas de que não existe crédito público.

Qualquer exploração. A Microsoft não registra nenhuma, a avaliação SSVC da CISA concorda, e nenhuma fonte revisada para este artigo descreve uma identidade comprometida em ambiente real. O campo de dano real do registro é falso, consistente com isso. Um EPSS baixo é uma previsão, não uma constatação, e a ausência de um incidente relatado não é prova de que nenhum tenha ocorrido.

Se existe um exploit público. É aqui que a cobertura secundária se divide. Uma publicação de março de 2026 no blog da Blueinfy afirma que existem “exploits públicos de prova de conceito, como os do GitHub” e alerta para uma “armamentização rápida”, mas não fornece link, payload nem passo a passo, e não demonstra a falha. O registro da Microsoft diz que a vulnerabilidade não foi divulgada publicamente antes do patch. Uma pesquisa de repositórios no GitHub pelo identificador da CVE em 4 de novembro de 2026 retornou um repositório — um laboratório de detecção do Microsoft Sentinel publicado em 17 de março de 2026, não um exploit — e a página de vulnerabilidade da Mallory afirma que dois exploits candidatos foram triados e rejeitados. A alegação de que existe código de exploit público funcional é, com base nas evidências disponíveis, infundada; a alegação de que ninguém tentou é igualmente não comprovada.

O enquadramento.Uma página no PolicyLayer, um site de resumos de incidentes de fornecedores, reformula o CVE-2026-26118 como uma cadeia de execução remota de código não autenticada que termina na tomada de controlo total do tenant, atribuindo crédito a um investigador nomeado e a uma demonstração na RSAC 2026. As próprias fontes citadas nessa página têm títulos de SSRF, as suas datas não são compatíveis com a cronologia da CVE, e nem o aviso da Microsoft nem a reportagem da SecurityWeek de 10 de março descrevem execução de código. Este artigo considera a versão do SSRF e do token como a estabelecida e não repete o enquadramento de RCE.

Por que o token, e não a requisição, é o achado

A falsificação de requisição do lado do servidor é uma das classes de bugs mais antigas em software web e, por si só, costuma ser uma forma de alcançar sistemas que o atacante não consegue endereçar diretamente. O que torna este registro digno de ser guardado é a credencial anexada à requisição. O servidor MCP é um confused deputy por concepção: ele detém uma identidade para que um agente possa agir em nome de um usuário, e todo parâmetro que um agente passa é, do ponto de vista do servidor, texto influenciado pelo atacante. Quando um desses parâmetros se torna um destino em vez de um nome, o deputy carrega sua própria autorização para o destino.

A documentação da Microsoft esclarece onde esse risco se concentra. Ela descreve o servidor local como “destinado estritamente ao uso de desenvolvedores dentro da sua organização”, ao mesmo tempo que publica separadamente guias de implantação para servidores remotos auto-hospedados no Microsoft Foundry e no Copilot Studio — as configurações em que uma identidade gerenciada, e não o login do próprio desenvolvedor, costuma ser a credencial em jogo. O caminho de roubo de token descrito no comunicado diz respeito especificamente à identidade gerenciada. Ele não afirma que todas as instalações ficaram expostas, nem quantas foram.

A lição geral é a que o AI Security Verification Standard da OWASP agora usa como caso para ensinar. O capítulo de orquestração do AISVS cita a CVE-2026-26118 entre seus exemplos trabalhados e chega à conclusão de que “os parâmetros de ferramentas MCP devem ser tratados como controlados pelo atacante, e as solicitações de saída dos servidores MCP devem passar pelas mesmas políticas de egresso e de origem esperadas de qualquer outro I/O conduzido por agente”. Isso é uma recomendação de controle, não uma constatação sobre este incidente, mas é a resposta mais concreta que alguém já publicou para a questão do que deveria mudar.

O que mudou depois

Três coisas, e nenhuma delas é dramática. A Microsoft enviou pacotes corrigidos nos três ecossistemas e revisou o aviso para nomeá-los. O ecossistema de inteligência de vulnerabilidades absorveu isso em silêncio: uma pontuação EPSS baixa e um registro do NVD modificado pela última vez em 17 de junho de 2026. E a comunidade de padrões adotou-o como um caso de ensino, que é uma forma de resposta mais lenta e mais duradoura do que um patch.

Para quem ainda executa uma build afetada, a remediação permanece inalterada e pouco glamorosa: atualize para 1.0.2 ou posterior na linha estável, ou para 2.0.0-beta.17 ou posterior na linha de pré-visualização, em todos os gerenciadores de pacotes que a implantação abranger. Além disso, a lógica do próprio comunicado implica três controles — restringir os destinos de saída que o servidor pode alcançar, conceder à identidade gerenciada apenas as funções de que suas ferramentas realmente precisam e tratar qualquer parâmetro de ferramenta que possa se tornar uma URL como entrada hostil. Nenhum deles é obrigatório para ter sobrevivido ao CVE-2026-26118. Cada um reduziria o valor que o próximo teria para um atacante.

Como o arquivo classifica este

O registro é arquivado como uma vulnerabilidade — algo encontrado, não algo sabidamente explorado — com confiança classificada como A, o que significa bem documentado com fontes primárias concordantes, e não está marcado como disputado. Seu campo de dano real é falso e seu envolvimento de IA é confirmado, porque o produto afetado é a ponte entre um agente de IA e um plano de controle em nuvem, e não um serviço de propósito geral que por acaso está por perto. A data é registrada com precisão de dia, 10 de março de 2026, sem data de término, porque este é um único ponto no tempo e não uma campanha. A região é global e o indicador de landmark é falso.

Um campo aparece de forma diferente da pontuação publicada. A gravidade do arquivo é registrada como média, em sua própria escala; o número que tanto a Microsoft quanto o NVD publicam é 8.8, que a Microsoft chama de Importante e o NVD classifica como Alta. O resumo do registro começa com esse 8.8, e a discrepância é uma diferença de categorização, não de fatos.

O que o registro não consegue transmitir é o quanto desta história é uma ausência. Há uma falha que entrega uma identidade de nuvem a quem quer que a peça no formato errado. Há uma correção, lançada antes do anúncio. Não há descobridor creditado, nenhuma ferramenta nomeada, nenhuma exploração confirmada e nenhuma maneira de um observador externo saber se alguma implantação hospedada chegou a executar uma versão vulnerável enquanto detinha uma identidade poderosa. O aviso é preciso sobre o que a falha faz e silencioso sobre quase todo o resto, e esse silêncio é a coisa mais útil a se notar nele.