MCP tomou dois advisories em uma semana e nenhum é bug de código

Poucos dias depois de eu escrever aqui sobre a integração de LLMs via MCP num MES on-premise, saíram duas falhas de segurança em MCP, com três dias de diferença. Fui ler os dois advisories inteiros, e o que mais me chamou atenção não foi a gravidade: foi que nenhuma das duas é bug de código.

28/09: o SDK Python oficial entrega as credenciais pro servidor errado

O advisory é o GHSA-qx49-fqc8-xw99, CVSS 7.5 (High), sem CVE atribuído.

O problema: o cliente não validava o issuer do fluxo OAuth. Um servidor MCP malicioso (ou um legítimo que foi comprometido) podia manipular o metadata do issuer, ou simplesmente não fornecer nenhum, e com isso apontar o cliente pra um token endpoint da escolha dele. O resultado é a credencial sendo entregue a um authorization server do atacante, com as mesmas permissões que você concedeu à aplicação.

• Afetado: mcp >= 1.9.1 < 1.30.0 e >= 2.0.0a1 < 2.2.0
• Corrigido em: 1.30.0 e 2.2.0

E atenção, porque atualizar não é o fim: o advisory diz explicitamente que para providers não interativos você precisa passar issuer= pra amarrar a credencial ao authorization server correto. Se houve exposição antes, rotacione credenciais e revogue tokens.

30/09: o next dev expõe seu projeto pra qualquer site aberto no navegador

Dois dias depois, o security release de setembro do Next.js trouxe sete correções. Uma delas é a CVE-2026-94486: o servidor de desenvolvimento do Next.js sobe um endpoint MCP que não verifica de qual site a requisição veio.

Ou seja: qualquer site malicioso que você visitar enquanto o next dev está rodando consegue ler o caminho do projeto em disco, trechos de código-fonte vindos de error reports, o inventário de rotas e os logs de desenvolvimento.

Só afeta next dev: produção não serve esse endpoint. O que não é consolo nenhum, porque next dev é exatamente o processo que fica rodando na mesma máquina em que você tem cinquenta abas abertas.

O que as duas têm em comum

Nenhuma é falha de parsing, de memória ou de implementação. As duas são a mesma classe de erro em lugares diferentes: o MCP assumiu boa-fé numa fronteira de confiança.

No SDK, a suposição era "o servidor vai me dizer a verdade sobre qual é o issuer do OAuth". No Next.js, era "quem fala com meu endpoint de dev é meu editor". Nos dois casos a correção não é um patch de lógica, é parar de confiar no outro lado.

Isso importa porque é estrutural. MCP é um protocolo cujo valor inteiro está em plugar coisas de terceiros no seu ambiente de desenvolvimento, que é o lugar com mais credencial por metro quadrado da sua vida profissional. Cada server que você adiciona é uma fronteira de confiança nova, e nenhuma delas vem com uma revisão de segurança anexada.

O que eu checaria hoje

No meu caso, o servidor MCP do MES é meu, roda on-premise, e o fluxo OAuth do SDK quase não me toca. Mas isso só inverte a pergunta, não a elimina:

1. Versão do SDK Python: >= 1.30.0 ou >= 2.2.0. É um comando.
2. issuer= explícito em qualquer provider não interativo.
3. Quantos servers MCP de terceiros estão configurados no seu Claude Code, Cursor ou editor, e qual deles você leu o código.
4. Se next dev roda na mesma máquina que seu navegador de uso geral (roda).
5. Que credencial exatamente o server MCP de terceiro consegue alcançar se ele quiser. Não "o que ele usa", o que ele alcança.

Meu veredito

Os dois patches são triviais de aplicar e você deve aplicar hoje. Mas se a leitura parar aí, a semana que vem traz o terceiro advisory da mesma família.

O item 3 e o item 5 daquela lista são o trabalho real, e são os únicos que nenhum npm update resolve. Eu venho plugando MCP em sistema industrial e escrevendo sobre isso, e até semana passada não tinha parado pra listar o que cada server de terceiro no meu editor consegue alcançar. Listei. Recomendo.