Ingress-NGINX has an admission controller used to validate Ingress objects. This is essentially a webserver accessible without any authentication. How does it work? The Ingress object gets converted to an @NGINX configuration file, which then gets validated by the NGINX binary:

Our request can only contain some fixed NGINX directives. But what if we just… escape our context?🤔 With CRLF injection, we inserted arbitrary configs into the file. But our config is never executed, only tested. So can we cause NGINX to execute code during syntax validation?

After digging through hundreds of NGINX directives, we found our winner: OpenSSL 🔒 The `ssl_engine` directive allows us to load arbitrary Shared Objects – jackpot! 🎰 Only one problem remains – how can we upload an SO file to the disk?

Using NGINX's "client body buffering" feature, we send a large HTTP request containing our SO payload. Since the body is large, NGINX will buffer it into a tempfile on disk. With ProcFS tricks and quick brute-force, we can reliably load our file into the process! RCE achieved 🥳

Conveniently, Ingress-NGINX has a very privileged Service Account in K8s. How privileged? Privileged enough to access ALL SECRETS across ALL NAMESPACES 🤯

We worked closely together with @KubernetesIO maintainers to help mitigate this attack surface. With a 9.8 CVSS score, these are tracked as: CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, and CVE-2025-1974. We thank the K8s team for their cooperation on this effort! 🙏

For more details about these vulnerabilities, check out our full technical blog @wiz_io 👇👇👇 https://www.wiz.io/blog/ingres...