Falha no nginx-ui permite tomada do serviço Nginx sem autenticação

CVE-2026-33032 expõe o endpoint /mcp_message a chamadas sem autenticação quando a lista de IPs está vazia, permitindo alterar configurações, recarregar o Nginx e assumir o controle do serviço em instalações vulneráveis.

Componentenginx-ui, ferramenta web de administração do Nginx, especificamente a integração MCP e os endpoints /mcp e /mcp_message.
Vetorrequisições HTTP especialmente construídas contra /mcp_message; o endpoint aplica apenas lista de IPs e, com a lista padrão vazia, o middleware interpreta a condição como permissão para todos.
Impactoinvasor de rede pode invocar ferramentas MCP sem autenticação, criar, alterar ou apagar arquivos de configuração do Nginx, reiniciar ou recarregar o serviço e, em cenário condicionado, interceptar tráfego ou coletar credenciais administrativas.
Prioridadeatualizar o nginx-ui para a versão 2.3.4, publicada em 15 de março de 2026, ou desabilitar a funcionalidade MCP e restringir o acesso de rede até a correção.
VersõesCVE-2026-33032 foi corrigida no nginx-ui 2.3.4; o encadeamento descrito também envolve CVE-2026-27944 em versões anteriores a 2.3.3 para exposição de backup e extração de node_secret.
Artefatosendpoints /mcp, /mcp_message e /api/backup; parâmetro node_secret; middleware AuthRequired(); lista de IPs com comportamento padrão de permitir todos quando vazia.
Resumo técnico

CVE-2026-33032 é uma falha crítica de bypass de autenticação no nginx-ui, uma interface web de código aberto usada para administrar o Nginx. O problema está na integração MCP, que adiciona endpoints capazes de acionar operações administrativas com alcance direto sobre o serviço. O endpoint /mcp exige lista de IPs e autenticação, mas /mcp_message aplica apenas a verificação de IP. Como a lista padrão de IPs é vazia e o middleware trata esse estado como autorização ampla, um atacante que consiga alcançar a interface pela rede pode chamar ferramentas MCP sem cabeçalhos ou tokens de autenticação adicionais. A pontuação CVSS informada para a falha é 9.8, compatível com impacto crítico quando a interface fica exposta.

A consequência técnica central não é apenas acesso à interface: é controle sobre funções que podem reiniciar o Nginx, criar, modificar ou remover arquivos de configuração e disparar recarregamentos automáticos. Em um servidor que usa Nginx como proxy reverso, terminador TLS ou ponto de entrada de aplicações internas, a alteração indevida da configuração pode afetar roteamento, certificados, cabeçalhos, logs e fluxo de tráfego. A falha foi listada entre vulnerabilidades exploradas ativamente em março de 2026, mas não há detalhes públicos sobre as campanhas, infraestrutura, alvos ou volume de exploração. A ausência desses detalhes limita atribuição e criação de indicadores específicos, mas não reduz a prioridade operacional para instalações acessíveis pela internet.

Fluxo técnico

A integração MCP expõe dois caminhos HTTP com controles diferentes. O caminho /mcp deveria estabelecer a sessão com autenticação e lista de IPs, enquanto /mcp_message recebe mensagens para invocar ferramentas MCP associadas à aplicação. A falha nasce da assimetria entre os dois controles: uma etapa da interface é protegida por autenticação, mas o caminho usado para executar ações depende somente da permissão por IP. Quando a configuração padrão não define entradas na lista de IPs, o mecanismo não bloqueia a origem; ele considera qualquer endereço como autorizado. Esse detalhe transforma uma política aparentemente restritiva em uma superfície de execução sem autenticação efetiva, desde que o atacante tenha conectividade até o serviço nginx-ui.

O encadeamento descrito inclui uma segunda vulnerabilidade, CVE-2026-27944, presente em versões anteriores a 2.3.3. Nesse cenário, o endpoint /api/backup pode expor, sem autenticação, dados suficientes para recuperar backups e extrair informações sensíveis, incluindo credenciais de usuários, chaves privadas SSL, configurações do Nginx e o valor node_secret usado para autenticar a interface MCP. Com esse segredo, o atacante consegue obter uma sessão MCP e encaminhar mensagens a /mcp_message para acionar ferramentas sem passar novamente por autenticação. O fluxo público foi descrito como possível em poucas interações HTTP, mas a defesa deve tratar o detalhe relevante como cadeia de precondições: exposição de nginx-ui, versão vulnerável, integração MCP ativa, lista de IPs permissiva e, no encadeamento mais amplo, disponibilidade do backup sem autenticação.

Superfície afetada

A superfície principal são instâncias nginx-ui acessíveis por rede, sobretudo quando publicadas diretamente na internet. A pesquisa citada no contexto identificou cerca de 2.689 instâncias expostas, com maior concentração em China, Estados Unidos, Indonésia, Alemanha e Hong Kong. A exposição é mais sensível quando o nginx-ui administra servidores Nginx que processam tráfego de múltiplas aplicações, concentram terminação TLS ou controlam regras de proxy para ambientes internos. Mesmo sem evidência pública de um ator específico, a existência de exploração ativa torna a janela entre descoberta e correção operacionalmente curta. Ambientes que mantêm nginx-ui apenas em redes administrativas ainda precisam validar segmentação, porque a falha também pode ser acionada por um atacante com posição de rede suficiente dentro do mesmo perímetro.

  • Instâncias nginx-ui com integração MCP habilitada e endpoint /mcp_message alcançável por rede.
  • Configurações em que a lista de IPs do MCP permanece vazia e é interpretada como autorização para qualquer origem.
  • Versões anteriores a 2.3.3 quando o risco inclui exposição de backup por /api/backup e extração de node_secret.
  • Servidores Nginx administrados pela interface, incluindo arquivos de configuração, recarregamentos automáticos e material SSL armazenado no backup.
Hunting e telemetria

A investigação defensiva deve começar pela exposição do serviço e seguir para evidências de uso anômalo dos endpoints MCP. Em logs HTTP do nginx-ui, proxy reverso ou balanceador, procure acessos a /mcp_message vindos de origens que não pertencem à rede administrativa, especialmente quando não houver sessão web interativa correspondente. Também é importante correlacionar chamadas a /api/backup em versões anteriores a 2.3.3 com leituras subsequentes de /mcp e /mcp_message, pois essa sequência sugere tentativa de obter segredos e acionar ferramentas MCP. Não é necessário publicar payloads para detectar a atividade: o sinal útil está na ordem dos endpoints, na origem de rede, na ausência de autenticação normal e nas alterações resultantes no serviço.

No host, a telemetria deve cobrir mudanças em arquivos de configuração do Nginx, recarregamentos fora de janela, reinícios inesperados e alterações em certificados ou chaves associadas ao serviço. Em ambientes com controle de integridade, compare timestamps, proprietário e conteúdo de arquivos de configuração com a última mudança aprovada. Em proxy reverso, procure regras novas que desviem tráfego, alterem cabeçalhos, modifiquem upstreams ou criem caminhos incomuns. Se houver suspeita de acesso ao backup, trate credenciais de usuários, chaves SSL e o valor node_secret como potencialmente expostos, mesmo que não exista confirmação de uso posterior. A ausência de IoCs públicos específicos exige hunting comportamental, não dependência de hash, domínio ou IP malicioso.

  • Requisições a /mcp_message sem fluxo de autenticação esperado ou partindo de endereços externos à administração.
  • Acesso a /api/backup seguido de atividade em /mcp ou /mcp_message em versões vulneráveis ao encadeamento.
  • Alterações, criação ou remoção de arquivos de configuração do Nginx fora de change request aprovado.
  • Recarregamentos ou reinícios do Nginx sem acionamento por pipeline, operador autorizado ou janela de manutenção.
  • Mudanças em regras de proxy, upstreams, certificados, chaves privadas ou parâmetros que possam afetar inspeção e roteamento de tráfego.
Mitigação

A resposta prioritária é atualizar nginx-ui para a versão 2.3.4, que corrige CVE-2026-33032. Quando a atualização imediata não for possível, a funcionalidade MCP deve ser desabilitada ou isolada, e o endpoint /mcp_message deve receber autenticação obrigatória equivalente à aplicada em /mcp, com AuthRequired() no caminho sensível. Outra medida defensiva é alterar o comportamento da lista de IPs para negar por padrão quando vazia, eliminando a interpretação de lista vazia como permissão universal. Essas ações devem ser acompanhadas por restrição de rede: a interface de administração não deve ficar exposta publicamente, e o acesso deve ser limitado a redes administrativas, VPN ou bastion host com autenticação forte e logs centralizados.

Para ambientes que estiveram vulneráveis, a correção do binário ou contêiner não encerra a resposta. É necessário revisar logs, verificar integridade das configurações do Nginx, procurar recarregamentos não autorizados e avaliar se houve acesso a /api/backup. Caso o backup tenha sido acessível em versão anterior a 2.3.3, rotacione credenciais administrativas, substitua chaves privadas SSL potencialmente expostas e gere novo node_secret. Depois da contenção, valide que /mcp_message não responde a origens não autorizadas, confirme que a lista de IPs segue política de negar por padrão e mantenha alertas para qualquer chamada MCP fora de fluxo administrativo conhecido. A vulnerabilidade mostra que integrações MCP herdando capacidades administrativas precisam receber os mesmos controles de autenticação, autorização e segmentação aplicados à aplicação principal.

  • Atualizar nginx-ui para 2.3.4 e confirmar que a versão em execução corresponde ao pacote ou imagem implantada.
  • Restringir acesso ao nginx-ui por rede administrativa e remover publicação direta da interface na internet.
  • Exigir autenticação em /mcp_message e configurar a lista de IPs para negar por padrão quando vazia.
  • Desabilitar MCP temporariamente quando a organização não conseguir corrigir ou validar controles de acesso com rapidez.
  • Auditar /api/backup, configurações do Nginx, chaves SSL, credenciais de usuários e node_secret em ambientes que executaram versões vulneráveis.