Multiple Vulnerabilities disclosed in Kubernetes Ingress-Nginx

Summary

Cyble's Security Update Advisory provides a synopsis of the latest vulnerability patches released by various vendors. This advisory discusses multiple recent vulnerabilities disclosed in Kubernetes ingress-nginx. Based on naming standards followed by Common Vulnerabilities and Exposures (CVE) and severity standards as defined by the Common Vulnerability Scoring System (CVSS), vulnerabilities are classified as high, medium, and low vulnerabilities.

Wiz Research discovered CVE-2025-1097, CVE-2025-1098, CVE-2025-24514 and CVE-2025-1974, a series of unauthenticated Remote Code Execution vulnerabilities in Ingress NGINX Controller for Kubernetes dubbed #IngressNightmare. Exploitation of these vulnerabilities leads to unauthorized access to all secrets stored across all namespaces in the Kubernetes cluster by attackers, which can result in cluster takeover.

Vulnerability Information

Ingress NGINX deploys an admission controller within its pod, designed to validate incoming ingress objects before they are deployed. By default, admission controllers are accessible over the network without authentication, making them a highly appealing attack vector.

When the Ingress-NGINX admission controller processes an incoming ingress object, it constructs an NGINX configuration from it and then validates it using the NGINX binary. Our team found a vulnerability in this phase that allows injecting an arbitrary NGINX configuration remotely, by sending a malicious ingress object directly to the admission controller through the network.

During the configuration validation phase, the injected NGINX configuration causes the NGINX validator to execute code, allowing remote code execution (RCE) on the Ingress NGINX Controller’s pod. The admission controller’s elevated privileges and unrestricted network accessibility create a critical escalation path. Exploiting this flaw allows an attacker to execute arbitrary code and access all cluster secrets across namespaces, that could lead to complete cluster takeover.

To be clear, gaining initial access to a cluster's pod network is not as difficult as one might think - containerization on its own is not a strong security boundary, and many applications running on K8s are susceptible to container escape, as we have repeatedly demonstrated in our research of cloud and SaaS applications over the past few years. Additionally, these vulnerabilities pair very well with SSRF vulnerabilities, which are an arguably common occurrence in web applications.

Mitigation & Detection

First, determine if your clusters are using ingress-nginx. In most cases, you can check this by running kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx with (at least) cluster-scoped read-only permissions.

This vulnerability is fixed in Ingress NGINX Controller version 1.12.1 and 1.11.5. We strongly recommend that cluster admins:

• Update to the latest version of Ingress NGINX Controller.

• Ensure the admission webhook endpoint is not exposed externally.

  • You can use this Nuclei template to check for exposed Ingress-NGINX admission controllers.

If you can’t upgrade immediately, consider one of these mitigations:

• Enforce strict network policies so only the Kubernetes API Server can access the admission controller.

• Temporarily disable the admission controller component of Ingress-NGINX if you cannot upgrade right away.

  • If you have installed ingress-nginx using Helm, reinstall with controller.admissionWebhooks.enabled=false.

  • If you have installed ingress-nginx manually, delete the ValidatingWebhookConfiguration called ingress-nginx-admission and remove the --validating-webhook argument from the ingress-nginx-controller container’s Deployment or DaemonSet.

  • Remember to re-enable the Validating Admission Controller after you upgrade, because it provides important safeguards for your Ingress configurations.

If you can’t upgrade immediately, consider one of these mitigations:

• Enforce strict network policies so only the Kubernetes API Server can access the admission controller.

• Temporarily disable the admission controller component of Ingress-NGINX if you cannot upgrade right away.

  • If you have installed ingress-nginx using Helm, reinstall with controller.admissionWebhooks.enabled=false.

  • If you have installed ingress-nginx manually, delete the ValidatingWebhookConfiguration called ingress-nginx-admission and remove the --validating-webhook argument from the ingress-nginx-controller container’s Deployment or DaemonSet.

  • Remember to re-enable the Validating Admission Controller after you upgrade, because it provides important safeguards for your Ingress configurations.

Wiz customers can use the pre-built query and advisory in the Wiz Threat Center. Wiz also validates for exposed admission controllers using the Wiz Dynamic Scanner. Finally, the Wiz Runtime Sensor detects zero-day vulnerabilities like IngressNightmare, by continuously monitoring ingress traffic, capturing malicious admission review requests in real-time, and flagging anomalous library loads to prevent similar attacks.

CVE-2025-24513 is different in nature from the other vulnerabilities in the IngressNightmare chain, as it does not lead to RCE.

Vulnerability Details (CVE-2025-1098)

Improper Input Validation

CVE-2025-1098

CVSSv3.1

8.8

Severity

High

Vulnerable Versions

ingress-nginx: 11.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.11.0, 1.11.1, 1.11.2, 1.11.3, 1.11.4, 1.11, 1.12

Description

Improper Input Validation vulnerability was discovered in vulnerable ingress-nginx where the mirror-target and mirror-host Ingress annotations can be used to inject arbitrary configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller and disclosure of Secrets accessible to the controller. Note that in the default installation, the controller can access all Secrets cluster-wide.

Additional Information

