Ingress-NGINX Remote Code Execution: Your Kubernetes Cluster's Front Door Is Wide Open

If your organization runs Kubernetes—and statistically, there's a good chance it does—pay attention. A chain of vulnerabilities in Ingress-NGINX, one of the most widely deployed ingress controllers in the Kubernetes ecosystem, allows unauthenticated attackers with pod network access to achieve arbitrary code execution on your cluster.

The attack leverages file descriptor injection against the admission controller webhook. Here's the short version: an attacker uploads a malicious shared library to the ingress controller, then brute-forces the admission webhook to find a valid file descriptor pointing to their payload. Once found, the controller loads and executes it. Game over.

The affected versions span from 1.10.0 through 1.11.1—essentially anyone who's updated their ingress-nginx deployment in the past year but hasn't patched for these specific CVEs. A working proof-of-concept exploit is already public on exploit-db, complete with Python code that automates the entire attack chain.

What makes this particularly devastating is the default Kubernetes permission model. In a standard installation, the ingress-nginx controller has access to all Secrets cluster-wide. That means a successful exploit doesn't just compromise the ingress pod—it potentially exposes every secret in your cluster. Database credentials, API keys, TLS certificates, service account tokens: all of it.

The technical details are worth understanding. The admission controller accepts JSON payloads that include configuration paths. By manipulating these paths to point to /proc/[pid]/fd/[fd], an attacker can trick the controller into loading arbitrary shared objects. The exploit keeps a connection open to maintain the file descriptor while simultaneously hammering the admission endpoint to find a valid reference. It's elegant, it's effective, and it works.

The fix is straightforward: upgrade to ingress-nginx v1.11.2 or later. If you can't patch immediately, consider restricting network access to the admission webhook endpoint or disabling the admission controller entirely (though that breaks some functionality). At minimum, audit what secrets your ingress controller can access and whether those permissions are actually necessary.

The broader lesson here is about Kubernetes security posture. Ingress controllers are, by design, the front door to your cluster. They handle external traffic, terminate TLS, and route requests to internal services. Giving them cluster-wide secret access by default is a design choice that prioritizes convenience over security—and vulnerabilities like this show exactly why that tradeoff is dangerous.