A set of critical vulnerabilities dubbed IngressNightmare has been uncovered in the Kubernetes ingress-nginx controller, allowing attackers to execute remote code, steal sensitive secrets, and compromise entire clusters. This article explores the technical mechanics of these flaws, detection strategies, and actionable steps to secure your environment.

The Significance of IngressNightmare

Disclosed in March 2025, the IngressNightmare vulnerabilities (CVE-2025-1974, CVE-2025-24514, CVE-2025-1097, CVE-2025-1098, and CVE-2025-24513) represent a severe threat to Kubernetes clusters using the ingress-nginx controller, a popular tool for managing external traffic to applications. These flaws enable unauthenticated attackers to achieve remote code execution (RCE) and escalate privileges to access all secrets in the cluster, potentially leading to full cluster takeover .

The most critical vulnerability, CVE-2025-1974 (CVSS 9.8), allows attackers to bypass Kubernetes API authentication and exploit the admission controller—a component responsible for validating configurations—to execute arbitrary commands. When chained with other flaws, attackers can inject malicious NGINX configurations, manipulate routing rules, and load malicious libraries to gain control over the controller pod. Researchers estimate 43% of cloud environments are at risk, with over 6,500 clusters publicly exposed, including those of Fortune 500 companies .

How the Exploit Works

The vulnerabilities stem from insecure handling of NGINX configuration parameters by the ingress-nginx admission controller. Here’s a breakdown:

  1. Admission Controller Exposure

    The admission controller, which validates Ingress objects, runs as a network-accessible service without authentication by default. Attackers can send crafted AdmissionReview requests to its endpoint, either from within the cluster (via compromised pods) or externally if misconfigured .

  2. Configuration Injection

    Vulnerabilities like CVE-2025-24514 (auth-url annotation injection) and CVE-2025-1098 (UID field manipulation) allow attackers to inject arbitrary NGINX directives into temporary configuration files. For example, an attacker could insert a directive like ssl_engine to load a malicious shared library from the filesystem .

  3. Remote Code Execution

    Using CVE-2025-1974, attackers exploit NGINX’s validation step (nginx -t) to execute injected code. By writing a malicious library to a temporary file (e.g., via large HTTP requests) and referencing it via /proc/self/fd, the attacker triggers the library’s execution during configuration testing, granting RCE on the controller pod .

  4. Privilege Escalation

    The ingress-nginx pod typically runs with a service account that has cluster-wide access to secrets. Attackers can exfiltrate credentials, pivot to other nodes, and hijack the entire cluster .

Is Your Cluster Affected?

To determine if your cluster is vulnerable:

  1. Check ingress-nginx Version Run: 
kubectl get pods -A --selector app.kubernetes.io/name=ingress-nginx -o custom-columns="IMAGES:.spec.containers[*].image"

Vulnerable versions include:

  • All versions before v1.11.0
  • v1.11.0–v1.11.4
  • v1.12.0 .
  1. Verify Admission Webhook Exposure Check if the ingress-nginx-admission webhook is accessible: 
kubectl get service ingress-nginx-controller-admission -n ingress-nginx

A ClusterIP type indicates internal exposure, while LoadBalancer or NodePort suggests public exposure .

  1. Inspect ValidatingWebhookConfiguration Ensure the admission controller is active: 
kubectl get ValidatingWebhookConfiguration ingress-nginx-admission

If present, the cluster is at risk unless patched .

Mitigation and Remediation

To secure your cluster:

  1. Immediate Patching

    Upgrade to ingress-nginx v1.11.5, v1.12.1, or later. Helm users should update to chart versions 4.11.5 or 4.12.1 .

  2. Disable Admission Controller (Temporary Fix)

    If patching isn’t feasible:

    • Helm users: Reinstall with controller.admissionWebhooks.enabled=false.
    • Manual installations: Delete the ingress-nginx-admission ValidatingWebhookConfiguration and remove --validating-webhook from the controller deployment .

  3. Restrict Network Access

    Use network policies to block external access to the admission controller. Only the Kubernetes API server should communicate with it .

  4. Monitor for Exploitation

    Tools like CrowdStrike Falcon and Wiz offer detection rules for suspicious activities, such as secret queries or anomalous library loads. For example, monitor commands like kubectl get secrets --all-namespaces from the ingress-nginx pod .

Twitter

Conclusion

The IngressNightmare vulnerabilities underscore the risks of misconfigured admission controllers and the critical need for robust input validation in Kubernetes components. Organizations must prioritize patching, enforce strict network policies, and adopt continuous monitoring to defend against such exploits. As Kubernetes continues to dominate cloud infrastructure, proactive security practices are no longer optional—they’re imperative.

For detailed remediation steps, refer to advisories from Kubernetes and Wiz .