Actualizam SDK de Python MCP para 1.30.0/2.2.0 para corrigir vulnerabilidade de credenciais OAuth

Os mantenedores do SDK oficial de Python para o Model Context Protocol (MCP) corrigiram uma vulnerabilidade que permitia a um servidor MCP malicioso enganar um cliente e fazer com que entregar credenciais OAuth válidas usadas para iniciar sessão em um serviço real. Nas versões afetadas, o cliente enviava ao atacante seu client secret, o authorization code e a chave PKCE (proof key), elementos suficientes para o atacante solicitar um token de acesso com as permissões que a aplicação tinha recebido.

De forma técnica, o problema surge na fase em que um cliente MCP pede ao servidor com o qual se conecta a localização do seu serviço de autorização (authorization server). Nas versões vulneráveis, o SDK não comprobava de forma confiável que o URL ou o emitente (issuer) do servidor de autorização coincidisse com o qual o cliente esperava antes de seguir o intercâmbio OAuth. Um servidor malicioso poderia responder apontando o endpoint de token controlado pelo atacante — ou falsificar metadados que nomeiam o serviço legítimo enquanto dirigiam os pedidos a outro lado — e assim receber o segredo de cliente, o código de autorização e o valor PKCE. A entrega do valor PKCE elimina a proteção que impede de reutilizar um código de autorização interceptado.

Cycode, a assinatura que informou e demonstrou o problema, realizou um intercâmbio de testes e mostrou que o token resultante levava as mesmas permissões que os autorizados originalmente para a aplicação. O advisory do SDK coloca a gravidade em 7.5 para os fornecedores que operam sem presença humana (machine-to-machine) e em 6.5 para o fornecedor interativo, onde alguém ainda deve aprovar o início de sessão. As correcções aparecem nas versões 1. 30. 0(rama 1.x) e 2. 0(rama 2.x) do SDK; as mudanças foram incluídas em notas de versão publicadas em 7 de setembro e o aviso de segurança foi divulgado em 28 de setembro, no mesmo dia em que Cycode publicou sua análise.

Atos confirmados: O SDK oficial de Python para MCP enviou o client secret, authorization code e o PKCE proof key a um endpoint controlado por um servidor MCP malicioso em versões anteriores a 1.30.0/2.2.0; Cycode demonstrou o intercâmbio em laboratório; a correção está em 1.30.0 e 2.2.0; a advertência sobre o comportamento apareceu primeiro como uma mudança de comportamento nas notas de versão; não havia CVE atribuído a 29 de setembro; não foram reportados exploits no terreno segundo o advisory e o relatório de Cycode.

O que implementações e papéis são afetados: estão em risco os aplicativos que usam o SDK comoMCP clientsobre HTTP e que empregam um desses fornecedores OAuth integrados: OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider ou o fornecedor obsoleto RFC7523OAuthClientProvider da série 1.x. Para que exista a exposição, o cliente deve poder ligar- se a um servidor MCP que não controla totalmente (por exemplo, servidores de terceiros). As MCP não são afetadas por servers construídas com o SDK, clientes locais (stdio) ou clientes que adjuntem seus próprios tokens manualmente.

Consequências práticas: Com as credenciais roubadas, um atacante pode trocar por um token de acesso válido no serviço de autenticação legítimo e agir com as permissões concedidas à aplicação. O client secret costuma ser de longa duração, pelo que a exposição permanece efetiva até que se rote o segredo. Em cenários machine-to-machine isso pode permitir acessos automatizados sem necessidade de interação humana; no caso do fluxo interativo, a página de início de sessão aprovada pelo usuário pode ser genuína e não mostrar sinais visíveis de manipulação, pelo que a vítima não percebe nada anormais durante a autorização.

Passos concretos e imediatos que devem tomar os responsáveis: Primeiro, atualizar o SDK às versões corrigidas: 1.30.0 para o ramo 1.x ou 2.2.0 para a 2.x. Segundo, para usuários do ClientCredentialsOAuthProvider ou PrivateKeyJWTOAuthProvider, além de atualizar, devem fornecer explicitamente o parâmetro issuer= que vincule essas credenciais ao serviço de autorização a que pertencem; sem esse parâmetro as credenciais continuarão aceitando o endereço que o servidor MCP lhes indicar. O fornecedor obsoleto RFC7523OAuthClientProvider não admite issuer= e deve ser substituído por um dos outros dois. Terceiro, após a atualização, eliminar uma única vez qualquer registro de cliente OAuth armazenado localmente por versões antigas, porque esses registros não estavam unidos a um issuer e permaneceriam inseguros. Finalmente, se houver a possibilidade de um cliente já se ter conectado a um servidor não confiável, rodar imediatamente o client secret e revogar tokens e autorizações no serviço de identidade correspondente.

Como medidas adicionais de mitigação temporária: evite conectar clientes MCP a servidores que não controle ou não possa auditar; habilite controles de rede que limitem destinos de token endpoints aos serviços legítimos; registrar e revisar trocas OAuth e exceções de issuer em logs de auditoria para detectar atividade anómala. Consulte a documentação do fornecedor de identidade para procedimentos de rotação e revogação de clientes e tokens.

Limitações e áreas de incerteza: Não há indícios públicos de que a vulnerabilidade tenha sido explorada em ambientes de produção até à data dos relatórios; no entanto, a falta de relatórios não garante que não haja abuso não detectado. Também não havia sido atribuído um CVE a 29 de Setembro — isto poderia mudar se os mantenedores ou terceiros registram a falha na base de CVE mais adiante. A avaliação de impacto em sistemas concretos dependerá de como cada organização gestione segredos, registros de cliente e controle de servidores MCP externos.

Para entender melhor por que essa vulnerabilidade é especialmente perigosa convém repassar o modelo OAuth: o RFC 6749 de OAuth 2.0 e os mecanismos PKCE são concebidos para que um código de autorização não seja reutilizável por um terceiro. Se o cliente entrega voluntariamente a chave PKCE ao atacante, essa barreira fica anulada. Para informações técnicas e recomendações sobre a gestão de advertências em Python (por exemplo, a deprecação que pode ser ocultada por defeito na 1.30.0), consulte a documentação oficial de advertências de Python em Python docs.python.org. O relatório técnico e a demonstração da empresa que reportou o problema está disponível na web do Cycode: Cycode.

Em resumo: se o seu aplicativo usa o SDK oficial de MCP como cliente e confia em servidores MCP que não controla, atualize quanto antes, configure o issuer quando apropriado, revoque e rote credenciais se houver exposição potencial, e verifique seus registros e políticas de conexão a servidores externos. Estas ações concretas são as únicas que reduzem o risco de um servidor MCP malicioso tornar uma interação legítima num compromisso de credenciais OAuth.