IngressNightmare
- Product
- Kubernetes ingress-nginx controller
- CVE
- CVE-2025-1974CVE-2025-1097CVE-2025-1098CVE-2025-24514CVE-2025-24513
- Disclosed
- 2025-03-24
- CVSS
- 9.8
- Auth
- pre-auth
- CISA KEV
- no
- Affected
- ingress-nginx before 1.11.5, and 1.12.0
- Fixed
- 1.11.5, 1.12.1
Summary
Wiz found that the ingress-nginx admission webhook, reachable without authentication from the pod network, could be fed a crafted Ingress object that injects NGINX configuration. Because the controller validates configs by running nginx -t with them, injected directives can load a shared library and run code. The controller's service account can read all cluster Secrets, so this often means full cluster takeover.
Root cause
The validating admission controller builds a temporary nginx.conf from Ingress annotations (auth-url, auth-tls-match-cn, mirror UID, etc.) without enough sanitization, and then runs nginx -t on it (CVE-2025-1097/1098/24514). Injecting an ssl_engine directive makes NGINX load an arbitrary shared object during the test (CVE-2025-1974). Wiz got the .so onto disk by having NGINX buffer a large request body to a temporary file and referencing it via /proc/<pid>/fd.
Impact
Anyone with network access to the admission webhook (any pod, or the internet if exposed) can run code in the controller and read every Secret in the cluster.
Detection
kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx and check image versions; alert on AdmissionReview requests from unexpected sources and suspicious annotations. Wiz and others published detection scripts; nuclei has a CVE-2025-1974 template.
Mitigation
Upgrade to 1.11.5 / 1.12.1+, and make sure the admission webhook is not reachable from untrusted networks (or disable it temporarily).