Four critical CVEs (CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, and CVE-2025-1974) were disclosed in March 2025, collectively dubbed IngressNightmare. If you’re running a Kubernetes cluster with Ingress-NGINX, this one demands your immediate attention—especially if you haven’t reviewed your admission controller exposure in a while.

These are unauthenticated Remote Code Execution (RCE) vulnerabilities with a CVSS score of 9.8. They can lead to total cluster compromise via the Ingress-NGINX admission controller, and a shocking 43% of clusters scanned by researchers were found to be vulnerable.

Are You Running Ingress-NGINX?

To find out if you’re using the affected controller, you can run the following command:

kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

Breakdown of the IngressNightmare Vulnerabilities

• CVE-2025-24513 (CVSS 4.8): A flaw in input validation that opens the door to directory traversal within the container. While not critical on its own, it can be chained with other bugs to cause denial-of-service or limited secret leakage from the cluster.

• CVE-2025-24514 (CVSS 8.8): Misuse of the auth-url annotation allows attackers to smuggle malicious directives into NGINX’s configuration. This leads to remote code execution within the ingress-nginx controller and grants access to any secrets that controller can reach.

• CVE-2025-1097 (CVSS 8.8): A vulnerability tied to the auth-tls-match-cn annotation lets attackers inject crafted config into NGINX. It results in arbitrary code execution and secret exposure from within the controller’s security scope.

• CVE-2025-1098 (CVSS 8.8): Annotations like mirror-target and mirror-host can be exploited to sneak unauthorized config into NGINX. This can be leveraged to execute code and access sensitive data through the controller.

• CVE-2025-1974 (CVSS 9.8): The most severe of the bunch. An unauthenticated actor with network access can execute arbitrary code inside the ingress-nginx controller. No prior access or credentials are required.

What Ingress-Nginx Versions Are Safe?

This vulnerability has been addressed in the following versions:

•  1.12.1
•  1.11.5

If you’re running an earlier version, you’re exposed to at least one of the vulnerabilities.

How To Check Your Version?

The easiest way is to check the tag of your image:

kubectl describe deployment ingress-nginx-controller -n ingress-nginx | grep Image

If lower than the listed versions above, you should consider patching/upgrading ASAP.

Is Your Admission Controller Exposed?

The most dangerous misconfiguration is exposing the Ingress-NGINX admission controller to the public internet.

The admission controller is a validating webhook that processes ingress resource changes and builds NGINX configurations. By default, it listens on the network and does not require authentication which is an attacker’s dream.

How to Test for Exposure

Security researcher @nirohfeld released a Nuclei template to detect exposed admission controllers.

You can use it with Nuclei:

nuclei -u https://<your-ingress-nginx-domain> -t exposed-ingress-nginx-admission.yaml

Use the Nuclei template to quickly check for exposed admission controllers—one of the most critical misconfigurations in this exploit chain.

This will detect whether the validating admission webhook is accessible and exposed without authentication.

What to Do if You’re Vulnerable

The best thing is to update to the later version(s). If upgrading is not immediately feasible, consider these temporary mitigations:

• Restrict network access to the admission controller using NetworkPolicies.
• Disable the admission controller temporarily.

If installed via Helm, reinstall with:

--set controller.admissionWebhooks.enabled=false

If installed manually, delete the ingress-nginx-admission ValidatingWebhookConfiguration and remove the --validating-webhook argument from the controller’s deployment.

Re-enable the admission controller after patching—it’s still a useful safeguard when secured properly.

❗Be aware of this statement stated in the controller's changelog:

Unfortunately, to fix CVE-2025-1974 it was necessary to disable the validation of the generated NGINX configuration during the validation of Ingress resources.

The resulting NGINX configuration is still checked before the actual loading, so that there are no failures of the underlying NGINX. However, invalid Ingress resources can lead to the NGINX configuration no longer being able to be updated.

To reduce such situations as far as possible, we therefore recommend enabling annotation validation and disabling snippet annotations. In case of doubt, such states can be determined from the logs of the Ingress NGINX Controller. Watch out for a line of dashes followed by "Error:" telling you what went wrong.

What Makes This So Dangerous?

The crux of the exploit is that malicious users can inject ingress resources that manipulate the NGINX configuration generation. Since the controller tests the generated config using nginx -t, attackers can get it to load arbitrary shared libraries from disk—leading to full RCE.

If your pod has elevated privileges (which many do by default), the attacker can read every secret in the cluster.

Final Thoughts

IngressNightmare isn’t just another CVE batch. It’s a wake-up call to check your exposure surface, audit your cluster’s configuration, and take immediate action. Admission controllers are powerful, but they must not be exposed without authentication or proper network segmentation.

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

https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities