In a recent report on WIZ, security researchers disclosed a series of critical vulnerabilities in the Ingress NGINX Controller for Kubernetes. These vulnerabilities allow unauthenticated attackers to gain unauthorized access to sensitive data, execute remote code (RCE - Remote Code Execution), or take over affected Kubernetes clusters. Initial estimates suggest that about 43% of cloud environments and approximately 6,500 Kubernetes clusters are immediately impacted by the vulnerability, as information about the clusters is publicly available on the internet..

What is the Ingress NGINX Controller for Kubernetes?

An Ingress controller is a component in Kubernetes used to manage and direct HTTP and HTTPS traffic to services within a Kubernetes cluster. It acts as a reverse proxy, routing requests from outside to internal services based on rules configured in the Ingress resource. Essentially, the Ingress controller provides an easy and flexible way to handle external requests into the cluster without needing to open ports directly for each service.

The Ingress NGINX Controller is a type of Ingress controller for Kubernetes, using NGINX as a reverse proxy and load balancer to direct HTTP and HTTPS traffic to services within the Kubernetes cluster. It functions to route requests from outside (clients) to services inside Kubernetes through rules configured in the Ingress resource. Approximately 41% of Kubernetes clusters that communicate with the internet today use Ingress NGINX.

Figure 1: Simplified diagram of Ingress NGINX Controller - Source: WIZ Research

Vulnerability Information

1. Vulnerability ID: CVE-2025-24514

   • CVSS Score (3.1): 8.8

   • Description: The auth-url annotation in the Ingress configuration can be exploited by an attacker to inject arbitrary configuration into NGINX. This can lead to malicious code execution within the ingress-nginx controller's privileges and expose sensitive data accessible by the controller.

2. Vulnerability ID: CVE-2025-1097

• CVSS Score (3.1): 8.8

• Description: The auth-tls-match-cn annotation in Ingress can be exploited by an attacker to inject arbitrary configuration into NGINX. This can lead to malicious code execution within the ingress-nginx controller's privileges and expose sensitive data accessible by the controller.

3. Vulnerability ID: CVE-2025-1098

• CVSS Score (3.1): 8.8

• Description: The mirror-target and mirror-host annotations in Ingress can be exploited by an attacker to inject arbitrary configuration into NGINX. This can lead to malicious code execution within the ingress-nginx controller's privileges and expose sensitive data accessible by the controller.

4. Vulnerability ID: CVE-2025-1974

• CVSS Score (3.1): 9.8

• Description: An unauthenticated attacker with access to the Kubernetes cluster's pod network can execute arbitrary code within the ingress-nginx controller. This can lead to full control over the controller and the cluster's sensitive data.

Figure 2: Attack Vector - Source: WIZ Research

Ingress NGINX has a component called the admission controller that runs in its pod, responsible for checking and validating ingress objects before they are deployed. However, this admission controller by default does not require authentication and can be accessed over the network without control, making it an attractive target for attackers.

A security vulnerability occurs during the NGINX configuration check. When the admission controller receives an ingress object, it creates an NGINX configuration from that object and validates the configuration using the NGINX binary. However, if an attacker sends a malicious ingress object over the network to the admission controller, it can allow arbitrary NGINX configurations to be injected into the process. When the malicious NGINX configuration is injected, the configuration validation process will execute code, leading to remote code execution on the Ingress NGINX Controller pod.

As a result, the attacker can execute remote code on the Ingress NGINX Controller pod, as the admission controller has high privileges and is not restricted in network access. This opens up a serious attack vector, allowing the attacker to take control of the entire cluster, potentially accessing and seizing all sensitive data within the cluster, including resources and secret information in the namespaces.

On the other hand, applications running on containers (Containerization) do not guarantee absolute safety. Many applications running on Kubernetes (K8s) can be easily attacked using container escape techniques, making it much easier to infiltrate a cluster's pod network. More dangerously, attackers often combine exploiting these vulnerabilities with SSRF (Server-Side Request Forgery) vulnerabilities, which are quite common in web applications, to increase the likelihood of attacking the cluster.

Exploiting the Vulnerability

Through constructed attack scenarios, security experts at WIZ have outlined the steps to exploit the vulnerability chain as follows:

1. The attacker uploads payloads as shared libraries into the pod by exploiting the client-body buffer feature of NGINX.

2. Send AdmissionReview requests to the admission controller of the Ingress NGINX Controller. These malicious requests contain customized directives that are injected.

3. The injected directive instructs NGINX to execute the malicious payloads uploaded as shared libraries, named ssl_engine.

4. The attacker specifies the path of ProcFS, a virtual file system in Linux that provides information about running processes. The attacker points the ProcFS path to the file descriptor of the payload to indicate the location of the uploaded payload.

5. Completing this process allows the attacker to execute remote code through the shared library and the uploaded malicious code.

Figure 3: Hypothetical attack scenario - Source: WIZ Research

Recommendations & Remediation

In their report, WIZ security experts also provided some recommendations and remediation methods for users. Users should check if their existing Kubernetes clusters are using ingress-nginx by using the command:

kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

For systems that can be upgraded immediately

• Upgrade to the latest versions 1.12.1, 1.11.5, and 1.10.7 of the Ingress NGINX Controller.

• Ensure the admission webhook endpoint is not accessible from outside the network. You can use Nuclei templates to scan and detect exposed Ingress-NGINX admission controllers.

For systems that cannot be upgraded immediately

• Implement strict network policies: Only allow the Kubernetes API server to access the admission controller.

• Temporarily disable: Disable the Ingress NGINX admission controller if an immediate system upgrade is not possible.

  • If ingress-nginx is installed via Helm, you can reinstall it with the parameter controller.admissionWebhooks.enabled=false.

  • If ingress-nginx is installed manually, you can remove components like ValidatingWebhookConfiguration, ingress-nginx-admission, --validating-webhook, ingress-nginx-controller.

  • Enable the Validating Admission controller to protect the Ingress configuration.

References

1. WIZ Research blog