CVE-2025-1974 — IngressNightmare (ingress-nginx)

Introduction

This document presents a study of the vulnerability CVE-2025-1974 affecting the ingress-nginx component (validating admission controller) for Kubernetes.
CVE-2025-1974 is a critical vulnerability (CVSS 3.1 9.8), an unauthenticated Remote Code Execution (RCE) in the context of the ingress-nginx process. When executing an attack, an attacker with access to the pod network (or a way to deliver an AdmissionReview to the validating webhook) can achieve arbitrary code execution in the controller pod, potentially leading to disclosure of Secrets and cluster takeover.

Ingress-nginx is one of the most common Ingress controllers in Kubernetes (estimates indicate usage in tens of percent of clusters), so the practical impact of the vulnerability is very high. Descriptions, technical analysis, and official fix recommendations were published by Kubernetes, Wiz researchers, and several vendor blogs.

---

Report Objective

Step-by-step analysis of CVE-2025-1974 and preparation of materials necessary for a write-up:

1. Collect and structure materials. Gather official advisories, research write-ups, and vendor analysis; highlight key technical details and PoC directions.
2. Understand the vulnerability essence and its impact. Explain the root cause, attack chain, and possible consequences (RCE → disclosure of Secrets → cluster takeover).
3. Determine CPE and configuration conditions. List the versions/packages and Kubernetes/ingress-nginx configurations for which the vulnerability is relevant.
4. Provide recommendations for safe testing in a lab and risk minimization during mass scanning.

---

⚠️ Disclaimer

This research is conducted exclusively for educational and ethical purposes and is intended for test/controlled environments.
Under no circumstances should exploits/PoCs be run against other people's clusters or publicly available instances without the owner's written permission. Publishing fully functional "weaponized" PoC openly greatly increases the risk of abuse—it is better to provide safe PoC and methodology in the public part. (Official advisories and vendors also emphasize caution when distributing exploits.)

---

CPE and Configuration Conditions

• cpe:2.3:a:kubernetes:ingress-nginx_controller:<version> — vulnerable ingress-nginx versions (specific versions are indicated in advisories; update values upon final publication).
• Vendors/distributions that include the vulnerable controller:
  • RKE2 / Rancher distributions with ingress-nginx up to the specified patch versions.
  • Harvester versions using a vulnerable ingress-nginx (vendor KB contains specific affected builds).
  • Custom clusters where ingress-nginx is installed separately (Helm chart/manifest) — check chart/image versions.

Configuration conditions under which the vulnerability is relevant:

1. Vulnerable ingress-nginx version (before the release/patch specified in advisories). See NVD and vendor advisories for exact version numbers.
2. Validating admission webhook accessible from outside the pod network — if the webhook is externally accessible (e.g., public endpoint, provider mistakenly exposed the service), the exploit can be performed remotely. Wiz and other researchers have pointed out numerous cases of public exposure.
3. Lack of NetworkPolicy / pod network isolation: if an attacker can send requests from any pod in the cluster network (compromised pod), this is sufficient for exploitation.
4. Lack of additional validation/ACL before the admission controller: additional filters/ingress-proxy authentication can reduce risk.
5. Presence of a service account with broad permissions and access to Secrets in the ingress-nginx container — by default, the controller often mounts a serviceAccount with broad rights; this increases the impact upon successful exploitation.

---

Vulnerability Details

Brief summary.
The vulnerability was discovered in the Validating Admission Controller component of the Ingress-NGINX controller and is related to how this component generates and checks a temporary NGINX configuration based on incoming Ingress / AdmissionReview objects. During processing, the controller generates nginx.conf and runs a configuration check (nginx -t). Due to insufficient sanitization of Ingress/AdmissionReview fields, an attacker can inject specially crafted fragments that end up in the generated config, ultimately leading to command execution within the controller process — i.e., remote code execution (RCE) in the ingress-nginx pod.

Key Technical Points

