Endpoint MCP do nginx-ui expõe vulnerabilidade crítica

O que aconteceu

Em 2026-03-15, os mantenedores do nginx-ui lançaram a versão 2.3.4. O lançamento corrigiu uma verificação de autenticação ausente em um único endpoint HTTP. Esse endpoint é /mcp_message, o caminho de entrega para a integração do Protocolo de Contexto do Modelo que o projeto adicionou para permitir que ferramentas de IA gerenciem configurações do nginx.

O aviso descreve a forma do problema em um parágrafo. "A integração do MCP (Protocolo de Contexto do Modelo) do nginx-ui expõe dois endpoints HTTP: /mcp e /mcp_message. Enquanto /mcp requer tanto a lista de permissões de IP quanto autenticação (AuthRequired() middleware), o endpoint /mcp_message aplica apenas a lista de permissões de IP — e a lista de permissões de IP padrão está vazia, o que o middleware trata como 'permitir tudo'."

A consequência, nas próprias palavras do aviso, é que "qualquer atacante de rede pode invocar todas as ferramentas do MCP sem autenticação, incluindo reiniciar o nginx, criar/modificar/excluir arquivos de configuração do nginx e acionar recargas automáticas de configuração — alcançando a tomada completa do serviço nginx."

O CVE é CVE-2026-33032, CVSS 9.8, classe: autenticação ausente. O descobridor é Yotam Perkal da Pluto Security, que publicou um relatório técnico junto com a correção e codificou o bug como "MCPwn".

O que é Confirmado vs Reportado vs Afirmado

Confirmado (fonte primária ou registro NVD):

• Os dois endpoints, a discrepância do middleware e o "lista de permissões vazia equivale a permitir tudo" padrão — todos diretamente do aviso dos mantenedores.
• CVSS 9.8. Classe de autenticação ausente.
• Correção lançada na versão 2.3.4 em 2026-03-15.
• Contornos: adicione middleware.AuthRequired() ao /mcp_message, ou altere o padrão da lista de permissões de IP para negar tudo.

Reportado (vários meios independentes secundários — The Hacker News, Security Affairs, Rapid7):

• Exploração na natureza desde março de 2026, de acordo com o relatório de 2026-04-13 da Recorded Future citado pela Rapid7.
• Encadeamento com CVE-2026-27944 (CVSS 9.8, um vazamento de informação não autenticada em /api/backup que expõe o node_secret necessário para abrir uma sessão em /mcp). Corrigido na 2.3.3.
• Aproximadamente 2.600 instâncias do nginx-ui acessíveis publicamente de acordo com a varredura da Pluto Security, ~2.689 de acordo com os dados do Shodan citados pelo The Hacker News, com a maioria localizada na China, EUA, Indonésia, Alemanha e Hong Kong. Essas são contagens de exposição, não contagens de comprometimento.
• O relatório de versões afetadas é inconsistente entre os avisos: o blog do descobridor lista ≤ 2.3.3 como vulnerável; o registro NVD lista ≤ 2.3.5. A Rapid7 recomenda atualizar para 2.3.6 para evitar a ambiguidade.

Afirmado (fonte única, explicitamente atribuída):

• Explicação estrutural de Perkal: "Quando você adiciona o MCP a um aplicativo existente, os endpoints do MCP herdam todas as capacidades do aplicativo, mas não necessariamente seus controles de segurança. O resultado é uma porta dos fundos que contorna todos os mecanismos de autenticação com os quais o aplicativo foi cuidadosamente construído." Esta é a citação dele, e a citamos como dele.

A cadeia, passo a passo

Apenas os saltos que as fontes realmente descrevem.

Passo 1 — Vazar o node_secret. O atacante emite uma solicitação não autenticada para /api/backup. Em versões do nginx-ui anteriores à 2.3.3, esse endpoint retorna informações suficientes para recuperar o valor de node_secret, o parâmetro de consulta que autentica a interface do MCP. Este passo é CVE-2026-27944, relatado pelo The Hacker News e Rapid7 como sendo encadeado em exploração ativa.

Passo 2 — Abrir a sessão do MCP. O atacante emite GET /mcp?node_secret=xxx para estabelecer uma sessão de eventos enviados pelo servidor e receber um sessionId. O aviso confirma que este endpoint é protegido tanto pela lista de permissões de IP quanto por AuthRequired(). O node_secret obtido no passo 1 satisfaz o lado da autenticação; a lista de permissões vazia padrão satisfaz o lado da rede.

Passo 3 — Invocar ferramentas em /mcp_message. O atacante emite POST /mcp_message?sessionId=xxx carregando o payload de invocação da ferramenta. Sem node_secret, sem JWT, sem cookies. Porque /mcp_message é apenas controlado pela mesma lista de permissões vazia, a solicitação é aceita. De acordo com o aviso, as ferramentas invocáveis incluem reiniciar o nginx, criar / modificar / excluir arquivos de configuração e acionar recargas automáticas.

Duas solicitações HTTP no total, se o atacante já possui o node_secret. Três, se eles também tiverem que encadear o vazamento de backup.

A suposição quebrada

A intenção de design parece boa. Dois endpoints, ambos por trás de AuthRequired() em intenção, ambos por trás de uma lista de permissões de IP. Defesa em profundidade. O que foi enviado era diferente.

Duas suposições separadas falharam juntas.

A primeira suposição falhada é que cada endpoint privilegiado em uma família estaria conectado ao mesmo middleware de autenticação. /mcp estava. /mcp_message não estava. Uma linha de código separou "autenticado" de "não autenticado", e essa linha estava ausente para o endpoint que carregava as operações de escrita. A Security Affairs observa que a correção da 2.3.4 adicionou essa linha ausente e um teste de regressão para que o mesmo tipo de omissão não possa ocorrer silenciosamente novamente.

A segunda suposição falhada é que a lista de permissões de IP seria significativa em tempo de execução. O padrão da lista de permissões estava vazio. O middleware tratou o vazio como permitir tudo. Assim, o controle de rede que deveria estar abaixo do controle de autenticação estava em zero também. Duas defesas, ambas desativadas em seus padrões, no mesmo endpoint.

Nenhuma suposição é única para este projeto. Ambas descrevem a forma geral do que acontece quando o MCP — um protocolo cujo valor é que ferramentas de IA podem dirigir os internos do aplicativo — é adicionado a um aplicativo que já possui autenticação, mas cuja autenticação é conectada por convenção em vez de por um único ponto de aplicação.

Perkal afirma a versão estrutural disso diretamente: "os endpoints do MCP herdam todas as capacidades do aplicativo, mas não necessariamente seus controles de segurança." Trate isso como a afirmação dele, não nossa. Mas a classe de falha corresponde ao que o aviso diz que aconteceu aqui.

Por que a detecção se torna mais difícil

A superfície exposta é uma interface de gerenciamento que normalmente fica em uma rede interna ou administrativa. A exploração usa duas solicitações HTTP que parecem, na rede, como o próprio tráfego do MCP do produto. Não há assinatura de malware. Não há padrão de preenchimento de credenciais. Um defensor que observa os logs de autenticação vê uma sessão bem-sucedida. Um defensor que observa os logs de rede vê tráfego para as próprias portas do produto.

O único sinal de detecção confiável é aquele que o próprio aplicativo teria que produzir: "esta invocação de /mcp_message foi atendida sem uma identidade verificada." Em uma versão vulnerável, esse sinal não existe, porque o endpoint não verifica a identidade. A detecção deve mudar para o exterior — para saber se o endpoint /mcp_message é acessível a partir da rede e se os eventos de alteração de configuração que ele produz são consistentes com a trilha de gerenciamento de mudanças que seus operadores esperam.

O que verificar esta semana

Operacional, em ordem de prioridade.

1. Inventário das implantações do nginx-ui. Execute uma varredura interna para a porta 9000 e quaisquer nomes de host conhecidos do nginx-ui. A contagem da superfície pública derivada do Shodan é ~2.600; sua superfície interna é tipicamente maior.
2. Status do patch. Se alguma instância estiver na 2.3.3 ou anterior, a informação vazada de /api/backup (CVE-2026-27944) é utilizável para ha