NGINX IngressNightmare: Critical Unauthenticated RCE Vulnerabilities in Kubernetes

NGINX IngressNightmare: Critical Unauthenticated RCE Vulnerabilities in Kubernetes

Over 40% of cloud environments are at risk. A newly disclosed series of vulnerabilities—dubbed IngressNightmare—has been found in the widely used Ingress NGINX Controller for Kubernetes. These flaws, which carry a CVSS v3.1 base score of 9.8, can lead to unauthenticated remote code execution (RCE) and ultimately enable an attacker to take over an entire cluster.

 

What Is Ingress NGINX Controller?

 

Ingress NGINX Controller is one of Kubernetes’ most popular ingress solutions. It acts as a reverse proxy and load balancer, routing external traffic to the proper backend services within your cluster. By design, it translates Kubernetes Ingress objects into NGINX configuration files—a process that is now under intense scrutiny due to this new vulnerability.

 

The Vulnerability in a Nutshell

 

The root cause of IngressNightmare lies in the admission controller component. This controller validates incoming Ingress objects by generating a temporary NGINX configuration and testing it with the nginx -t command. However, due to a lack of proper sanitization, attackers can inject arbitrary configuration directives through manipulated ingress objects. This can trigger the NGINX binary to execute unintended code.

Wiz Research identified four related vulnerabilities:

 

 

Exploitation of these vulnerabilities enables remote attackers to gain unauthorized access to sensitive cluster secrets and escalate privileges, potentially leading to a full cluster takeover.

 

How the Attack Works

 

Configuration Injection via Admission Controller

The admission controller processes Ingress objects to construct an NGINX configuration. Because it accepts these objects over an unauthenticated network endpoint, attackers can craft malicious Ingress resources. In particular:

 

  • Annotation Injection: By exploiting annotations such as auth-url and auth-tls-match-cn, an attacker can insert arbitrary NGINX configuration directives. These annotations are intended for handling authentication logic but—due to unsanitized input—become vectors for injecting harmful code.
  • Mirror UID Injection: The vulnerability also extends to how the controller processes the Ingress object’s UID field, providing an additional injection point that bypasses standard sanitization.

 

From Injection to Remote Code Execution

 

Even though the configuration file is only being tested with nginx -t, certain directives (such as those in the OpenSSL module like ssl_engine) can be abused to load shared libraries from the filesystem. By exploiting NGINX’s client body buffering feature, an attacker might upload a malicious shared library—keeping the file descriptor open long enough to be loaded during configuration testing. In effect, this series of steps transforms a configuration injection into full-blown remote code execution.

 

Checking Your Ingress NGINX Controller Version

 

To determine if your Kubernetes cluster is affected, it is crucial to verify which version of the Ingress NGINX Controller you are using:

Run the following command:

 

        kubectl get pods --namespace <namespace> -l app.kubernetes.io/name=ingress-nginx -o jsonpath='{.items[0].spec.containers[0].image}' 

 

Ensure that your deployment is updated to at least version 1.12.1 or 1.11.5, as these releases include the necessary patches to mitigate IngressNightmare.

 

Illustrative Code Snippets

 

To better understand the technical details, here are a couple of code snippets inspired by the original disclosure:

1. Configuration Validation

The admission controller generates a temporary configuration file and validates it using the NGINX binary:

 

        func (nc NginxCommand) Test(cfg string) ([]byte, error) {    

                return exec.Command(nc.Binary, "-c", cfg, "-t").CombinedOutput() 

        }

 

This snippet demonstrates how the nginx -t command is used to check the validity of the generated configuration. If unsanitized input is injected into this process, it could lead to code execution.

2. Example of Annotation Injection

An example of how the auth-url annotation might be manipulated:

 

        nginx.ingress.kubernetes.io/auth-url: "http://example.com/#; 

        injection_point"

 

When this annotation is processed, the resulting configuration might look like:

 

        proxy_http_version 1.1; 

        set $target http://example.com/#; 

        injection_point 

        proxy_pass $target;

 

Here, the attacker’s injected text (injection_point) is executed as part of the configuration, illustrating the injection mechanism.

 

Mitigation and Detection

 

Cluster administrators must act immediately to reduce the risk:

 

  • Upgrade: The vulnerabilities have been patched in Ingress NGINX Controller versions 1.12.1 and 1.11.5. Updating to these versions is strongly recommended.
  • Restrict Network Access: Ensure that the admission webhook endpoint is not publicly accessible. Enforcing strict network policies to limit access solely to the Kubernetes API Server can drastically reduce the attack surface.
  • Temporary Workarounds: If an immediate upgrade is not feasible, consider disabling the admission controller temporarily:
    • For Helm installations, reinstall with controller.admissionWebhooks.enabled=false.
    • For manual installations, remove the ValidatingWebhookConfiguration named ingress-nginx-admission and adjust the controller’s startup parameters accordingly.
  • Monitor Your Environment: Employ tools that can scan for exposed admission controllers and monitor ingress traffic in real time to quickly detect anomalous activities.

 

How BaseFortify.eu Can Help

 

At BaseFortify.eu, we empower organizations to stay one step ahead of vulnerabilities like IngressNightmare. Our platform allows users to enter their attack surface details, which are then matched with known CVEs using Common Platform Enumerations (CPEs). This enables early detection and proactive risk management. In addition, BaseFortify offers annotated CVE reports that provide clear, actionable insights, and integrated solutions—such as our intelligent A.I. assistant—to help streamline vulnerability management and response. By leveraging BaseFortify, organizations can focus on safeguarding their environments before threats escalate.

 

Final Thoughts

 

IngressNightmare highlights a critical oversight in the security posture of many Kubernetes deployments. The combination of an unauthenticated, elevated-privilege component with an unsanitized configuration generation process presents a dangerous vulnerability. This incident serves as a stark reminder that every component—from admission controllers to configuration testing tools like nginx -t—must be rigorously secured.

By staying informed about such vulnerabilities and applying prompt mitigations, organizations can protect their clusters from severe compromises. With proactive platforms like BaseFortify, early detection and comprehensive vulnerability management are within reach—helping you minimize risk and secure your digital infrastructure.

 

Based on research by Wiz Research. For further technical details, see the original disclosure by Wiz at Wiz Blog.