Resumo da Vulnerabilidade
Acabam de ser descobertas 5 vulnerabilidades críticas para ingress-nginx, sendo a mais crítica delas a CVE-2025-1974, onde atacantes podem explorar falhas no processamento das configurações do Ingress NGINX Controller para executar código arbitrário remotamente.
Ao explorar o admission webhook – que, por padrão, não requer autenticação – é possível injetar diretivas arbitrárias na configuração do NGINX, permitindo desde a leitura de secrets ao comprometimento total do cluster Kubernetes e movimentação lateral na sua infraestrutura.
Vale destacar que, embora o uso de Dynamic Admission Control seja uma prática recomendada em ambientes Kubernetes, o webhook do projeto ingress-nginx não seguiu boas práticas de desenvolvimento seguro de APIs. A falha está no design específico dessa implementação, e não significa que a funcionalidade deva ser evitada em todas as extensões da API.
Nota: Segundo análise da Wiz, cerca de 43% dos ambientes em nuvem estão vulneráveis, expondo publicamente à internet controladores de admissão do Ingress-NGINX.
Visão Geral da Vulnerabilidade
Contexto
O Ingress NGINX Controller é amplamente utilizado para expor aplicações em clusters Kubernetes, servindo como ponte entre os Ingress objects e a configuração do NGINX. Em muitas implementações, o componente de admission webhook é deixado acessível sem restrição, o que amplia a superfície de ataque, já que qualquer Pod na rede pode enviar requisições maliciosas.
Mecanismo de Exploração
Injeção Maliciosa
O atacante envia uma requisição de AdmissionReview manipulada, explorando campos como anotações (por exemplo, nginx.ingress.kubernetes.io/auth-url ou nginx.ingress.kubernetes.io/auth-tls-match-cn) e até mesmo o UID do recurso. Essa requisição injetada permite que diretivas arbitrárias sejam adicionadas à configuração temporária do NGINX.Execução do Payload
Durante a validação da configuração pelo comando nginx -t, as diretivas injetadas são processadas, ocasionando a execução de código malicioso. Com acesso aos privilégios do pod – que inclui a leitura de todos os segredos do cluster – o invasor pode assumir o controle completo do ambiente Kubernetes.
Versões Afetadas e Cenários de Exploração
Verifique se seu ingress-nginx possui webhooks ativos
kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations | grep nginx
Versões Afetadas
Ingress NGINX Controller nas versões anteriores à 1.12.1 e 1.11.5 estão vulneráveis, pois nessas versões o problema ainda não foi corrigido.
Cenários de Exploração
Clusters Kubernetes com o Ingress NGINX exposto publicamente, onde o admission webhook é acessível sem autenticação.
Ambientes onde a rede interna dos pods não restringe a comunicação, permitindo que qualquer workload envie requisições maliciosas para o componente vulnerável.
Agravantes
Cenários com configurações inseguras que concedem ao Ingress NGINX privilégios elevados, possibilitando comprometimento total do cluster e ambientes adjacentes.
Mitigação e Recomendações
Atualização Imediata
Atualize o Ingress NGINX Controller para as versões 1.12.1 ou 1.11.5, onde a vulnerabilidade foi corrigida.
Revisão de Configurações
Garanta que o endpoint do admission webhook não esteja exposto externamente, restringindo seu acesso apenas ao Kubernetes API Server. Você pode realizar isto implementando uma NetworkPolicy com esta regra.
Outras Recomendações
Caso a atualização imediata não seja viável, desabilite temporariamente o componente do admission webhook.
Se o ingress-nginx foi instalado via Helm, reinstale-o com o parâmetro controller.admissionWebhooks.enabled=false.
Para instalações manuais, remova a ValidatingWebhookConfiguration denominada ingress-nginx-admission e ajuste os argumentos do container no Deployment ou DaemonSet do controlador, removendo a flag --validating-webhook.
Caso decida mitigar temporariamente a vulnerabilidade desligando o Admission Webhook, lembre-se de religá-lo quando o ingress-nginx for atualizado para a versão corrigida.
Considerações Finais
Esta vulnerabilidade evidencia a importância de restringir o acesso a componentes críticos dentro dos clusters Kubernetes. A exploração do admission webhook do Ingress NGINX, sem autenticação e com privilégios elevados, pode permitir a execução de código arbitrário e o comprometimento de dados sensíveis. Atualizações imediatas e a revisão das configurações de segurança são fundamentais para mitigar esses riscos e proteger o ambiente contra ataques que possam levar ao comprometimento total do cluster. Mantenha sempre as práticas de segurança atualizadas e revisite periodicamente as configurações para minimizar a exposição a novas ameaças.
Referências
https://kubernetes.io/blog/2025/03/24/ingress-nginx-cve-2025-1974/
https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities
Saiba mais
Entenda como a Getup vem atuando na redução de mais 90% das vulnerabilidades em imagens de conteiner: https://getup.io/lp/images