Kubernetes IngressNightmare Vulnerabilities: What You Need to Know

We would like to recognize Amit Serper, Travis Lowe, Tony Gore, Adrian Godoy, Mihai Vasilescu, Suraj Sahu, Pablo Ramos, Raj Jammalamadaka, Lacie Griffin, and Josh Grunzweig for their contributions in authoring this publication.

CrowdStrike is committed to protecting our customers from the latest disclosed vulnerabilities. We are actively monitoring activity surrounding “IngressNightmare,” the name given to recently identified vulnerabilities in the Kubernetes (K8s) ingress-nginx controller.

In this blog, we discuss the significance of these vulnerabilities, how CrowdStrike protects its customers from adversaries attempting exploitation, and how this issue can be discovered within the CrowdStrike Falcon® platform.

Overview of IngressNightmare

On March 24, 2025, security researchers¹ disclosed several new vulnerabilities in ingress-nginx, a highly popular Kubernetes ingress controller used in many large Kubernetes deployments. The nature of ingress controllers’ purpose, which is to accept and handle incoming connections and traffic, dramatically increases the chances of exposure to exploitation.

IngressNightmare refers to a set of four vulnerabilities that can be exploited in an attack chain. The threat actor must exploit one of these three vulnerabilities initially:

• CVE-2025-24514: ingress-nginx controller — configuration injection via unsanitized auth-url annotation (High)
• CVE-2025-1097: ingress-nginx controller — configuration injection via unsanitized auth-tls-match-cn annotation (High)
• CVE-2025-1098: ingress-nginx controller — configuration injection via unsanitized mirror annotations (High)

The initial exploit must be chained with:

• CVE-2025-1974: ingress-nginx admission controller RCE escalation (Critical)

CVE-2025-1974 is the most critical vulnerability (CVSS 9.8) and exists in the Kubernetes ingress-nginx admission controller. This allows an arbitrary file upload and execution within the context of the ingress-nginx process, which runs with a service account with privileged access to all cluster secrets and cluster network access. As such, an attacker within the pod network could have access to all cluster secrets and the ability to move laterally within the cluster.

Impacted K8s Ingress-Nginx Controller

The following versions of K8s are affected by these vulnerabilities:

• All versions prior to v1.11.0
• v1.11.0 - 1.11.4
• v1.12.0

Patching as soon as possible is highly recommended. Alternatively, removing the ValidatingWebhook can be used as a stopgap to break the exploit chain until a new version can be deployed.

Are You Vulnerable?

CrowdStrike Falcon Next-Gen SIEM Dashboard

Customers may leverage the following CrowdStrike Falcon® Next-Gen SIEM dashboard to gain relevant visibility into their environment as it pertains to the outlined vulnerabilities:

• CrowdStrike - EmergingThreat - IngressNightmare (CVE-2025-1974)

As outlined in Figure 1 below, this dashboard provides visibility into environments potentially vulnerable to the IngressNightmare vulnerability (CVE-2025-1974) affecting ingress-nginx. It monitors Linux hosts, Kubernetes clusters, and public cloud environments that are running a Falcon sensor to identify vulnerable versions and track remediation progress.

Security teams can use this dashboard to quickly assess exposure across their infrastructure, prioritize remediation efforts, and verify that vulnerable controllers have been patched or replaced. The dashboard supports incident response activities by providing detailed information about affected systems and enabling targeted remediation actions.

While captured within the dashboard itself, the following queries may be leveraged to identify all ingress-nginx controllers, as well as those vulnerable to IngressNightmare, respectively.

The first CrowdStrike Falcon® LogScale query, outlined below, will query and parse all observed instances of the ingress-nginx controller and subsequently pull in the version that it is currently running. It will then parse this version and break it into its major version, minor version, and patch number. The information is then captured and surfaced to the user, providing full visibility into all instances and versions of the ingress-nginx controller within an organization.

#event_simpleName=K8SDeployment
 K8SLabels=*app.kubernetes.io/name#ingress-nginx*
| parseJson(field=K8STemplate, prefix="pod.")
| ingressNginxImage := rename(pod.spec.containers[0].image)
| ingressNginxImage = /:v?(?<majorVersion>\d+)\.(?<minorVersion>\d+)\.(?<patchNumber>\d+)?/i
| groupBy([ingressNginxImage, majorVersion, minorVersion, patchNumber])
| sort()

The second Falcon LogScale query, outlined below, will take the first rule and extend it further. Using the captured major version, minor version, and patch numbers, the query will seek out instances where versions that are vulnerable to IngressNightmare are observed. These vulnerable instances are then surfaced to the user, allowing the organization to take further actions.

#event_simpleName=K8SDeployment
 K8SLabels=*app.kubernetes.io/name#ingress-nginx*
| parseJson(field=K8STemplate, prefix="pod.")
| ingressNginxImage := rename(pod.spec.containers[0].image)
| ingressNginxImage = /:v?(?<majorVersion>\d+)\.(?<minorVersion>\d+)\.(?<patchNumber>\d+)?/i
| groupBy([ingressNginxImage, majorVersion, minorVersion, patchNumber])
| (majorVersion=0) or (majorVersion=1 minorVersion<11) or (majorVersion=1 minorVersion=11 patchNumber<5) or (majorVersion=1 minorVersion=12 patchNumber=0)
| sort()

Falcon Cloud Security Image Assessment 

A provided query gives visibility into any matches for the vulnerabilities in image scanning.

Manual Discovery

To manually discover if your environment is impacted by these vulnerabilities, you must first check if ingress-nginx is present in your cluster, as noted in the command below:

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

Next, you must check the image tags for vulnerable versions through the following command:

kubectl get pods -A --selector app.kubernetes.io/name=ingress-nginx -o custom-columns="NAMESPACE:.metadata.namespace,NAME:.metadata.name,IMAGES:.spec.containers[*].image"

Additionally, users may check to see if the ValidatingWebhook is in place, as noted in the following command:

kubectl -n ingress-nginx get ValidatingWebhookConfiguration ingress-nginx-admission

Users may also check if the admission controller is exposed to the internet with the following command:

kubectl -n ingress-nginx get service
ingress-nginx-controller-admission

In the case of the screenshot above, the admission controller server is not public. This confirms the vulnerability is not directly exploitable from the internet. However, the vulnerability still exists, and other pods within the cluster could be utilized to trigger the exploit.

How CrowdStrike Falcon Protects Customers

CrowdStrike employs a layered approach for detecting exploitation and post-exploitation using machine learning and behavior detections. One way a threat actor could fully compromise the Kubernetes cluster is by initially gaining access to the vulnerable pod by successfully exploiting CVE-2025-1974, and utilizing the service account within the pod to query secrets in the cluster. 

The following Falcon LogScale query may be leveraged to identify when secrets are being queried within a cluster:

#repo="base_sensor" #event_simpleName="ProcessRollup2"
| CommandLine=/\s+get\s+secret(s)?\s+-(A|-all-namespaces)/
| groupBy([aid, ComputerName, LocalAddressIP4], function=collect([CommandLine, ImageFileName]))

An example output from this query being run within an environment, and the subsequent results, may be seen below:

A Falcon sensor protecting a Kubernetes cluster will have full visibility into the malicious activity happening on the affected Kubernetes node; additionally, these events are sent to Falcon Next-Gen SIEM. Our customers can leverage Falcon Next-Gen SIEM rule templates or Advanced Event Search to query any evidence of exploitation attempts.

Any following post-exploitation activity will be detected and prevented by our existing machine learning and behavior detection coverage for the post-exploitation techniques.

CrowdStrike has created the following rule template that detects instances where an exploit was attempted by observing shared objects being loaded from the /tmp/nginx/client-body/ directory:

• CrowdStrike - Endpoint - Shared Object Loaded From client-body Directories (IngressNightmare / CVE-2025-1974)

An example of the detection that fires as a result of enabling this rule template can be seen below:

In order to enable this rule template, customers may refer to the linked URL above and follow the necessary steps to test and enable this rule template within their environment. Alternatively, customers may navigate to the Rules Templates page under Falcon Next-Gen SIEM and filter on the rule name above.

Conclusion and Recommendations

The IngressNightmare suite of vulnerabilities gives attackers the ability to ultimately take over a cluster through uploading and loading of a malicious library into the ingress-nginx admission controller process. 

CrowdStrike customers may leverage the provided dashboard, rule templates, or Advanced Event Search queries to identify vulnerable K8s clusters and any exploitation attempt within their organization, and take appropriate actions toward remediation. 

Due to the potential impact of these vulnerabilities, customers are encouraged to follow these recommendations to secure their environment(s):

• Patch all affected instances of K8s (versions 1.12.0, 1.11.0 through 1.11.4, and all versions prior to 1.11.0) as quickly as possible
  • Removing the ValidatingWebhook, or otherwise making it not publicly available, can be used as a stopgap until patching is possible
• Leverage the provided CrowdStrike dashboard, rule templates, or queries for continued monitoring of your environment

1. Researchers at Wiz discovered and disclosed these vulnerabilities