NGINX vulnerability: Quickly detect and mitigate IngressNightmare vulnerabilities with Dynatrace

On March 24, 2025, researchers disclosed multiple vulnerabilities affecting Ingress NGINX Controller for Kubernetes. The highest scored vulnerability, CVE-2025-1974, has a CVSS v3.1 base score of 9.8. Successful exploitation requires attackers reaching the admission webhook over the network which is only possible if the webhook has been exposed externally or an attacker is already able to reach the webhook from within the cluster (for example, by having control over a pod). Any publicly exposed deployment of the ingress-nginx controller in version v1.12.0 or less than 1.11.5 could potentially be affected by these vulnerabilities. You can use Dynatrace to find these vulnerable components and search for indicators of compromise.

What is the NGINX vulnerability IngressNightmare?

Recently, researchers discovered a series of vulnerabilities in the Ingress NGINX Controller for Kubernetes, referred to as #IngressNightmare. These vulnerabilities, identified as CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, and CVE-2025-1974, allow unauthenticated remote code execution (RCE) and unauthorized access to secrets stored across all namespaces in a Kubernetes cluster. This could be further exploited to result in a complete cluster takeover due to the privileged nature of such controllers. The highest-scored vulnerability, CVE-2025-1974, carries a critical CVSS v 3.1 base score of 9.8.

The Ingress NGINX Controller is widely used to expose Kubernetes applications externally, making it a critical component for many organizations. Based on the researcher’s analysis, 43% of cloud environments could be affected by this combination of vulnerabilities.

How does an exploit of the IngressNightmare vulnerabilities work?

An attacker can achieve remote code execution (RCE) by chaining multiple flaws in the NGINX implementation if the admission webhook of the ingress-nginx controller is accessible to the attacker without authentication.

1. First, an attacker can upload a file to the NGINX instance itself, which stores large files in a temporary directory. To prevent immediate clean-up, the Content-Length header is manipulated to make the process think the file upload is not completed yet. This allows an attacker to upload any file to the filesystem and to keep it around for long enough for the next steps to execute.
2. The second flaw that is being exploited is the process of the ingress controller to test arbitrary admission templates via the nginx NGINX -t command. This command is vulnerable to injections in multiple variations, which allows an attacker to invoke a set of directives. One of these directives is the ssl_engine directive that allows the loading of a shared library into the running process.

Putting one and two together, with the ability to upload any file to a temporary directory and keeping it around for long enough to invoke a directive to load the file as a shared library, an attacker can inject arbitrary code and take over the deployment. From there it is only a matter of time for them to find additional secrets mounted in this usually highly privileged controller and take over the whole Kubernetes cluster.

What is affected by the NGINX vulnerability?

Any publicly exposed deployment of the ingress-nginx controller in version v1.12.0 or <1.11.5 could potentially be affected by these vulnerabilities. Kubernetes has released patches for version 1.11.6 and 1.12.1 that remediate all found vulnerabilities.

Detecting vulnerable instances of ingress-nginx

Using DQL you can quickly generate a list of ingress-nginx instances including versions being used, cluster and namespace information, and IP addresses being used by the service. Please see the sample queries appendix for an example query to get started.

Furthermore, using the DQL function ipIsPublic, it’s possible to filter directly on services having public IPs, which can be an indicator of attackers’ reachability. Check out the Network functions topic in the Dynatrace docs to learn more about the command.

Detecting post-exploitation activity using Kubernetes audit logs

One reason the severity of this vulnerability is so critical is because of the comprehensive permissions granted to the service account used by ingress-nginx. A ClusterRole called ingress-nginx is configured along with other components. As you can see in the following example, the ClusterRole grants permissions to list, secrets, configmaps, and other resources:

<...> 
rules: 
- apiGroups: 
 - "" 
 resources: 
 - configmaps 
 - endpoints 
 - nodes 
 - pods 
 - secrets 
 - namespaces 
 verbs: 
 - list 
 - watch 
<...>

An attacker that successfully triggers a remote code execution could use these permissions to access possibly sensitive data. Using DQL it’s possible to query Kubernetes audit logs about recent activities of the service account. You can find an example query in the sample queries appendix.

This can potentially surface signs of compromise, like:

• Abnormal user agents like curl, kubectl and others
• Requests to get or list all secrets or configmaps of the entire cluster (for example, no namespace is defined in the requests)

Sample queries appendix: Identify affected instances and analyze access patterns

Use the following queries to find affected instances of Ingress NGINX Controller for Kubernetes.