Users can check whether ingress-nginx is installed on the cluster, you are not affected by running kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx. Suspicious data within the mirror-target or mirror-host annotations of an Ingress resource could indicate an attempt to exploit this vulnerability. Users are advised to use the Nuclei template to check for exposed Ingress-NGINX admission controllers.

Patch Link

Link

Vulnerability Details (CVE-2025-1974)

Improper Isolation or Compartmentalization

CVE-2025-1974

CVSSv3.1

9.8

Severity

Critical

Vulnerable Versions

ingress-nginx: 11.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.11.0, 1.11.1, 1.11.2, 1.11.3, 1.11.4, 1.11, 1.12

Description An Improper Isolation or Compartmentalization vulnerability was discovered in Kubernetes. Under certain conditions, an unauthenticated attacker with access to the pod network can archive arbitrary code execution in the context of the ingress-nginx controller, which can lead to the disclosure of Secrets accessible to the controller. Note that in the default installation, the controller can access all Secrets cluster-wide.

Patch Link
Link

Vulnerability Details (CVE-2025-24513)

Improper Input Validation

CVE-2025-24513

CVSSv3.1

8.8

Severity

High

Vulnerable Versions

ingress-nginx: 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.11.0, 1.11.1, 1.11.2, 1.11.3, 1.11.4, 1.11, 1.12

Description

Improper Input Validation vulnerability was discovered in vulnerable ingress-nginx where the auth url Ingress annotation could be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller and disclosure of Secrets accessible to the controller. Note that in the default installation, the controller can access all Secrets cluster-wide.

Additional Information

Users can check whether ingress-nginx is installed on a cluster; you are not affected by running kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx. This issue does not affect users if they have the enable-annotation-validation CLI argument enabled. (This option is enabled by default starting from ingress-nginx v1.12.0.) Suspicious data within the auth-url annotation of an Ingress resource could indicate an attempt to exploit this vulnerability.

Patch Link

Link

Vulnerability Details (CVE-2025-24514)

Improper Input Validation

CVE-2025-24514

CVSSv3.1

8.8

Severity

High

Vulnerable Versions

ingress-nginx: 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.11.0, 1.11.1, 1.11.2, 1.11.3, 1.11.4, 1.11, 1.12

Description

Improper Input Validation vulnerability was discovered in vulnerable ingress-nginx where the auth url Ingress annotation could be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller and disclosure of Secrets accessible to the controller. Note that in the default installation, the controller can access all Secrets cluster-wide.

Additional Information

Users can check whether ingress-nginx is installed on a cluster; you are not affected by running kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx. This issue does not affect users if they have the enable-annotation-validation CLI argument enabled. (This option is enabled by default starting from ingress-nginx v1.12.0.) Suspicious data within the auth-url annotation of an Ingress resource could indicate an attempt to exploit this vulnerability.

Patch Link

Link

Vulnerability Details (CVE-2025-24514)

Improper Input Validation

CVE-2025-1097

CVSSv3.1

8.8

Severity

High

Vulnerable Versions

ingress-nginx: 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.11.0, 1.11.1, 1.11.2, 1.11.3, 1.11.4, 1.11, 1.12

Description

An Improper Input Validation vulnerability was discovered in ingress-nginx, where the auth-tls match-cn Ingress annotation can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller and disclosure of Secrets accessible to the controller. Note that in the default installation, the controller can access all Secrets cluster-wide.

Additional Information

Suspicious data within the auth-url annotation of an Ingress resource could indicate an attempt to exploit this vulnerability.

Patch Link

Link

Conclusion

The Ingress NGINX Controller for Kubernetes, a widely used ingress controller, has been found to contain multiple vulnerabilities, collectively termed "IngressNightmare". These vulnerabilities allow attackers to inject malicious configurations via the admission controller. This leads to unauthorized access to all secrets across all namespaces within a Kubernetes cluster, potentially resulting in full cluster compromise. Given that a huge percentage of cloud environments utilize Ingress NGINX, the widespread exposure underscores the urgency of addressing these flaws. Patching to the latest versions (1.12.1 or 1.11.5) is imperative to mitigate these risks and maintain the security and integrity of Kubernetes deployments.

Recommendations

• Implement the latest patch released by the official vendor: Regularly update all software and hardware systems with the latest patches from official vendors to mitigate vulnerabilities and protect against exploits. Establish a routine schedule for patch application and ensure critical patches are applied immediately.

• Implement a robust patch management process: Develop a comprehensive patch management strategy that includes inventory management, patch assessment, testing, deployment, and verification. Automate the process where possible to ensure consistency and efficiency.

• Incident response and recovery plan: Create and maintain an incident response plan that outlines procedures for detecting, responding to, and recovering from security incidents. Regularly test and update the plan to ensure its effectiveness and alignment with current threats.

• Monitoring and logging malicious activities across the network: Implement comprehensive monitoring and logging solutions to detect and analyze suspicious activities. Use SIEM (Security Information and Event Management) systems to aggregate and correlate logs for real-time threat detection and response.

• To mitigate risks associated with End-of-Life (EOL) products: Organizations should proactively identify and assess their criticality and then plan for timely upgrades or replacements.