Kubernetes Ingress-NGINX admission controller, unauthenticated RCE (IngressNightmare)
A security issue in the Kubernetes ingress-nginx controller allows an unauthenticated attacker with access to the pod network to achieve arbitrary code execution in the context of the ingress-nginx controller under certain conditions. Because the admission controller accepts and processes attacker-supplied configuration via its admission webhook without proper authentication boundaries, a malicious AdmissionReview payload can inject NGINX configuration that is loaded by the controller. Successful exploitation can lead to disclosure of Secrets accessible to the controller, which in a default installation can read all Secrets cluster-wide.
Overview
CVE-2025-1974, the most severe member of the cluster of flaws dubbed IngressNightmare, is a critical unauthenticated remote code execution vulnerability in the Kubernetes ingress-nginx controller. An attacker who can reach the controller's admission webhook over the pod network, with no credentials and no user interaction, can execute arbitrary code in the controller's context. The Kubernetes CNA assigns a CVSS v3.1 base score of 9.8 (Critical); the NVD record carries no separate NVD-assigned primary score and reflects the CNA value.
The vulnerability was reported by researchers at Wiz and disclosed coordinately by the Kubernetes project on 24 March 2025. It chains with companion CVEs (CVE-2025-1097, CVE-2025-1098, and CVE-2025-24514) that govern how annotation and configuration input is injected; CVE-2025-1974 is the privilege-boundary failure that turns that injection into code execution. Because a default ingress-nginx install grants the controller cluster-wide read access to Secrets, a single successful exploit can escalate to full cluster compromise.
Technical Details
The ingress-nginx controller runs a validating admission webhook that the Kubernetes API server calls whenever an Ingress object is created or updated. The webhook receives an AdmissionReview object, renders a candidate NGINX configuration from it, and runs nginx -t to validate that configuration before accepting the resource. The design assumption is that only the API server calls this endpoint and that the rendered configuration is therefore trustworthy.
The flaw, classified as CWE-653 (Improper Separation of Privileges), is that the admission webhook endpoint is reachable directly over the pod network and does not adequately authenticate that the caller is the API server. An attacker who can send HTTP to the webhook port can submit a crafted AdmissionReview whose contents cause the controller to write attacker-controlled directives into the NGINX configuration that is handed to nginx -t. By abusing NGINX configuration features (for example loading a shared object via a directive) and combining the directive injection from the companion annotation CVEs, the attacker gets the validation step to load and execute their payload inside the controller pod. From there the controller's service account token can be used to read Secrets across the cluster.
Affected versions are all ingress-nginx releases before v1.11.0, the v1.11.0 through v1.11.4 range, and v1.12.0. The pre-conditions are essentially default: a network-reachable admission controller, which is the standard deployment topology inside a cluster.
Impact
- Unauthenticated remote code execution inside the ingress-nginx controller pod from anywhere on the pod network.
- Disclosure of every Secret the controller can read; in a default install this is all Secrets cluster-wide, including service-account tokens and TLS keys.
- Effective full cluster takeover by pivoting from leaked credentials to the Kubernetes API.
- Complete loss of confidentiality, integrity, and availability (CIA all High) with no authentication and no user interaction.
- High blast radius because a single ingress-nginx deployment commonly fronts many namespaces and applications.
Mitigation
- Upgrade the ingress-nginx controller to a fixed release: v1.12.1 or later, or v1.11.5 or later for the 1.11.x line.
- If you cannot patch immediately, disable the validating admission controller component of ingress-nginx (remove the
ValidatingWebhookConfigurationand disable the admission webhook in the controller), then re-enable it after upgrading. - Enforce strict network policy so that only the Kubernetes API server can reach the admission webhook port on the controller pods, blocking arbitrary pod-network access.
- Scope down the controller's RBAC so its service account cannot read Secrets cluster-wide; restrict Secret access to only the namespaces it must serve.
- After patching, rotate any Secrets and service-account tokens that the controller could have accessed, in case of prior compromise.
- Audit for unauthorized
ValidatingWebhookConfiguration,Ingress, or controller-pod changes that could indicate exploitation.
Detection
The primary signal is direct traffic to the admission webhook that does not originate from the API server. The webhook listens on the controller pod (commonly port 8443) and should only ever be contacted by the kube-apiserver. Use network-flow logs, CNI flow logs (Cilium Hubble, Calico, or equivalent), or a service-mesh access log to enumerate every source that has connected to the controller's admission port; any pod or address other than the API server endpoints is a high-priority lead. A network policy that denies all but the API server, deployed in alert-only mode first, will surface offenders quickly.
Inspect ingress-nginx controller logs for admission-review processing of Ingress objects whose annotations or configuration snippets contain NGINX directives that load modules, set ssl_engine, reference unexpected file paths, or otherwise embed configuration the application teams did not author. Correlate these with the result of the internal nginx -t validation runs; an exploit deliberately uses the validation step as its execution primitive, so anomalies around config-test invocations are meaningful. Because the controller pod is the execution target, monitor it with runtime security tooling (Falco, Tetragon, or your EDR) for unexpected child processes, outbound connections, or file writes inside the controller container; the controller normally spawns only NGINX worker processes, so a shell, an interpreter, or a network beacon is a clear post-exploitation indicator.
From the Kubernetes audit log, hunt for two things. First, unusual creation or modification of Ingress resources, especially from service accounts or users that do not normally manage ingress, and especially objects that are created and quickly deleted. Second, any anomalous use of the ingress-nginx service-account token to enumerate or read Secrets, particularly across namespaces the controller does not serve; a sudden list/get of Secrets cluster-wide from that identity strongly suggests the token was stolen. Cross-reference Secret access spikes with the network and runtime findings above to build a timeline. Finally, confirm your exposure window by checking the deployed controller version against the affected ranges, and retain audit and flow logs back to late March 2025, since proof-of-concept code circulated publicly shortly after disclosure.