Um servidor MCP malicioso pode induzir um aplicativo criado com o SDK oficial de Python do MCP a revelar as credenciais OAuth usadas para se conectar a um serviço legítimo, segundo um alerta de segurança publicado pelos responsáveis pela manutenção do SDK.
Nas versões afetadas, o aplicativo enviava o segredo do cliente, o código de autorização e a chave de prova PKCE para um endpoint de token controlado pelo invasor. A correção está disponível nas versões 1.30.0 e 2.2.0.
O Protocolo de Contexto de Modelo (MCP) é um padrão aberto para conectar aplicativos de IA a ferramentas e dados externos. O pacote em questão é o SDK oficial de Python para criar servidores e clientes MCP.
Com as credenciais roubadas, o invasor pode solicitar um token de acesso válido ao serviço legítimo de autenticação. A Cycode, empresa de segurança que reportou a falha, demonstrou a troca completa em um teste. Segundo a empresa, o token resultante recebe as permissões concedidas ao aplicativo. Como o segredo do cliente tem longa duração, ele continua válido até ser alterado.
Nos dois fluxos sem interação humana, a falha recebeu pontuação 7,5. No fluxo interativo, que exige que alguém inicie a autenticação, a pontuação é 6,5. Até 29/09, a vulnerabilidade ainda não havia recebido um identificador CVE.
Como o servidor rouba as credenciais
Quando um cliente MCP precisa se autenticar, pergunta ao servidor ao qual está se conectando onde está o serviço de autenticação, chamado servidor de autorização. Nas versões afetadas, o SDK nem sempre verificava a resposta. Um servidor malicioso podia direcionar o cliente para um serviço de autenticação escolhido pelo invasor, seja indicando um servidor controlado por ele, seja fornecendo dados de autenticação que apontavam para o serviço legítimo do usuário, mas enviavam as credenciais para outro destino.
Assim, o cliente enviava o segredo, o código de autorização e a chave de prova PKCE ao invasor, em vez de enviá-los ao serviço legítimo. A chave de prova é um valor de uso único criado para impedir que um código de autorização roubado seja reutilizado. Ao entregá-la ao invasor, o cliente também anula essa proteção.
No fluxo interativo, a pessoa ainda precisa aprovar a autenticação. Segundo a Cycode, a página exibida é a página legítima de autenticação, por isso nada parece suspeito. Já os dois fluxos de comunicação entre máquinas não exigem que uma pessoa inicie a autenticação.
Quem está vulnerável
Um aplicativo está vulnerável se usar o SDK como cliente MCP por HTTP com um dos provedores OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider ou o obsoleto RFC7523OAuthClientProvider da linha 1.x. Também é necessário que ele possa se conectar a um servidor que não controla totalmente e mantenha credenciais para um serviço legítimo de autenticação.
Servidores MCP criados com o SDK, clientes locais que usam stdio e clientes que fornecem seus próprios tokens não são afetados.
| Linha | Versões afetadas | Correção disponível em |
|---|---|---|
| 1.x | 1.9.1 a 1.29.1 | 1.30.0 |
| 2.x | 2.0.0 a 2.1.1 | 2.2.0 |
O que fazer
Atualize para a versão 1.30.0 na linha 1.x ou para a 2.2.0 na linha 2.x. Nas versões corrigidas, o cliente determina qual serviço de autenticação espera encontrar antes de buscar os dados de acesso e rejeita informações que indiquem outro serviço.
Para dois dos provedores, porém, a atualização não basta. Se você usa ClientCredentialsOAuthProvider ou PrivateKeyJWTOAuthProvider, o alerta informa que “a atualização não muda nada até que você também passe `issuer=` para indicar o serviço de autenticação ao qual essas credenciais pertencem”. Sem esse parâmetro, os provedores continuam seguindo o endereço indicado pelo servidor MCP.
Na versão 1.30.0, o aviso sobre esse requisito é uma notificação padrão de descontinuação. Como o Python oculta esse tipo de aviso por padrão, é fácil não percebê-lo. O provedor obsoleto RFC7523OAuthClientProvider não oferece a opção `issuer=`, portanto é necessário migrar para um dos outros dois provedores.
Depois de atualizar, exclua uma única vez os registros de clientes OAuth armazenados, pois os registros antigos não estão associados a um serviço de autenticação. Se um cliente já puder ter se conectado a um servidor não confiável, troque o segredo do cliente e revogue os tokens no serviço de autenticação. Nas versões antigas, a única medida preventiva é conectar-se apenas a servidores MCP confiáveis.
Divulgação
As verificações de emissor foram incluídas nas notas de lançamento das versões 1.30.0 e 2.2.0, publicadas em 07/09, na seção de mudanças de comportamento, e não como uma correção de segurança. O alerta foi divulgado em 28/09, no mesmo dia em que a Cycode publicou sua análise. O documento credita oito pessoas que reportaram o problema, incluindo um pesquisador da Cycode.
Nem o alerta nem os relatos da Cycode apontam ataques que tenham explorado a falha, e nenhum caso foi divulgado por outras fontes.
Publicidade
Nossa audiência é formada por analistas, pentesters, decisores e entusiastas que consomem nossas notícias todo dia pelo Site, Newsletter e Instagram. Fale com quem realmente importa para o seu negócio. Anuncie aqui. Saiba mais...