A critical vulnerability (CVE-2025-1974) was recently discovered in the Kubernetes Ingress-NGINX Controller that allows unauthenticated remote code execution (RCE) on the ingress controller pod.

Originally discovered by the Wiz research team (Nir Ohfeld, Ronen Shustin, Sagi Tzadik, Hillai Ben-Sasson) in late 2024 and disclosed in March 2025, CVE-2025-1974 is part of a series of vulnerabilities collectively called IngressNightmare.

What is Ingress-Nginx Controller?

Ingress-Nginx Controller is one of the most popular ingress controllers available for Kubernetes, and a core Kubernetes project with over 18.1k+ stars on GitHub. It serves as a critical component in the Kubernetes ecosystem, acting as the gateway between external traffic and internal services running within a Kubernetes cluster.

The Role of Ingress Controllers in Kubernetes

In Kubernetes, an Ingress is an API object that manages external access to services within a cluster, typically via HTTP/HTTPS. However, the Ingress resource itself doesn't do anything without an Ingress controller - a component that interprets the Ingress resource specifications and configures the actual routing.Ingress-Nginx Controller fulfills this role by implementing the Ingress specification using NGINX, one of the most widely used reverse proxies and load balancers. It's explicitly highlighted in the Kubernetes documentation as an example Ingress controller that fulfills the prerequisite for using Ingress in Kubernetes.

Technical Details of the Vulnerability (CVE-2025-1974)

The Admission Controller Vulnerability

CVE-2025-1974 is a critical vulnerability in the Ingress-Nginx Controller that allows for unauthenticated remote code execution. At its core, this vulnerability stems from a design flaw in how the admission controller component processes and validates incoming ingress objects.The admission controller in Ingress-Nginx is designed to validate incoming ingress objects before they are deployed to ensure the resulting NGINX configuration will be valid. By default, these admission controllers are accessible over the network without authentication, making them a highly appealing attack vector.

The Vulnerability Mechanism

When the Ingress-Nginx admission controller processes an incoming ingress object, it constructs an NGINX configuration from it and then validates it using the NGINX binary with the -t flag. Wiz research team found a vulnerability in this phase that allows injecting arbitrary NGINX configuration remotely by sending a malicious ingress object directly to the admission controller through the network.The vulnerability specifically involves the Ingress annotation, which can be exploited to inject configuration into NGINX. Some annotations can be manipulated to inject arbitrary NGINX directives.Let's examine how this works:

From Configuration Injection to RCE

The progression from configuration injection to remote code execution exploits weaknesses in NGINX’s configuration validation process. Initially, Wiz research team explored the load_module directive, which allows loading shared libraries from the filesystem. However, since this directive can only be used at the start of the NGINX configuration, it was incompatible with the injection point. Further investigation led to the ssl_engine directive, part of the OpenSSL module, which can also load shared libraries. Unlike load_module, ssl_engine can be used anywhere within the configuration file.

Uploading a Shared Library

The next challenge in exploiting this vulnerability is placing a shared library on the pod's filesystem. The research team discovered that the Ingress-Nginx pod also runs the NGINX instance itself, listening on port 80 or 443. By sending a specially crafted HTTP request to this instance, we can leverage NGINX's client body buffers to upload a malicious shared library to the filesystem.Once the shared library is uploaded and the malicious configuration is injected, the ssl_engine directive loads the library during the validation phase, executing the attacker's code with the privileges of the Ingress-Nginx controller pod.

Affected Versions

This vulnerability affects:

The vulnerability has been fixed in versions 1.12.1 and later, as well as 1.11.5 and later.

Exploitation Demonstration

This section provides a detailed walkthrough of how CVE-2025-1974 can be exploited in vulnerable Ingress-Nginx Controller deployments. Understanding the exploitation process is crucial for security teams to properly assess their risk and validate their defenses.

It's important to note that by default, admission controllers are accessible over the network without authentication, making this attack vector particularly dangerous.

Step 1: Identify Vulnerable Clusters

First, an attacker would identify clusters running vulnerable versions of Ingress-Nginx Controller. This can be done by:bash

Then checking the image version to determine if it's vulnerable (versions prior to 1.11.5 or 1.12.1).

Step 2: Craft a Malicious Admission Review Request

The attacker creates a specially crafted AdmissionReview request that includes an ingress object with the malicious auth-url annotation. Here's an example of such a request:

The key part of this payload is the auth-url annotation, which contains the NGINX configuration injection.

Step 3: Upload a Malicious Shared Library

In parallel, the attacker needs to upload a malicious shared library to the pod's filesystem. This can be done by sending a specially crafted HTTP request to the NGINX instance running in the same pod:

Step 4: Execute the Payload

When the admission controller processes the malicious ingress object, it will:

Nuclei Templates for IngressNightmare Detection

To help security teams identify vulnerable Ingress-Nginx Controller deployments in their environments, we've write Nuclei templates for both external and internal testing. These templates can be used to detect the presence of CVE-2025-1974 in your Kubernetes clusters.

Vulnerable Exposed Admission Controller Template

This template is designed to detect vulnerable Ingress-Nginx admission controllers that are exposed to the internet. It works by sending a crafted admission review request and analyzing the response.

Nuclei Template to detect CVE-2025-1974 - CVE Scan URL

Template Breakdown:

Sending a POST request to the target host with a specially crafted AdmissionReview JSON payload

This template is particularly useful for identifying externally exposed admission controllers that could be targeted by attackers.

Internal Kubernetes Cluster Template

The following template is to be run from within a Kubernetes cluster. This can come in handy along with other Kubernetes Cluster Security templates during Kubernetes configuration review engagements.

It checks for vulnerable versions of the Ingress-Nginx controller by examining the container images used in the deployment.

Template Breakdown:

This template is particularly useful for security teams conducting internal audits of their Kubernetes environments.

To use these templates with Nuclei:

It's important to note that the internal template requires kubectl access to your cluster with appropriate permissions, while the external template can be run from anywhere with network access to the target.

Remediation Recommendations

We strongly recommend the following actions to mitigate the risk of this vulnerability:

Timeline:

Conclusion