In the developed Kubernetes ingress controller project ingress-nginx, four vulnerabilities have been identified that allow for code execution on the servers of cloud systems using the Kubernetes platform and provide full privileged access to the Kubernetes cluster. The issues have been assigned a critical threat level (9.8 out of 10). The researchers who discovered the problems have given the vulnerabilities the codename IngressNightmare and noted that they affect approximately 43% of cloud environments. The vulnerabilities have been fixed in ingress-nginx versions 1.11.5 and 1.12.1.
The ingress controller acts as a gateway and is used in Kubernetes to manage access from the external network to services within the cluster. The ingress-nginx controller is the most popular and utilizes server NGINX to route requests to the cluster, handle external request routing, and balance load. The Kubernetes project provides basic ingress controllers for AWS, GCE, and nginx, the latter of which is not related to the kubernetes-ingress controller, which is maintained by F5/NGINX (the vulnerabilities discussed do not affect projects developed by NGINX developers; the mention of nginx in the name ingress-nginx is solely due to the use of nginx as a proxy).
The vulnerabilities allow an unauthenticated attacker to execute their code in the context of the ingress-nginx controller when able to send a request to the Admission web handler. During network scanning, more than 6,500 vulnerable Kubernetes clusters were identified using publicly vulnerable controllers with an Admission handler open to external requests.
In the default configuration, launched attacker code can access the settings of the Ingress object, which, among other things, store credentials for accessing Kubernetes servers, allowing privileged access to the entire cluster. To circumvent the protection, it is recommended to disable the 'Validating Admission Controller' feature in ingress-nginx.
The Admission controller runs in a separate pod environment and performs checks on incoming ingress objects before they are deployed. By default, the Admission web handler accepts requests without authentication from the public network. During the verification process, the Admission controller creates a configuration for the nginx HTTP server based on the content of the received ingress object and checks its validity.
The identified vulnerabilities allow for the injection of custom settings into nginx by sending specially crafted ingress objects directly to the Admission controller. Researchers found that some properties of the verification requests set in the '.request.object.annotations' field are directly injected into the nginx configuration. In this case, the generated configuration is not applied but is only tested by running the 'nginx' executable with the '-t' option.
Specifically, the injection of external data into the configuration occurs for the parameters 'mirror-target', 'mirror-host' (CVE-2025-1098), 'auth-tls-match-cn' (CVE-2025-1097), and 'auth-url' (CVE-2025-24514). For example, in the configuration line 'set $target {{ $externalAuth.URL }};', the URL specified in the 'auth-url' parameter is injected in place of '{{ $externalAuth.URL }}'. At the same time, the validity of the URL is not checked. Consequently, an attacker can pass a URL value like 'http://example.com/#;\nsettings' and inject their settings into the configuration file.
To execute arbitrary code during the configuration check with the command 'nginx -t', researchers exploited the fact that in addition to checking the syntax, nginx loads libraries with modules and opens files mentioned in the configuration to assess their availability. Among other things, when processing the ssl_engine directive, the shared library specified in the directive is loaded for the engine. SSL-engine.
To load their library onto the Kubernetes server, researchers took advantage of (CVE-2025-1974) the fact that when handling large requests, nginx saves the request body to a temporary file, which is immediately deleted. However, an open file descriptor remains for this file in the '/proc' filesystem. Thus, one can simultaneously send requests to save the temporary file and initiate a configuration check, where the path to the descriptor in the '/proc' filesystem is specified in the 'ssl_engine' directive.
To keep the file descriptor accessible for an extended period, the "Content-Length" value in the request can be specified to be significantly larger than the actual data being transmitted (the server will wait for the remaining data to be received). An additional complication is the need to guess the PID of the process and the file descriptor number associated with the loaded shared library, but since a minimal number of processes are usually running in the container, the required values can be guessed through trial and error. If successful and the supplied shared library is loaded, the attacker can access the parameters stored within the pod environment, sufficient to manage the entire cluster.
To check for the use of the vulnerable ingress-nginx, you can run the command: kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx
Source: opennet.ru
