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. <\/p>\n
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<\/a> 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). <\/p>\n 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. <\/p>\n In the default configuration, the attacker can execute code that may access the settings of the Ingress object, where, among other things, credentials for accessing Kubernetes servers are stored, allowing privileged access to the entire cluster. It is recommended to disable the 'Validating Admission Controller' feature in ingress-nginx as a workaround for this vulnerability. <\/p>\n 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. <\/p>\n The identified vulnerabilities allow for the injection of custom settings into nginx by sending a specially crafted ingress object directly to the Admission controller. Researchers found that certain properties of validation requests set in the field '.request.object.annotations' are directly injected into the nginx configuration. However, the generated configuration is not applied, but rather tested by running the 'nginx' executable with the '-t' option. <\/p>\n In particular, the injection of external data into the configuration is performed for 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 instead of '{{ $externalAuth.URL }}'. No validity checks are performed on the URL. Consequently, an attacker can inject a value like 'http:\/\/example.com\/#;\nsettings' as the URL and insert their settings into the configuration file. <\/p>\n To execute arbitrary code during the configuration check with the command 'nginx -t', researchers exploited the fact that, in addition to checking syntax, nginx loads libraries with modules and opens files mentioned in the configuration to assess their availability. Among other things, processing the ssl_engine directive causes the specified shared library to load. SSL<\/a>-engine. <\/p>\n To upload their library to the Kubernetes server, researchers exploited (CVE-2025-1974) the fact that when processing large requests, nginx saves the request body to a temporary file that is immediately deleted, but an open file descriptor remains in the filesystem «\\\/proc» for that file. Thus, it is possible to simultaneously send requests to save the temporary file and initiate a configuration check, in which the path to the descriptor in the «\\\/proc» filesystem is specified in the «ssl_engine» directive. <\/p>\n To ensure the file descriptor remains accessible for an extended period, the value of «Content-Length» in the request can be declared significantly larger than the actual data sent (the server will wait for the remaining data to arrive). An additional complication is the necessity to guess the PID of the process and the number of the file descriptor related to the loaded shared library, but since only a minimal number of processes usually run in the container, the required values can be guessed through several attempts. If successful in loading the substituted shared library, the attacker can gain access to the parameters stored within the pod environment, sufficient to control the entire cluster.