• Entry point. Incoming AdmissionReview/Ingress objects accepted by the controller's validating webhook become input data for generating the NGINX configuration (including annotation fields, backend settings, etc.).
• Exploitation mechanism. A crafted malicious Ingress or direct AdmissionReview can inject controlled strings into configuration templates/fragments. When such an nginx.conf is checked/loaded, the validation process (nginx -t) and subsequent operations with the configuration file can lead to arbitrary code execution, file write/execution, or command execution in the controller context.
• Required conditions. For successful exploitation: a vulnerable ingress-nginx version; ability to deliver an AdmissionReview to the validating webhook (access from the pod network or direct network access); absence of compensating measures — NetworkPolicy, RBAC restrictions, or additional webhook authentication. In some scenarios, Create/Update privileges can be bypassed by sending a crafted AdmissionReview directly to the webhook.

Why This Is Dangerous — Exploitation Consequences

Successful exploitation gives code execution in the ingress-nginx container, which typically allows:

• obtaining the controller's serviceAccount token and accessing the Kubernetes API;
• reading Secrets and other confidential information in accessible namespaces;
• creating/modifying cluster resources and expanding access (privilege escalation, lateral movement);
• in some cases — full cluster takeover.

Behavioral and Detection Observations

• Under normal controller operation, there is no flow of requests to the Admission Controller — the validating webhook serves as an internal component operating within the cluster. During exploitation, an anomaly is observed: incoming connections appear to ingress-nginx-controller-admission and the ingress-nginx-controller service from non-standard sources (in reports, from containers like alpine), which should not happen under normal conditions.
• Analyzing the cluster network map provides insight into interactions between microservices; selecting the ingress-nginx Deployment in the namespace shows incoming/outgoing connections. The appearance of incoming connections to the admission endpoint at the time of attack is a clear indicator of compromise.
• To detect exploitation attempts, it is useful to monitor: POST requests to the validating webhook, creation of atypical Ingress objects, calls to nginx -t and sudden controller restarts, as well as unexpected file write operations from the ingress-nginx process.

Context: What Is the NGINX Ingress Controller and Why Is It Important

Ingress-NGINX is one of the most widely used Ingress controllers in Kubernetes (commonly used to organize external access to services). The controller acts as a reverse proxy: it accepts external traffic and proxies it to the appropriate Service/Pod based on a set of Ingress rules. The Ingress-NGINX project is very popular and has a significant installation share in internet-accessible clusters.

Ingress-NGINX is mentioned in Kubernetes documentation as a reference example of an Ingress controller. Estimates indicate that a significant portion of exposed clusters use it; some studies suggest that around 41% of publicly accessible clusters use Ingress-NGINX. It is precisely because of its widespread use and central role in traffic routing that vulnerabilities in this component have high practical impact.

Why the Validating Webhook Becomes a Convenient Attack Vector

• By default, the controller's validating webhook is accessible within the Kubernetes network space and often does not require additional authentication when connecting to its address (e.g., validate.nginx.ingress.kubernetes.io). This makes it easy to reach from inside the cluster.
• The combination: wide controller deployment + network accessibility + potentially broad service account permissions = a critical combination that provides an effective path for compromise.
• In practice, gaining a "first foothold" in a cluster is not very difficult: applications often contain vulnerabilities leading to the compromise of a single container; from that container, the attacker can then reach internal webhooks. Additionally, exploitable vulnerabilities like SSRF in web applications are often used to initiate requests into the cluster network and leverage such webhooks.

Re-explanation of the Exploit Chain (Concise)

1. The attacker gains the ability to send requests to the pod network or directly access the validating webhook.
2. A specially crafted Ingress / AdmissionReview is created, where certain fields contain malicious strings that have not undergone proper filtering.
3. The controller generates nginx.conf based on this input and executes nginx -t / other validation operations.
4. Injected fragments lead to execution of commands/scripts or file write/launch in the controller process context.
5. Having gained execution, the attacker extracts the serviceAccount token, accesses the Kubernetes API, and continues lateral movement and escalation in the cluster.

Compatibility Notes with Other Vulnerabilities

Such vulnerabilities are especially dangerous when combined with other defects: a compromised pod (or SSRF in a public application) + an exposed validating webhook gives a high chance of full compromise. Therefore, incident analysis should consider the chain of dependencies and potential vectors, not just the ingress-nginx version.

---