CVE-2025-1974 — IngressNightmare (ingress-nginx)

Introdução

Este documento apresenta uma pesquisa sobre a vulnerabilidade CVE-2025-1974, que afeta o componente ingress-nginx (validating admission controller) para Kubernetes.
CVE-2025-1974 é uma vulnerabilidade crítica (CVSS 3.1 9.8), consistindo em Remote Code Execution (RCE) não autenticado no contexto do processo ingress-nginx. Ao executar o ataque, um invasor que tenha acesso à pod-network (ou uma forma de entregar um AdmissionReview ao validating webhook) pode conseguir executar código arbitrário no pod do controlador, o que potencialmente leva à exposição de Secrets e à tomada do cluster.

Ingress-nginx é um dos controladores Ingress mais comuns no Kubernetes (estimativas indicam uso em dezenas de por cento dos clusters), portanto o impacto prático da vulnerabilidade é muito alto. A descrição, a análise técnica e as recomendações oficiais de correções foram publicadas pela Kubernetes, por pesquisadores da Wiz e por vários blogs de fornecedores.

---

Objetivo do relatório

Analisar a CVE-2025-1974 passo a passo e preparar os materiais necessários para o write-up:

1. Coleta e estruturação de materiais. Reunir advisories oficiais, write-ups de pesquisa e análises de fornecedores; destacar os principais detalhes técnicos e direções de PoC.
2. Entender a essência da vulnerabilidade e seu impacto. Explicar a root cause, a cadeia de ataque e as possíveis consequências (RCE → disclosure of Secrets → cluster takeover).
3. Determinar os CPEs e as condições de configuração. Listar versões/pacotes e configurações de Kubernetes/ingress-nginx nas quais a vulnerabilidade é relevante.
4. Fornecer recomendações para testes seguros em laboratório e minimização de risco em verificações em massa.

---

⚠️ Aviso legal

Esta pesquisa é conduzida exclusivamente para fins educacionais e éticos e é voltada para ambientes de teste/controlados.
Sob nenhuma circunstância execute exploits/PoCs contra clusters de terceiros ou instâncias publicamente acessíveis sem autorização por escrito do proprietário. A publicação de um PoC totalmente funcional e "weaponized" em formato aberto aumenta fortemente o risco de abuso — na parte pública, é melhor apresentar um safe-PoC e a metodologia. (Advisories oficiais e fornecedores também enfatizam cautela na disseminação de exploits).

---

CPEs e condições de configuração

• cpe:2.3:a:kubernetes:ingress-nginx_controller:<version> — versões vulneráveis do ingress-nginx (as versões específicas estão indicadas nos advisories; atualize os valores na publicação final).
• Fornecedores/distribuições que incluem o controlador vulnerável:
  • Distribuições RKE2 / Rancher com ingress-nginx até as versões de patch indicadas.
  • Versões do Harvester que utilizam ingress-nginx vulnerável (o KB do fornecedor contém os builds afetados específicos).
  • Clusters personalizados onde o ingress-nginx foi instalado separadamente (Helm chart/manifest) — verificar as versões do chart/imagem.

Condições de configuração nas quais a vulnerabilidade é relevante:

1. Versão vulnerável do ingress-nginx (anterior ao release/patch indicado nos advisories). Números exatos de versão consulte no NVD e nos advisories dos fornecedores.
2. Validating admission webhook acessível fora da pod-network — se o webhook estiver acessível externamente (por exemplo, endpoint público, provedor que expôs o serviço por engano), o exploit pode ser executado remotamente. A Wiz e outros pesquisadores apontaram numerosos casos de exposição pública.
3. Ausência de NetworkPolicy / isolamento da pod-network: se o invasor puder enviar requisições de qualquer pod para a rede do cluster (pod comprometido), isso é suficiente para a exploração.
4. Ausência de validações/ACLs adicionais antes do admission controller: filtros adicionais/autenticação via ingress-proxy podem reduzir o risco.
5. Presença no contêiner ingress-nginx de uma service account com amplas permissões e acesso a Secrets — por padrão, o controlador frequentemente monta uma serviceAccount com amplas permissões; isso aumenta o impacto em caso de exploração bem-sucedida.

---

Detalhes da vulnerabilidade

Resumo breve.
A vulnerabilidade foi encontrada no componente Validating Admission Controller do controlador Ingress-NGINX e está relacionada à forma como esse componente gera e valida a configuração temporária do NGINX com base nos Ingress / AdmissionReview recebidos. Durante o processamento, o controlador gera o nginx.conf e executa a verificação de configuração (nginx -t). Devido à sanitização insuficiente dos campos de Ingress/AdmissionReview, o atacante pode inserir fragmentos especialmente preparados que entram na configuração gerada e, como resultado, levam à execução de comandos dentro do processo do controlador — ou seja, à execução remota de código (RCE) no pod do ingress-nginx.

Principais pontos técnicos

