Rapid response · 2 MIN READ · MYLES SATTERFIELD · MAR 25, 2025 · TAGS: Threat hunting
TL;DR
- Five vulnerabilities (CVE-2025-1097, CVE-2025-1098, CVE-2025-1974, CVE-2025-24513, CVE-2025-24514) in the Ingress NGINX Controller for Kubernetes were publicly disclosed on March 24, 2025
- Threat actors can use these vulnerabilities to gain unauthorized access to secrets stored in the namespaces of the Kubernetes cluster
- We recommend patching immediately by updating your Ingress NGINX Controller for Kubernetes, or reducing risk by turning off the Validating Admission Controller feature
What happened?
On March 24, 2025, five vulnerabilities (CVE-2025-1097, CVE-2025-1098, CVE-2025-1974, CVE-2025-24513, CVE-2025-24514) in the Ingress NGINX controller for Kubernetes were publicly disclosed. It’s been named the IngressNightmare.
Threat actors exploiting these vulnerabilities (which can be used in connection to each other) could achieve remote code execution and gain unauthorized access to secrets stored in the namespaces of the Kubernetes cluster, leading to a complete cluster takeover. These vulnerabilities were identified and reported to Kubernetes through coordinated disclosure, affecting versions 1.12.0, 1.11.4, and below.
What should you do right now?
To determine if your clusters are using the affected NGINX Controller (ingress-nginx), run this command with cluster administrator permissions:
kubectl get pods –all-namespaces –selector app.kubernetes.io/name=ingress-nginx
These vulnerabilities were fixed in versions 1.12.1 and 1.11.5 of the Ingress NGINX Controller for Kubernetes, released on March 24, 2025. If patching isn’t possible, you can reduce your risk associated with CVE-2025-1974 by turning off the Validating Admission Controller feature of ingress-nginx.
- If ingress-nginx was installed using Helm:
- Reinstall and set Helm value controller.admissionWebhooks.enabled=false
- If ingress-nginx was installed manually:
- Delete the ValidatingWebhookconfiguration called ‘ingress-nginx-admission’
- Edit the ingress-nginx-controller Deployment or Daemonset by removing –validating-webhook from the controller container’s argument list
Why does it matter?
These five CVEs, when combined, don’t require credentials or administrative access for remote code execution or authorized access to secrets. Once a bad actor has access to the Pod network (via a public, cloud VPC, or corporate network), they can exploit the vulnerabilities to take control over the Kubernetes cluster. The potential for impact is incredibly high, but there have been no reported public proof-of-concept exploits for the related CVEs yet. However, these CVEs also lack associated indicators of compromise (IOC) at this time.
We suspect detecting this exploit might be possible based on what actions the bad actor takes after gaining access, or if there’s proper visibility into the Kubernetes cluster. We highly recommend taking immediate action to patch and mitigate associated risks.
What’s next?
We’ll update this post with big developments, but if you or your team have any additional questions regarding this vulnerability, or information regarding signs of exploitation, please reach out to us.