Sample query to list instances of ingress-nginx in the environment

fetch dt.entity.cloud_application 
| fieldsFlatten cloudApplicationLabels 
| fieldsFlatten kubernetesAnnotations 
| fieldsFlatten balanced_by 
| filter matchesValue(cloudApplicationLabels[`app.kubernetes.io/name`], "*ingress-nginx*") 
| expand balanced_by.dt.entity.kubernetes_service 
 
| join [ 
  fetch dt.entity.kubernetes_service 
  | fieldsFlatten kubernetesAnnotations 
  | fieldsAdd cloudNetworkServiceType 
  | fieldsAdd ipAddress 
  | expand ipAddress 
  | fieldsFlatten kubernetesLabels 
 ], 
  kind:leftOuter,  
  on:{left[balanced_by.dt.entity.kubernetes_service] == right[id]} 
 
| fieldsFlatten clustered_by 
 
| join [ 
  fetch dt.entity.kubernetes_cluster 
 ],  
  kind:leftOuter,  
  prefix: "k8scluster.",  
  on:{left[clustered_by.dt.entity.kubernetes_cluster] == right[id]} 
 
| summarize  
  {count = count(),  
  ipAddresses=collectDistinct(right.ipAddress)},  
 by: { 
  version = `cloudApplicationLabels.app.kubernetes.io/version`,  
  workload.name = `cloudApplicationLabels.app.kubernetes.io/name`,  
  namespace.name = `right.kubernetesAnnotations.meta.helm.sh/release-namespace`,  
  cluster.name = `k8scluster.entity.name`} 
 
| sort version desc

Sample query to analyze access patterns of the service account

fetch logs, from: -7d 
 
| parse content, "JSON{JSON{STRING+:log}(flat=true):properties}(flat=true)", 
 parsingPrerequisite: ( 
  azure.resource.type == "MICROSOFT.CONTAINERSERVICE/MANAGEDCLUSTERS" and  
  log.source == "kube-audit") 
| fieldsAdd content=coalesce(properties, content) 
 
| parse content, "JSON{ 
  STRING+:kind, 
  STRING+:apiVersion, 
  STRING+:level, 
  STRING+:auditID, 
  STRING+:stage, 
  STRING+:requestURI, 
  STRING:verb, 
  JSON:user, 
  JSON_ARRAY{ipaddr}(typed=true):sourceIPs, 
  STRING+:userAgent, 
  JSON:objectRef, 
  JSON:responseStatus, 
  TIMESTAMP('yyyy-MM-ddTHH:mm:ss.SZ'):requestReceivedTimestamp, 
  TIMESTAMP('yyyy-MM-ddTHH:mm:ss.SZ'):stageTimestamp, 
  JSON:annotations 
 }(flat=true)" 
 
| filter  
  apiVersion == "audit.k8s.io/v1" and 
  user[username] == "system:serviceaccount:ingress-nginx:ingress-nginx" and 
  in(verb, {"list", "get"}) and 
  in(objectRef[resource], {"configmaps", "secrets"}) 
 
| summarize {  
  count = count(),  
  start_time = takeMin(timestamp), 
  end_time = takeMax(timestamp), 
  resources = collectDistinct(objectRef[resource]), 
  verbs = collectDistinct(verb) 
 }, by: {  
  user[username], 
  user[uid], 
  userAgent 
 }

How to remediate clusters affected by the NGINX vulnerability

If your Kubernetes cluster is impacted, it’s recommended to upgrade the ingress-nginx controller to a patched version to mitigate the vulnerability. Follow these links to upgrade to one of the following secure releases:

• v1.12.1 or later (Helm chart version 4.12.1 or later)
• v1.11.5 or later (Helm chart version 4.11.5 or later)

If upgrading isn’t immediately possible, make sure the admission webhook is not exposed to the public internet. At a minimum, it should be restricted to private access—ideally limited solely to the control plane (API server).

Next steps for mitigating IngressNightmare

The IngressNightmare vulnerabilities—especially CVE-2025-1974 with its critical CVSS score of 9.8—highlight the high stakes of Kubernetes security. This vulnerability enables unauthenticated remote code execution via a trusted component, making even default configurations risky, as any pod can access the vulnerable webhook internally.

To mitigate the threat, teams should immediately upgrade ingress-nginx to a patched version or enforce strict network access controls.

Given Kubernetes is a backbone in many production environments, ingress components should be treated as critical, high-value assets, with continuous monitoring through a platform like Dynatrace that can detect it in runtime environments and help promptly respond to potential exploitation.