A 2 de setembro de 2026, a CISA acrescentou pela primeira vez uma vulnerabilidade do Model Context Protocol ao seu catálogo de Known Exploited Vulnerabilities. Cinco dias depois surgiu uma segunda falha, mais grave, num servidor MCP diferente e muito usado. Nenhuma das duas é uma falha exótica específica do MCP — uma é um fallback de autenticação que falhou aberto, a outra é um bypass de privilégios de base de dados — e é exatamente esse o ponto: o MCP já está suficientemente implementado para que classes de bugs vulgares, em infraestrutura vulgar, sejam o que o derruba.

A primeira entrada MCP na lista de exploração da CISA

O CVE-2026-59822 é um bypass de autenticação no LiteLLM, o proxy open-source que uma boa parte das stacks de IA self-hosted usa para encaminhar chamadas a modelos e, para muitas equipas, aos seus servidores MCP. A CISA acrescentou-o ao catálogo Known Exploited Vulnerabilities a 2 de setembro, com prazo de correção a 16 de setembro para sistemas federais dos EUA — um prazo apertado que, ao abrigo da nova Binding Operational Directive 26-04 da agência, está reservado a falhas confirmadamente exploradas, alcançáveis pela internet pública e fáceis de automatizar. Tanto quanto conseguimos apurar, é a primeira implementação do Model Context Protocol a aparecer nessa lista.

Como funcionava o bypass

O endpoint MCP Streamable HTTP do LiteLLM verifica a chave de quem chama e tem um caminho de fallback para passthrough de OAuth2 a montante. Quando a validação da chave falhava, o fallback não recusava o pedido — substituía-o por um objeto UserAPIKeyAuth() vazio e deixava a chamada passar na mesma. Um pedido com nada mais do que um cabeçalho Authorization fabricado conseguia chegar a qualquer ferramenta MCP configurada, sem precisar de chave válida. A correção, lançada na versão 1.84.0, fecha esse fallback. O LiteLLM publicou o aviso ainda em junho; a entrada da CISA, dois meses depois, é que confirmou que a falha estava mesmo a ser usada contra implementações reais, e não apenas teoricamente explorável.

Uma segunda falha, mais grave, cinco dias depois

A 9 de setembro, a AWS Labs divulgou o CVE-2026-87911 no seu próprio postgres-mcp-server: uma falha crítica, CVSS 9,6, em que a validação SQL por trás do modo só de leitura do servidor podia ser contornada com uma instrução COPY ... TO PROGRAM construída propositadamente, permitindo executar comandos do sistema operativo na máquina da base de dados. Só afeta quem liga o servidor MCP com um papel que tem privilégios de superuser ou pg_execute_server_program — um atalho que muitas configurações rápidas tomam, por ser o caminho de menor resistência até alguém ler o aviso primeiro. Corrigido na versão 1.1.7.

Porque é que isto está a acontecer precisamente ao MCP

Nenhuma das duas falhas é um defeito da especificação MCP — um fallback de autenticação que falha aberto e uma escalada de privilégios via COPY TO PROGRAM são classes de bugs tão antigas como as tecnologias por baixo delas. O que mudou é que corrigi-las num prazo acelerado já vale a pena para a CISA e para a AWS, porque os servidores MCP estão exatamente onde está uma base de dados ou um gateway de API: acessíveis, a guardar credenciais, e agora comuns o suficiente para serem uma categoria-alvo em vez de uma curiosidade. O lote de 2 de setembro da CISA registou sete falhas exploradas; três, incluindo esta, foram reportadas como visando especificamente infraestrutura de IA.

O que fazer, na prática

  • Atualiza o LiteLLM para 1.84.0+ e o postgres-mcp-server para 1.1.7+, se usares algum dos dois — as correções já estão disponíveis.
  • Seja qual for o servidor MCP que toca numa base de dados, liga-o com um papel limitado às tabelas e operações de que precisa mesmo, nunca superuser. O modo só de leitura é uma rede de segurança, não um substituto das permissões ao nível da base de dados.
  • Testa o caminho de falha da tua autenticação, não só o de sucesso. Um validador que falha aberto é pior do que um que rebenta, e visto de fora são indistinguíveis até alguém encontrar a falha.
  • Se não conseguires corrigir de imediato, coloca o proxy MCP atrás de um gateway que consiga limitar ou controlar as rotas /mcp/ por conta própria.

Isto também reforça o que a nossa checklist de OAuth já dizia desde agosto: a especificação exige OAuth 2.1 em todos os servidores MCP, e muitos continuam a cortar esse canto. Estes dois CVE são o que cortar esse canto custa na prática — não uma hipótese, uma entrada datada no catálogo da CISA com um prazo de correção associado.