Falha no MCP Python SDK deixa um servidor malicioso redirecionar as credenciais OAuth: atualize para a 1.30.0 ou 2.2.0 e passe issuer=

O nosso veredito: se cria clientes MCP em Python com o MCP Python SDK oficial (que não consta do nosso diretório) e se liga por HTTP a servidores que não controla, aplique a correção hoje. Em dois dos quatro providers afetados, atualizar não muda nada: tem também de passar issuer=. Os responsáveis pela manutenção atribuem-lhe a classificação Alta, CVSS 7,5. Não foi comunicado nenhum ataque.

O que aconteceu

A 28 de setembro de 2026, os responsáveis pela manutenção do SDK publicaram o alerta de segurança GHSA-qx49-fqc8-xw99, intitulado «O cliente OAuth podia enviar credenciais para um servidor de autorização escolhido pelo servidor MCP». Segundo o alerta, o issuer dos metadados do servidor de autorização não era validado em todos os caminhos de descoberta, e as credenciais de cliente guardadas ou pré-configuradas não estavam associadas ao servidor de autorização a que pertencem. Um servidor MCP malicioso podia, por isso, apontar as credenciais de um cliente para um endpoint sob o seu controlo. O The Hacker News indica o que fica exposto: o segredo de cliente, o código de autorização e a chave de prova PKCE.

• Gravidade: CVSS 3.1 7,5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) para os providers máquina a máquina, 6,5 para o provider interativo, que exige a aprovação do utilizador. Não foi atribuído nenhum CVE.
• Providers afetados: OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider e o RFC7523OAuthClientProvider da série 1.x, já descontinuado.
• Versões afetadas: mcp 1.9.1 a 1.29.1, e 2.0.0 a 2.1.1.
• Corrigido em: mcp 1.30.0 e 2.2.0.
• Não afetados: servidores MCP criados com o SDK, clientes stdio e clientes que anexam os seus próprios tokens ou cabeçalhos.
• Exploração: nem o alerta nem a Cycode comunicam quaisquer ataques, segundo o The Hacker News.

Porque é que isto importa

A correção foi publicada a 7 de setembro de 2026, três semanas antes do alerta, segundo o The Hacker News. Uma atualização de rotina pode já a ter trazido, o que cria uma falsa confiança: só o protegia no provider interativo.

ClientCredentialsOAuthProvider e PrivateKeyJWTOAuthProvider são os providers máquina a máquina e guardam segredos de cliente e chaves privadas de longa duração. Nestes dois, o código corrigido só associa as credenciais se passar o argumento issuer= com o servidor de autorização a que pertencem. Se o omitir, recebe um aviso de descontinuação e nenhuma proteção. Clientes sem supervisão, com segredos de longa duração, protegidos apenas por um aviso que ninguém lê: é isto que justifica uma correção fora de calendário.

O que muda para si

1. Atualize mcp para a 1.30.0 (1.x) ou a 2.2.0 (2.x).
2. Nos ClientCredentialsOAuthProvider e PrivateKeyJWTOAuthProvider, passe issuer= explicitamente, por exemplo issuer="https://auth.example.com". Passa a ser obrigatório na 3.0.
3. Se usa RFC7523OAuthClientProvider, migre para outro provider: não tem a opção issuer=.
4. Limpe uma vez os registos OAuth guardados, para que os clientes voltem a registar-se com associação ao emissor.
5. Se um cliente puder ter chegado a um servidor MCP não fidedigno, rode os segredos de cliente no servidor de autorização e revogue os respetivos tokens.

Nenhuma ferramenta do nosso diretório é o próprio SDK. Se executa um agente ou gateway em Python que fala MCP por HTTP, verifique que versão do SDK fixa.

Perguntas frequentes

Estou afetado se só criar servidores MCP? Não. O alerta indica que os servidores MCP criados com o SDK não são afetados, tal como os clientes stdio.

Já atualizei em setembro. Estou seguro? Apenas no OAuthClientProvider interativo. Nos dois providers máquina a máquina continua exposto até passar issuer=.

Existe um CVE para acompanhar? Não. Acompanhe-o como GHSA-qx49-fqc8-xw99.