[CVE-2025-1974] - Critical vulnerability in ingress-nginx #IngressNightmare

Vulnerability Summary

5 critical vulnerabilities have just been discovered in ingress-nginx, the most critical of which is CVE-2025-1974, where attackers can exploit flaws in the processing of Ingress NGINX Controller configurations to execute arbitrary code remotely. 

By exploiting the admission webhook – which, by default, does not require authentication – it is possible to inject arbitrary directives into the NGINX configuration, allowing anything from reading secrets to a full compromise of the Kubernetes cluster and lateral movement within your infrastructure. 

It is worth noting that, although the use of Dynamic Admission Control is a recommended practice in Kubernetes environments, the ingress-nginx project's webhook did not follow secure API development best practices. The flaw lies in the specific design of this implementation, and does not mean that the functionality should be avoided in all API extensions.

Note: According to Wiz's analysis, about 43% of cloud environments are vulnerable, publicly exposing Ingress-NGINX admission controllers to the internet.

Vulnerability Overview

Context

The Ingress NGINX Controller is widely used to expose applications in Kubernetes clusters, serving as a bridge between Ingress objects and NGINX configuration. In many implementations, the admission webhook component is left accessible without restriction, which widens the attack surface, as any Pod on the network can send malicious requests.

Exploitation Mechanism

1. Malicious Injection
   The attacker sends a manipulated AdmissionReview request, exploiting fields such as annotations (for example, nginx.ingress.kubernetes.io/auth-url or nginx.ingress.kubernetes.io/auth-tls-match-cn) and even the resource's UID. This injected request allows arbitrary directives to be added to the temporary NGINX configuration.

   
   

2. Payload Execution
   During configuration validation via the nginx -t command, the injected directives are processed, resulting in the execution of malicious code. With access to the pod's privileges – which includes reading all cluster secrets – the attacker can take complete control of the Kubernetes environment.
   
   

Affected Versions and Exploitation Scenarios

1. Verify if your ingress-nginx has active webhooks

• kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations | grep nginx
  
  

2. Affected Versions

• Ingress NGINX Controller in versions prior to 1.12.1 and 1.11.5 are vulnerable, as the issue has not yet been resolved in these versions.
  
  

3. Exploitation Scenarios

• Kubernetes clusters with the Ingress NGINX publicly exposed, where the admission webhook is accessible without authentication.

• Environments where the internal network of the pods does not restrict communication, allowing any workload to send malicious requests to the vulnerable component.
  
  

4. Aggravating Factors

• Scenarios with insecure configurations that grant the Ingress NGINX elevated privileges, enabling complete compromise of the cluster and adjacent environments.

Mitigation and Recommendations

1. Immediate Update

• Update the Ingress NGINX Controller to versions 1.12.1 or 1.11.5, where the vulnerability has been patched.
  
  

2. Configuration Review

• Ensure that the admission webhook endpoint is not exposed externally, restricting its access only to the Kubernetes API Server. You can achieve this by implementing a NetworkPolicy with this rule.
  
  

3. Other Recommendations

• If an immediate update is not feasible, temporarily disable the admission webhook component.

• If ingress-nginx was installed via Helm, reinstall it with the parameter controller.admissionWebhooks.enabled=false.

• For manual installations, remove the ValidatingWebhookConfiguration named ingress-nginx-admission and adjust the container arguments in the controller's Deployment or DaemonSet, removing the --validating-webhook flag.

• If you decide to temporarily mitigate the vulnerability by turning off the Admission Webhook, remember to re-enable it when ingress-nginx is updated to the patched version.
  
  

Final Considerations

This vulnerability highlights the importance of restricting access to critical components within Kubernetes clusters. Exploiting the Ingress NGINX admission webhook, without authentication and with elevated privileges, can allow the execution of arbitrary code and the compromise of sensitive data. Immediate updates and reviewing security configurations are fundamental to mitigating these risks and protecting the environment from attacks that could lead to the complete compromise of the cluster. Always keep security practices up to date and periodically revisit configurations to minimize exposure to new threats.

References

https://kubernetes.io/blog/2025/03/24/ingress-nginx-cve-2025-1974/
https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities

Learn more

Understand how Getup has been working to reduce vulnerability in container images by over 90%: https://getup.io/lp/images