IngressNightmare: Critical RCE Vulnerabilities in Ingress NGINX Threaten Kubernetes Clusters

Introduction

In the world of Kubernetes orchestration, the Ingress NGINX Controller plays a central role as it serves as the gateway for traffic to applications within the cluster. However, recent discoveries by security researchers reveal that this essential component of Kubernetes poses significant security risks.

Researchers from Wiz Research have uncovered a series of Remote Code Execution (RCE) vulnerabilities known as IngressNightmare. The affected CVEs (CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, and CVE-2025-1974) have a CVSS score of 9.8, making them critical threats.

In this article, we explain the impact of the vulnerabilities, affected systems, and the necessary measures to secure Kubernetes clusters.

The Threat: Remote Code Execution (RCE) and Complete Cluster Takeover

The discovered vulnerabilities allow attackers to execute unauthenticated code on the Ingress NGINX Controller. This can grant them access to all secrets stored in the cluster and potentially gain complete control over the cluster.

Since Ingress NGINX is widely used in most Kubernetes environments, this vulnerability poses a significant risk.

Affected Systems:

• Approximately 43% of all cloud environments are vulnerable.
• More than 6,500 Kubernetes clusters worldwide are affected.
• Clusters that make the Ingress NGINX Admission Controller publicly accessible are particularly at risk.

How Does the Attack Work?

The vulnerability specifically affects the Admission Controller of Ingress NGINX. By default, it is network-wide accessible and does not sufficiently authenticate requests.

An attacker can perform the following steps to compromise the system:

1. Manipulated Ingress Object Request: A specially crafted request is sent to the Admission Controller.
2. Injection of Malicious Configuration: The controller validates and accepts the harmful configuration.
3. Code Execution: During validation, the malicious code is executed on the Ingress NGINX Controller.
4. Attack Expansion: Combining with SSRF attacks (Server-Side Request Forgery) allows further internal services to be targeted.

The danger of this vulnerability lies in the fact that attackers do not need specific permissions and can trigger a compromise with just a single malicious request.

What Measures Are Necessary?

The good news is that security patches are already available. Companies should act immediately to protect their Kubernetes clusters.

1. Update to the Latest Version

The current, secure version of the Ingress NGINX Controller is 1.12.1 or 1.11.5. All previous versions are considered insecure.

We have therefore updated all instances in our Managed Clusters to version 0.4.12 of the Helm Charts today to secure our systems.

2. Secure Admission Webhooks

If the Admission Controller is used, it should be ensured that it is not publicly accessible. This can be achieved through the following measures:

• Apply network policies to allow access to the Admission Controller only for the Kubernetes API server.
• Review RBAC rules to ensure that only authorized users have access.

3. Disable the Admission Controller (if an update is not possible)

If an immediate update cannot be performed, the Admission Controller should be disabled. This can be achieved through the following methods:

• Remove the webhook from the Kubernetes validation configuration.
• Disable the Admission Controller in Helm, if the installation was done via Helm.

4. Conduct Regular Security Checks

To protect against vulnerabilities in the long term, we recommend:

• Using security scanning tools like Trivy or kubebench.
• Enable auditing to detect suspicious Ingress object changes.
• Implement Zero-Trust principles to minimize unauthorized access.

Conclusion

The IngressNightmare vulnerabilities once again highlight the importance of regularly patching and reviewing security configurations of Kubernetes clusters. Since Ingress NGINX is used in almost every Kubernetes cluster, this vulnerability poses a serious threat.

Through our swift action and the update to version 0.4.12, we have ensured that our systems are protected from these attacks. Companies should urgently analyze their environment and, if affected, promptly implement updates and security measures.

The security of Kubernetes is a continuous process – with regular updates and a well-thought-out security strategy, companies can effectively protect their systems.