Overview
Many Kubernetes clusters utilize an Ingress to handle routing incoming requests. Creating an ingress by itself does not do anything, you have to also install an Ingress Controller which will handle the actual routing logic that you define. One of the most popular Ingress Controllers is the Ingress NGINX Controller. In order to make this Controller more usable, it implements a Validating Admission Webhook, which can be thought of as a helper utility that confirms any NGINX configuration you want to apply is valid and rejects any malformed configurations. A recent series of vulnerabilities found a way to reliably abuse this helper and cause remote code execution within the Ingress NGINX Controller.
How dangerous is this?
The most serious of these exploits is extremely dangerous as it is believed to impact a significant amount of public-facing Kubernetes clusters and is extremely reliable to reproduce, resulting in a 9.8 CVSS. Additionally, the vulnerable pods often have very high privileges in your Kubernetes cluster, meaning an attacker could easily use remote code execution to gain access to sensitive information.
Technical Details
A series of vulnerabilities have been recently discovered in the popular Ingress NGINX Controller for Kubernetes. These vulnerabilities stem from the Ingress NGINX Admission Webhook accepting unsanitized inputs while validating an NGINX configuration leading to arbitrary NGINX configuration injection. This exploit can be combined with NGINX Client Body Buffering to store arbitrary code on the Ingress NGINX Controller pod and execute it directly. This vulnerability is particularly dangerous since Admission Webhooks are often publicly exposed and unprotected, greatly amplifying the threat surface. Additionally, the Ingress NGINX Controller pod that processes them typically have broad access to resources within your cluster such as global Secret access. This means that executing arbitrary code from them can easily lead to leaking vulnerable information stored in your cluster.
How to Check If You Are Affected?
You can determine if your clusters are impacted by:
1. Determining if your version of the Ingress NGINX Controller is vulnerable: There are two currently patched versions for this vulnerability v1.12.1 and v1.11.5. If you have installed the controller using Helm you can run the following command and use the APP VERSION column to determine if you are running a patched version (far right column):
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
ingress-nginx ingress-nginx 20 2025-03-25 10:26:03.343404 -0700 PDT deployed ingress-nginx-4.12.1 1.12.1
2. Determining if any ingress in your cluster is using the Ingress NGINX Controller: You can run the following command while connected to your cluster to determine if any of your ingresses are using the Ingress NGINX Controller:
kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx
I am Impacted, What Should I Do?
If you are impacted you should consider upgrading your Ingress NGINX Controller version to a patched version. If this is not possible, you should instead consider disabling the Validating Admission Webhook either by manually deleting it or upgrading your Helm release with the following config set:
controller.admissionWebhooks.enabled=false
Below are two ways to solve this issue using Helm:
1. Upgrade your existing Helm chart to a patched version
export NGINX_INGRESS_RELEASE_NAME=<your release name>
export NGINX_INGRESS_RELEASE_NAMESPACE=<your release namespace>
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update ingress-nginx
helm upgrade --reuse-values $NGINX_INGRESS_RELEASE_NAME ingress-nginx/ingress-nginx --version 4.12.1 -n $NGINX_INGRESS_RELEASE_NAMESPACE2. Disabling Admission Webhooks on your existing Helm chart
export NGINX_INGRESS_RELEASE_NAME=<your release name>
export NGINX_INGRESS_RELEASE_NAMESPACE=<your release namespace>
export NGINX_INGRESS_CHART_VERSION=<your chart version>
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update ingress-nginx
helm upgrade --reuse-values --set controller.admissionWebhooks.enabled=false $NGINX_INGRESS_RELEASE_NAME ingress-nginx/ingress-nginx --version $NGINX_INGRESS_CHART_VERSION -n $NGINX_INGRESS_RELEASE_NAMESPACE
I am a Kapstan customer, do I need to take any action?
At Kapstan, we constantly monitor for new vulnerabilities throughout the Kubernetes ecosystem and handle automatic upgrade paths for existing users. If you are a Kapstan customer, you do not need to worry about this or any future vulnerabilities.
If you are not using Kapstan to manage your kubernetes cluster, and are unsure if you are impacted or are seeking security advice for your Kubernetes environments, we are here to help. We simplify the process of running applications on secure, reliable infrastructure on all major public clouds. To learn more about how you and your team can accelerate your development process and automate security patches, reach out to us today, or email us at hi@kapstan.io.
Additional Resources and Official Advisories