• Ponto de entrada. Objetos AdmissionReview/Ingress recebidos, aceitos pelo validating webhook do controlador, tornam-se dados de origem para a geração da configuração do NGINX (incluindo campos de anotações, configurações de backend, etc.).
• Mecanismo de exploração. Um Ingress malicioso ou um AdmissionReview direto pode injetar strings controladas em templates/fragmentos de configuração. Durante a verificação/carregamento desse nginx.conf, o processo de validação (nginx -t) e as operações subsequentes com o arquivo de configuração podem levar à execução de código arbitrário, gravação/execução de arquivos ou execução de comandos no contexto do controlador.
• Condições necessárias. Para exploração bem-sucedida, é necessário: versão vulnerável do ingress-nginx; capacidade de entregar um AdmissionReview ao validating webhook (acesso pela pod-network ou acesso de rede direto); ausência de medidas compensatórias — NetworkPolicy, restrições de RBAC ou autenticação adicional do webhook. Em alguns cenários, é possível contornar as permissões de Create/Update enviando um AdmissionReview crafted diretamente ao webhook.

Por que isso é perigoso — consequências da exploração

A exploração bem-sucedida permite execução de código no contêiner do ingress-nginx, o que geralmente possibilita:

• obter o token da serviceAccount do controlador e acessar a API do Kubernetes;
• ler Secrets e outras informações confidenciais nos namespaces acessíveis;
• criar/modificar recursos do cluster e expandir o acesso (escalonamento de privilégios, movimento lateral);
• em alguns casos — a tomada completa do cluster.

Observações comportamentais e de detecção

• Durante a operação normal do controlador, normalmente não há fluxo de requisições ao Admission Controller — o validating webhook atua como um componente interno, operando dentro dos limites do cluster. Durante a exploração, observa-se uma anomalia: no mapa de rede (por exemplo, Luntry), aparecem conexões de entrada para ingress-nginx-controller-admission e para o serviço ingress-nginx-controller a partir de origens não padronizadas (nos relatos — de contêineres como alpine), o que não deveria ocorrer na operação normal.
• A análise do mapa de rede do cluster fornece uma visão das interações entre microsserviços; ao selecionar o Deployment do ingress-nginx no namespace, é possível ver as conexões de entrada/saída. O aparecimento de conexões de entrada para o admission-endpoint no momento do ataque é um indicador claro de comprometimento.
• Para detectar tentativas de exploração, é útil monitorar: requisições POST ao validating webhook, criação de objetos Ingress atípicos, chamadas a nginx -t e reinicializações repentinas do controlador, bem como operações inesperadas de gravação de arquivos pelo processo do ingress-nginx.

Contexto: o que é o controlador Ingress NGINX e por que ele é importante

Ingress-NGINX é um dos controladores Ingress mais amplamente utilizados no Kubernetes (amplamente empregado para organizar o acesso externo a serviços). O controlador atua como um proxy reverso: recebe o tráfego externo e o encaminha aos Services/Pods correspondentes com base em um conjunto de regras de Ingress. O projeto Ingress-NGINX goza de grande popularidade e tem uma parcela significativa de instalações em clusters acessíveis pela internet.

Na documentação do Kubernetes, o Ingress-NGINX é citado como exemplo de referência de controlador Ingress. Estima-se que uma parcela significativa dos clusters abertos o utilize; algumas pesquisas indicam que cerca de 41% dos clusters publicamente acessíveis usam Ingress-NGINX. É justamente devido à ampla adoção e ao papel central no roteamento de tráfego que vulnerabilidades nesse componente têm alto impacto prático.

Por que o validating webhook se torna um vetor de ataque conveniente

• Por padrão, o validating webhook do controlador é acessível dentro do espaço de rede do Kubernetes e, muitas vezes, não exige autenticação adicional ao acessar seu endereço (por exemplo, validate.nginx.ingress.kubernetes.io). Isso torna fácil acessá-lo a partir de dentro do cluster.
• A combinação: ampla adoção do controlador + seu acesso de rede + permissões potencialmente amplas da service account = combinação crítica que proporciona um caminho eficaz para comprometimento.
• Na prática real, obter o "primeiro ponto de entrada" no cluster não é tão difícil: aplicações frequentemente contêm vulnerabilidades que levam ao comprometimento de um contêiner individual; a partir desse contêiner, o invasor pode acessar webhooks internos. Além disso, vulnerabilidades exploráveis como SSRF em aplicações web são frequentemente usadas para iniciar requisições para dentro da rede do cluster e acionar esses webhooks.

Redescrição da cadeia de exploit (de forma concisa)

1. O invasor obtém a capacidade de enviar requisições para a pod-network ou acessar diretamente o validating webhook.
2. Um Ingress / AdmissionReview especialmente crafted é criado, onde determinados campos contêm strings maliciosas que não passaram pela filtragem adequada.
3. O controlador gera o nginx.conf com base nesses dados de entrada e executa nginx -t / outras operações de validação.
4. Os fragmentos injetados levam à execução de comandos/scripts ou à gravação/execução de arquivos no contexto do processo do controlador.
5. Com a execução obtida, o invasor extrai o token da serviceAccount, acessa a API do Kubernetes e continua o movimento lateral e o escalonamento de privilégios no cluster.

Observações sobre compatibilidade com outras vulnerabilidades

Essas vulnerabilidades são especialmente perigosas quando combinadas com outros defeitos: pod comprometido (ou SSRF em aplicação pública) + validating webhook exposto oferece alta probabilidade de comprometimento total. Portanto, a análise de incidentes deve considerar a cadeia de dependências e os vetores potenciais, e não apenas a versão do ingress-nginx.

---