Issues with Kubernetes ingress-nginx controller (CVE-2025-1974)

On March 26, 2025, a critical vulnerability—CVE-2025-1974—was reported in the ingress-nginx controller, which is widely used in Kubernetes environments for routing HTTP(S) traffic to applications. The vulnerability allows attackers to bypass security controls through the admission webhook exposed by the ingress-nginx controller, potentially compromising the integrity of the cluster.

In this article, we'll discuss the details of this vulnerability, how to assess whether your Amazon EKS (Elastic Kubernetes Service) cluster is affected, and the steps you should take to mitigate this risk.

What is CVE-2025-1974?

CVE-2025-1974 is a security vulnerability in the ingress-nginx controller's admission webhook. The ingress-nginx controller is a commonly used solution to manage HTTP(S) traffic in Kubernetes clusters. The vulnerability is specifically linked to improper configuration of the admission webhook, which is responsible for validating Ingress resources.

If exposed externally, this webhook could allow an attacker to manipulate the ingress controller's configuration, bypassing security measures and gaining control over the ingress configurations. The severity of the vulnerability makes it critical to patch any clusters running affected versions of ingress-nginx.

How Can You Check If Your EKS Cluster Is Vulnerable?

To check whether your EKS cluster is vulnerable to CVE-2025-1974, follow these steps. This guide will cover how to check both internally and externally for vulnerabilities in your cluster.

1. Verify the Presence of ingress-nginx in Your Cluster

Start by confirming if the ingress-nginx controller is installed in your cluster. You can do this by running the following command to list the pods related to ingress-nginx:

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

If no pods are listed, it means the ingress-nginx controller is not installed, and your cluster is not affected by this vulnerability.

2. Check the Version of ingress-nginx

If ingress-nginx is installed, you need to check the version of the ingress controller to determine if it’s vulnerable. The ingress-nginx versions prior to 1.11.5 and 1.12.1 are affected by CVE-2025-1974. You can check the version of the ingress-nginx controller by running:

kubectl describe deployment ingress-nginx-controller -n ingress-nginx | grep "Image:"

This command will display the version of ingress-nginx in your cluster. If the version is earlier than 1.11.5 or 1.12.1, your cluster is vulnerable and requires an update.

3. Assess Network Exposure of the Admission Webhook

Next, assess whether the admission webhook is exposed externally. By default, the admission webhook is not publicly accessible, but configurations can vary based on your setup.

Internal Exposure: If the admission webhook is only accessible within the cluster (e.g., https://ingress-nginx-controller-admission.ingress-nginx.svc.cluster.local), the risk is lower. However, it's still important to ensure that only trusted entities inside the cluster can interact with the webhook.
External Exposure: If the webhook is accessible externally (from the public internet), it is highly vulnerable. Attackers can exploit the webhook and compromise the security of your cluster. You can check the external exposure by reviewing the ingress-nginx service and the associated ingress rules.

kubectl get svc -n ingress-nginx

If any service related to the admission webhook is exposed with an external IP or a publicly accessible LoadBalancer, your cluster is at a significant risk.

Mitigation Steps

If your cluster is affected by CVE-2025-1974, there are a few key steps you should take to mitigate the risk:

1. Upgrade ingress-nginx

The most important action is to upgrade the ingress-nginx controller to a version that addresses the vulnerability. As of this writing, versions 1.11.5 and 1.12.1 or later are free from this vulnerability.

To upgrade your ingress-nginx controller, follow the official upgrade instructions from the ingress-nginx documentation.

2. Temporarily Disable the Admission Controller

If upgrading or restricting access is not immediately possible, you can temporarily disable the admission webhook. However, this is not a recommended long-term solution, as the admission webhook performs critical security validation.

To disable it temporarily:

kubectl delete ValidatingWebhookConfiguration ingress-nginx-admission

You can also remove the --validating-webhook argument from the ingress-nginx controller’s deployment or daemonset. However, make sure to re-enable the webhook once you have updated your ingress-nginx to a secure version.

Conclusion

CVE-2025-1974 poses a serious security threat to Kubernetes clusters using ingress-nginx. By following the steps outlined above, you can assess whether your EKS cluster is vulnerable to this issue and take the necessary steps to mitigate the risk.

Upgrading to a secure version of ingress-nginx and restricting the exposure of your admission webhook are the most effective ways to protect your cluster from this vulnerability. Stay up to date on security patches, and implement proper network policies to minimize the risk of external exposure.

For detailed guidance, consult the Kubernetes security documentation and consider regularly auditing your cluster for potential vulnerabilities to safeguard your infrastructure.

References: