IngressNightmare Vulnerabilities: All You Need to Know

What is the Ingress Controller

In Kubernetes, an Ingress Controller manages external access to services within a cluster, typically via HTTP or HTTPS. The ingress NGINX Controller, built on the NGINX web server, is widely used to route incoming traffic to the appropriate backend services based on defined rules.

Understanding the IngressNightmare vulnerabilities

The disclosed vulnerabilities include:

CVE-2025-1974 (CVSS Score 9.8 Critical)
Allows unauthenticated attackers with pod network access to execute arbitrary code in the ingress-nginx controller, potentially leading to full cluster takeover.

CVE-2025-24514, CVE-2025-1097, CVE-2025-1098 (CVSS Score 8.8 High)
Involve improper handling of Ingress annotations that can lead to code execution or unauthorized data access.

CVE-2025-24513 (CVSS Score 4.8 Medium)
Involves directory traversal that can lead to DoS or limited secret disclosure.

Vulnerabilities Details and Impact

The researchers who found these vulnerabilities indicated that over 40% of cloud environments were vulnerable to these remote code execution (RCE) risks. Their analysis discovered over 6,500 clusters, including those of Fortune 500 companies, that publicly expose the admission controllers of vulnerable Kubernetes ingress controllers to the public internet, placing them at immediate critical risk.

The most critical issue, CVE-2025-1974, affects the admission controller component of the Ingress NGINX Controller. It allows remote code execution through a malicious Ingress object, potentially exposing secrets and compromising the entire cluster.

An exploit was published on GitHub.

Are you Affected? Detection and Mitigation

Query your clusters for ingress-nginx

If your pods use the commonly applied ingress-nginx label, run the following command to check for ingress-nginx in your cluster.

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

These vulnerabilities affect ingress-nginx. If ingress-nginx is not installed on your cluster, your environment is not affected.

Query the ingress-nginx version

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

If your deployment is using any version earlier than 1.11.5 or specifically 1.12.0, your cluster is vulnerable.

First steps to mitigate these vulnerabilities

Step 1: Upgrade to ingress-nginx version 1.12.1 or 1.11.5, which contain the necessary patches.

Step 2: Restrict network access to the admission webhook to only the Kubernetes API server. The admission webhook listens on port 8443 and by default is exposed inside the cluster. To prevent lateral movement from compromised pods. Apply a NetworkPolicy that allows traffic only from the Kubernetes API server to the ingress-nginx controller’s admission service.

Example policy (adjust namespace and labels as needed):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-admission-access
  namespace: ingress-nginx
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/component: admission-webhook
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
    ports:
    - port: 8443
      protocol: TCP
  policyTypes:
- Ingress

Step 3: If you can’t upgrade the ingress-nginx version immediatly, disable the admission controller.

For Helm installations

helm upgrade --install ingress-nginx ingress-nginx/ingress-nginx \
--set controller.admissionWebhooks.enabled=false

For Manifest-based installations

• Delete the ValidatingWebhookConfiguration:
  kubectl delete ValidatingWebhookConfiguration ingress-nginx-admission

• Edit the ingress-nginx deployment or daemonset to remove the --validating-webhook flag from the controller’s command args.

Important: The admission controller performs validation of Ingress resources. Disabling it is a temporary workaround and should be re-enabled after upgrading.

By promptly identifying and addressing these vulnerabilities, you can significantly enhance the security posture of your Kubernetes environment and safeguard against potential exploits.

Mitigating Vulnerabilities with Aqua

Use the Aqua Hub to detect any images or running containers/pods containing any of these vulnerabilities.

Figure 1: Aqua Hub detection of images containing the vulnerabilities

We ran one of the container images (detected above) in a pod, as can be seen in the example below:

Figure 2: Running a vulnerable ingress-nginx

In Aqua Hub, we can see that the ingress controller pod has been detected.

Figure 3: Aqua Hub search for this vulnerability in container/pods

By clicking on the container information and details you can see an overview of all the detected issues, such as vulnerabilities of malware.

Figure 4: Container risk overview

Further details about the vulnerability, and remediation recommendations are provided on the side panel.

Figure 5: Container specific vulnerability view

Detecting and Mitigating with Aqua Trivy

Trivy’s KBOM (Kubernetes Bill of Materials) allows you to map the composition of your Kubernetes clusters, including the cluster’s core components. You can generate a KBOM for your Kubernetes cluster and identify if it uses ingress-nginx and what version is installed.

trivy k8s –format cyclonedx –output ./kbom.cdx.json

trivy k8s command identifies ingress controller

This KBOM can be scanned for vulnerabilities just like any other SBOM. If your cluster is running the affected version of ingress-nginx, scanning the cluster’s KBOM will flag the vulnerability for you.

 trivy sbom ./kbom.cdx.json

trivy sbom command flags vulnerable ingress controller

Aqua Trivy scans your cluster components directly (without going through the KBOM generation) – just like Trivy can scan your images for vulnerabilities. If you scan a vulnerable cluster, Trivy will flag the ingress-nginx component for you.

trivy k8s –scanners vuln –report summary

trivy k8s command flags vulnerable ingress controller

Mitigating IngressNightmare vulnerabilities with trivy

Trivy’s misconfiguration scanner identifies risk and bad security practices in IaC (Infrastructure as Code) files, including in Kubenetes Resource files. Scanning your Kubernetes Resources, including Ingress resources, will flag malformed resource annotations, which prevents the vulnerability from being exploited.

trivy config ./ingress.yaml –severity CRITICAL

trivy scan results of malicious ingress flags the malicous annotation

This check could also be evaluated against the live cluster state or as validation check at admission time.

Vulnerability Impact Across Managed Kubernetes Platforms

Amazon EKS: AWS does not include the ingress-nginx controller by default in EKS clusters. Therefore, clusters without a manually installed ingress-nginx controller are unaffected. If you’ve deployed this controller, it’s essential to update to the latest patched versions (v1.11.5 or v1.12.1).

Azure AKS: AKS users who have integrated the ingress-nginx controller should promptly upgrade to the patched versions to mitigate potential risks associated with these vulnerabilities. If you are using the Managed NGINX ingress with the application routing add-on on AKS, the patches are getting rolled out to all regions and should be completed in a few days. No action is required. See Microsoft Security Advisory for more information about the vulnerabilities.

Google GKE: Google has published GCP-2025-013, confirming that these vulnerabilities only affect clusters where ingress-nginx has been installed. If you do not have ingress-nginx deployed, your GKE cluster is not impacted. If you do, you should upgrade to a patched version and follow the mitigation steps.

Red Hat OpenShift: OpenShift does not use ingress-nginx; it has its own native ingress controller based on HAProxy. Therefore, these vulnerabilities do not apply unless ingress-nginx was explicitly deployed in a custom configuration. However, users of OpenShift on AWS (ROSA) or Azure (ARO) should verify if ingress-nginx has been deployed manually.

VMware Tanzu Kubernetes Grid: VMware Tanzu may use ingress-nginx depending on the deployment profile. VMware has published a security bulletin for Tanzu users—administrators should verify the presence of ingress-nginx and patch if necessary.

Rancher/SUSE: Rancher enables flexible ingress controller deployment. ingress-nginx is often installed via Helm or Rancher UI, so many Rancher-based clusters may be affected. Rancher users should check their workloads and update any vulnerable ingress-nginx deployments.