Detecting the Execution of IngressNightmare via Security Command Center

[ascoon]

Overview

This blog details the ability of Google’s Security Command Center (SCC) to detect the execution of the IngressNightmare vulnerability chain affecting Kubernetes Ingress Nginx Controllers, which was discovered by Wiz. Successful exploitation of CVE-2025-1974 can result in remote code execution.  Exploitation of this vulnerability can be detected by SCC’s Container Threat Detection, which is a built-in service that continuously evaluates all changes and remote access attempts to detect runtime attacks in Google Kubernetes Engine (GKE) in near-real time. This blog will also touch on how to identify if your clusters are using ingress-nginx.

Background

Recently disclosed vulnerabilities (CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, and critically, CVE-2025-1974 with a CVSS score of 9.8) within ingress-nginx, a widely adopted Kubernetes Ingress controller, present a significant risk. These vulnerabilities could allow malicious actors to execute arbitrary code within the ingress-nginx controller, potentially leading to the exposure of sensitive Kubernetes Secrets. Ingress-nginx is not installed by default in GKE so customers aren’t vulnerable by default. 

Exploitation

To take advantage of this vulnerability, an attacker would need to upload a shared library to the target pod, taking advantage of NGINX Client Body Buffering to keep the file available for execution. Then they would send an AdmissionReview request with a maliciously crafted "ssl_engine load_module" annotation to the NGINX admission controller, which would trigger the loading of the previously uploaded shared library. Lastly, the attacker would need to locate the shared library using the file descriptor reference from the /proc filesystem (by searching in /proc/*/fd/**) in order to trigger its execution.

Discovery

1.  Check if your GKE clusters are using ingress-nginx by using one of the following commands:
   • Check an individual cluster:
     • kubectl get pods --all-namespaces --selector
       app.kubernetes.io/name=ingress-nginx
       
   • Check multiple clusters at once using a Cloud Asset Inventory resource search query:
     • gcloud asset search-all-resources \
         --scope='organizations/ORGANIZATION_ID' \
         --asset-types='k8s.io/Pod' \
         --query='labels."app.kubernetes.io/name"="ingress-nginx"
       Replace ORGANIZATION_ID with your organization resource ID. For details, see Getting your organization resource ID.
2. Upgrade ingress-nginx to a patched version. For details, see the official Kubernetes CVE feed.
3. Read about customizing network isolation in GKE.

Detecting Ingress Nightmare

By focusing on the most critical CVE (CVE-2025-1974 with a CVSS of 9.8), this exploit can be detected by monitoring nginx execution with arguments that include references to the /proc filesystem by the ingress-nginx container.

Security Command Center Premium and Enterprise customers who have the Container Threat Detection service enabled, have coverage for this scenario via the detection Execution: IngressNightmare Vulnerability Exploitation.

The detection is off by default so customers need to enable it by following our guide for module enablement to enable the detector at the desired level (organization, folder or project) which is dependent on your Security Command Center entitlement.

More specifically, customers can run this command line to enable the detector at a project level:

PROJ_NUM=<Project number >
gcloud alpha scc settings services modules enable \
--service=CONTAINER_THREAT_DETECTION \
--module=INGRESS_NIGHTMARE_VULNERABILITY_EXPLOITATION \
--project=${PROJ_NUM}

References

• https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities

[_K_O]

@ascoon is there a way to view the enabled / disabled modules through the UI? 

---

@ascoon wrote:

The detection is off by default so customers need to enable it by following our guide for module enablement to enable the detector at the desired level (organization, folder or project) which is dependent on your Security Command Center entitlement.

---

There is a modules option in SHA, but the module isn't available here - I'm guessing that it's meant to be enabled in "Container Threat Detection" but that doesn't have a modules tab. 

[ascoon]

For Container Threat Detection, we do not expose the individual modules in the UI like we do for SHA and ETD. To enable the detection, you need to use the gcloud command mentioned:

PROJ_NUM=<Project number >
gcloud alpha scc settings services modules enable \
--service=CONTAINER_THREAT_DETECTION \
--module=INGRESS_NIGHTMARE_VULNERABILITY_EXPLOITATION \
--project=${PROJ_NUM}

[_K_O]

@ascoon  Is there a public list of modules? Being able to enable this 1 detection is great but it seems as if a lot can get missed from a user's perspective if there is no way of knowing which modules exist. 

[ascoon]

@_K_O the list of modules that are available can be found here: https://cloud.google.com/security-command-center/docs/concepts-container-threat-detection-overview. 

[_K_O]

@ascoon the list that you provided does not include the INGRESS_NIGHTMARE_VULNERABILITY_EXPLOITATION module. This is the exact issue that I was concerned about, are there plans to have the "Container Threat Detection" modules available in the GUI as with the other categories?

[ascoon]

Hi @_K_O, apologies for the miscommunication - the documentation has been updated to reflect the addition of they new detection and there are plans to add the Container Threat Detection modules in the GUI, along with the other supported categories. I'll circle back with more details around adding the modules to the GUI.