### Resumo Nas versões afetadas, o servidor HTTP SSE e Streamable transporta os pedidos entrantes para uma sessão existente com base apenas no identificador da sessão, sem verificar que o pedido foi autenticado como o mesmo principal que criou a sessão. Qualquer pessoa que tenha aprendido ou adivinhou um ID de sessão pode enviar mensagens do JSON- RPC nessa sessão, independentemente do portador que tenha carregado o pedido. ### Sou afetado? Só se o servidor de aplicativos de um desenvolvedor usar um transporte HTTP (SSE, ou HTTP Streamable em modo magistral) **e** autenticar pedidos. Os servidores no stdio, apátrida HTTP Streamable ou sem autenticação configurada não são afetados.

### Detalhes Ambos os transportes procuram a sessão alvo por seu identificador sozinho — o parâmetro de consulta `session_id` para SSE (`mcp.server.sse.SseServerTransport`) e o cabeçalho `Mcp-Session-Id` para HTTP Streamable (`mcp.server.streamable_http_manager.StreamableHTTPSessionManager`). Uma vez que a consulta foi bem- sucedida, o pedido foi tratado naquela sessão sem comparar o seu contexto de autenticação com as credenciais apresentadas quando a sessão foi criada, para que um pedido autenticado como um cliente OAuth diferente pudesse injetar mensagens na sessão. No transporte SSE a resposta é entregue ao fluxo de eventos do cliente original; no transporte HTTP Streamável ele é devolvido no pedido de injeção, para que o cliente de injeção também possa ler o resultado. O transporte SSE foi afetado desde a primeira versão; o transporte HTTP Streamável desde a versão 1.8.0. ### Os servidores de impacto usando qualquer transporte HTTP junto com a autenticação incorporada do SDK são afetados: o isolamento por cliente que a autenticação fornece pode ser evitado para qualquer sessão cujo ID é conhecido. Os IDs de sessão são gerados aleatoriamente UUIDs, portanto a exploração requer a obtenção de um fora da banda (logs, observação de rede). Os servidores que não habilitam a autenticação por tokens de portador não têm isolamento por cliente para contornar e não são abordados por este aviso, e as implantações HTTP Streamable apátridas não mantêm sessões e não são afetadas.

### Atualizar a Mitigação para a versão 1.27.2 ou posterior, que registra o principal autenticado que criou cada sessão — o ID do cliente OAuth juntamente com o emitente do token e o sujeito quando o verificador do token os fornece — e responde a pedidos apresentando um principal diferente com o mesmo 404 resposta como para uma sessão desconhecida. As implantações onde muitos usuários finais compartilham um único cliente OAuth (clientes MCP hospedados, gateways) devem garantir que o verificador token popula `AccessToken.sujeito ' (por exemplo, a partir do pedido de `sub` do token) para que as sessões sejam isoladas por usuário em vez de por cliente. As implantações usando uma infraestrutura de autenticação personalizada que não seja a `BearerAuthBackend` incorporada devem impor uma verificação equivalente.

Registro de aconselhamento: GHSA- jpw 9 - pfvf- 9 f 58. Identificadores relacionados: CVE- 2026 - 52869. Tempo: GitHub Advisory Database publicou este registro em 2026 - 07 - 16 T 19: 58: 53.000 Z e lista a sua última modificação como 2026 - 07 - 16 T 19: 58: 53.000 Z.

Severidade: ALTAMENTE. Dados de pontuação publicados: CVSS_V 3: CVSS: 3.1 /AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L. Informações sobre software e versão afetadas: pacote PyPI mcp — ECOSISTEM: introduzido 0, corrigido 1.27.2.

Classificação e evidência: identificadores de fraqueza CWE- 639. O registro contém 8 suporte de referências nestes tipos: WEB, AVISO, EMBALAGAMENTO.