Tirar lição dos incidentes que já aconteceram

Falha em servidor MCP já deixou credencial de nuvem, token de administrador e arquivo interno ao alcance de terceiros, em produtos de fornecedores grandes e pequenos. Só em agosto de 2026, o banco público de vulnerabilidades dos Estados Unidos registrou quatro casos novos. O caso mais relevante do ano passou por baixo da política de aprovação de fornecedor, porque não havia fornecedor no caminho.

Por que o comitê pede caso antes de aprovar controle

A diretora jurídica da rede de distribuição fez a pergunta na forma em que ela costuma aparecer: isso já aconteceu com empresa do nosso porte, e a nossa política atual teria impedido? A pergunta separa risco teórico de risco observado e força a resposta a nomear um controle específico.

O critério de seleção deste capítulo foi rígido. Entrou apenas caso com identificador atribuído, linha do tempo publicada pelo pesquisador ou medição com metodologia declarada. CVE (número de registro público de falha, como a placa de um carro) é o identificador mais comum. Ficaram de fora os números de fornecedor que circulam em apresentação comercial.

A lição que interessa a quem decide

Não houve instalação de pacote, contratação de fornecedor nem escolha errada de servidor. O vetor foi um arquivo de configuração dentro de um repositório que alguém do time clonou para trabalhar, no assistente de programação da Amazon. Nenhuma política de aprovação de fornecedor teria barrado.

Quem transformou leitura de repositório em comprometimento de infraestrutura foi uma sessão de nuvem de longa duração viva na máquina de quem programa. Daí decorre a mitigação que funciona: credencial de curta duração, escopo por projeto e política de frota que decide quais servidores podem carregar. Abrir um repositório passou a ser evento de segurança, e a frase precisa entrar na política antes de entrar no relatório de incidente.

O caso que virou requisito de protocolo

A CVE-2025-6514 atingiu o proxy mais usado para alcançar servidores remotos, com nota 9,6 de 10 na escala de severidade. Um servidor malicioso respondia ao fluxo de autorização com um endereço montado para provocar execução de comando no sistema operacional. As versões 0.0.5 a 0.1.15 foram afetadas, com correção na 0.1.16.

O desfecho vale como argumento em comitê. A revisão vigente da especificação, de 28/07/2026, manda o cliente rejeitar esquemas perigosos no endereço de autorização, como javascript: e file:. Uma falha em dependência popular virou requisito do padrão em cerca de um ano, prova de que fixar a revisão em contrato tem consequência material.

A cláusula que nasce do terceiro caso é a de prazo de correção com direito de rescisão, detalhada em "Testar e contratar antes de aprovar". Trazê-la aqui mostra a origem: ela deixa de ser formalidade jurídica quando existe um caso concreto em que a resposta do fornecedor a um relato de segurança foi a recusa.

O cliente também é superfície, e a resposta dele é critério de compra

Entre 06/04/2026 e 25/06/2026, o Claude Code, cliente de agente muito usado por times técnicos, publicou uma sequência de avisos de segurança. O mais grave, CVE-2026-35022, era injeção de comando na execução de helper de autenticação, com nota 9,3. Vieram junto elevação local de privilégio, falha na verificação de chave de servidor e escape de isolamento.

A avaliação que olha só para o servidor cobre metade do problema, porque o cliente roda na estação de quem trabalha, com as credenciais dessa pessoa. A pergunta de compra que decorre disso é objetiva: o fornecedor publica aviso com identificador e severidade, ou corrige em silêncio? Cinco avisos publicados em três meses deixam o fornecedor mais legível do que nenhum.

Agosto de 2026 trouxe quatro casos novos com registro público

No mesmo mês em que a campanha Deadbugz trocava metadados depois da terceira chamada, tratada em "Reconhecer os ataques próprios deste protocolo", o NVD (base oficial americana de vulnerabilidades, o cartório das falhas) publicou quatro CVEs em servidores MCP. Elas atingem ferramentas de banco de dados, de documentação interna, de anúncios e de apoio a programadores, usadas por áreas bem diferentes da empresa.

O padrão comum é o que o comitê precisa ouvir. Em nenhum dos quatro o ataque exigiu invadir a empresa. Bastou uma ferramenta legítima aceitar parâmetro sem conferência, ou devolver ao agente um texto que ninguém revisou, para credencial e arquivo saírem pela porta da frente.

Três medições acadêmicas completam o quadro

Uma varredura automatizada percorreu 39.884 repositórios de servidores e achou 106 falhas inéditas, todas confirmadas com prova de exploração, com 67 identificadores atribuídos. O número que importa é o custo: a confirmação foi automática, o que põe a descoberta de falha no patamar de rotina para quem ataca.

Outro estudo mediu autenticação em 7.973 servidores remotos ativos. Deles, 40,55% expõem ferramenta sem autenticação alguma, e cada um dos 119 servidores com autorização testável apresentou pelo menos uma falha, somando 325. A resposta de que o fornecedor usa OAuth deixou de bastar em avaliação.

Uma auditoria dinâmica submetida em 31/07/2026 testou 414 servidores de produção expostos na internet e encontrou 68 vulnerabilidades reportáveis, de injeção de SQL a falsificação de requisição contra metadados de nuvem. Entre os auditados, 91,8% não tinham autenticação OAuth. Outro dado ajuda o inventário: 41,6% dos servidores confirmados sumiram em três dias entre duas medições, sinal de publicação às pressas e sem revisão.

Marque para os próximos 30 dias um ensaio do roteiro de 24 horas com um servidor de teste, cronometre cada passo e registre em ata quais horários-limite estouraram. Na mesma semana, rode a busca pelas quatro CVEs de agosto na frota; a meta é zero servidor afetado em versão sem correção. O capítulo seguinte, "Separar o que o padrão faz do que vendem", mostra o que continua sendo obrigação da casa mesmo com tudo funcionando.