Security teams tracking application security, ASPM, and phoenix security have seen a surge of concern around multiple unauthenticated remote code execution flaws (CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, and CVE-2025-1974) in ingress-nginx, since the attack is a Remote Code Execution and likely to be exploited at scale we wanted to cover the key element in this article. These vulnerabilities, collectively dubbed IngressNightmare on for Ingress NGINX Controller, pose a severe cybersecurity risk, with the potential for cluster-wide takeover in Kubernetes deployments that rely on NGINX as a front-end proxy.
Not one vulnerability but a chain of vulnerabilities The vulnerabilities (CVE-2025-24513, CVE-2025-24514, CVE-2025-1097, CVE-2025-1098, and CVE-2025-1974 ), assigned a CVSS score of 9.8
Overview of the Vulnerabilities
CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, and CVE-2025-1974 named IngressNightmare allow attackers to inject and execute malicious configuration directives on NGINX. Researchers at Wiz identified these flaws, highlighting that over 40% of internet-facing Kubernetes clusters utilize ingress-nginx. When leveraged successfully, a threat actor can obtain full access to all stored secrets across the cluster’s namespaces, leading to privilege escalation and data compromise.
CVE-2025-1974 stands out with a CVSS score of 9.8. It exposes a pathway for anyone with network access to the pod interface to exploit configuration injection in the Validating Admission Controller feature. This path bypasses the usual requirement for creating an Ingress object, making cluster takeover achievable without special permissions.
Listen to the Blog:
Threat Actor Identified and Impact
A series of research studies (culminating in IngressNightmare) led to the disclosure and coordinated remediation with ingress-nginx maintainers and the Kubernetes Security Response Committee. Real-world threat actors exploiting these weaknesses gain unauthenticated remote code execution capability, unlocking cluster-wide secrets. Such adversaries can inject crafted Ingress objects or manipulate admission controller traffic to coerce the environment into loading arbitrary shared libraries. The critical severity stems from the substantial privileges assigned to ingress-nginx, which often includes read access to every Secret in the cluster.
To exploit the vulnerability, an attacker needs to perform the following steps:
- Use NGINX Client Body Buffering to upload a shared library to the target pod
- Send an AdmissionReview request to the NGINX admission controller with the
ssl_engine load_moduledirective, causing NGINX to load the previously uploaded shared library - Get the shared library being executed using the file descriptor reference from the
/procfilesystem (in particular, by searching for it in/proc/*/fd/*)
Attack Technique: Configuration Injection and Shared Library Loading
What composes IngressNightmare:
• Annotation Misuse (CVE-2025-1097, CVE-2025-1098, CVE-2025-24514): Threat actors modify relevant fields (auth-url, auth-tls-match-cn, or even the UID) to slip malicious NGINX directives into the config file.
• RCE Escalation (CVE-2025-1974): The controller runs nginx -t on this doctored configuration. Directives like ssl_engine load an attacker-hosted shared library from a disk location, exploiting a race with NGINX’s client body buffer functionality to place payloads into the pod’s file system.
Ransomware Attack Vectors and Vulnerability Percentages for CVE-2025-1974 like
How likely would this be weaponized and used at scale for exploitation and threat actors? Very high, being on the external controller and having access to secrets.
The Phoenix Security 0-day and ransomware threat likelihood puts IngressNightmare vulnerability high on exploitation tactics, indicating a heavy reliance on flaws enabling remote code execution and privilege escalation in ransomware campaigns. Reported percentages include:
• Remote Code Execution: 40.4%
• Privilege Escalation: 16.9%
• Authentication Bypass: 13.6%
Ingress-nginx flaws land squarely in the most favored category for ransomware operators: RCE. This single factor underscores the urgency of a swift remediation strategy, because infiltration at the ingress level can provide an all-in-one route to exfiltrate data, elevate privileges, and distribute ransomware payloads across a cluster.
The more frequent user of this threat type is clop followed by conti and other groups as seen below:
Deep Dive into the Attack Mechanism
The core problem with IngressNightmare lies in how ingress-nginx generates and tests NGINX configurations whenever a new Ingress object appears or a validation request arrives. By manipulating annotations (auth-url, auth-tls-match-cn) or the Ingress UID, malicious directives slip into the temporary NGINX configuration file. When the process runs nginx -t to verify the configuration, it interprets these directives.
Attackers extend the compromise further with the ssl_engine directive, which can load shared libraries at any stage. Combined with NGINX’s client body buffer behavior, a malicious library file is uploaded to the pod’s file system through an open file descriptor. The NGINX configuration test then loads that rogue file, granting the attacker code execution privileges equivalent to the ingress-nginx pod itself.
Credit to wiz research team for discovering this vulnerability
Upload results into Phoenix:
Link to trivi scan: https://github.com/aquasecurity/trivy
Remediation and Defensive Measures for NGNX CVE-2025-1974
1. Immediate Patch ngnx against CVE-2025-1974
• Upgrade to ingress-nginx v1.12.1 or v1.11.5 where all known vulnerabilities are addressed.
• Confirm the version by checking your cluster’s deployment manifests or using Helm repository updates.
2. Restrict Network Access to the Admission Controller:
• Avoid exposing the webhook externally.
• Implement strict network policies that ensure only the Kubernetes API server can contact the admission controller.
3. Disable the Validating Admission Controller if Upgrades Are Delayed:
• For Helm installations, set controller.admissionWebhooks.enabled=false.
• For manual deployments, delete the ingress-nginx-admission ValidatingWebhookConfiguration and remove the –validating-webhook argument from the ingress-nginx-controller container.
4. Re-enable Safeguards Post-Upgrade:
• Switch the Validating Admission Controller back on after patching. It catches errors in Ingress definitions that can otherwise cause instability or unexpected behavior.
5. Enhanced Detection and Monitoring:
• Review cluster logs for suspicious AdmissionReview requests.
• Consider solutions that monitor ingress traffic and runtime anomalies, particularly any load of unexpected shared libraries.
• Verify that secrets are not overexposed through broad role-based access control (RBAC) permissions.
Detecting the Vulnerability CVE-2025-1974 IngressNightmare
First, determine if your clusters are using ingress-nginx. In most cases, you can check this by running kubectl get pods –all-namespaces –selector app.kubernetes.io/name=ingress-nginx with cluster administrator permissions.
If you are using ingress-nginx, make a plan to remediate these vulnerabilities immediately.
The best and easiest remedy is to upgrade to the new patch release of ingress-nginx. All five of today’s vulnerabilities are fixed by installing today’s patches.
If you can’t upgrade right away, you can significantly reduce your risk by turning off the Validating Admission Controller feature of ingress-nginx.
- If you have installed ingress-nginx using Helm
- Reinstall, setting the Helm value controller.admissionWebhooks.enabled=false
- If you have installed ingress-nginx manually
- delete the ValidatingWebhookconfiguration called ingress-nginx-admission
- edit the ingress-nginx-controller Deployment or Daemonset, removing –validating-webhook from the controller container’s argument list
If you turn off the Validating Admission Controller feature as a mitigation for CVE-2025-1974 (IngressNightmare), remember to turn it back on after you upgrade. This feature provides important quality of life improvements for your users, warning them about incorrect Ingress configurations before they can take effect.
Static Analysis of Containers and Build Files for CVE-2025-1974 and IngressNightmare
Dockerfiles and Image Layers: If you can access container build files, check the base image tag or installation commands. For example, a Dockerfile might use FROM nginx:1.21.0 or run apt-get install nginx=1.18.0. These explicitly indicate the NGINX version. Even without the Dockerfile, image metadata and layers can reveal this. Tools like Dive, Skopeo, or docker history can show the base image name/tag or commands used to install NGINX (e.g. an apk add nginx in Alpine) . You can also search the filesystem of the image for the NGINX binary or package info:
• Inspect package manager databases (e.g. dpkg -l | grep nginx or apk info nginx files) to find the installed version.
• Look for the NGINX binary (nginx or nginx.exe) and run nginx -v if possible, or use strings on the binary to find a version string (the binary typically contains a string like “nginx/1.X.Y”).
Image Scanning Tools: Container vulnerability scanners can automatically detect NGINX in images. Tools such as Trivy and Grype parse OS package info and file signatures to list NGINX with its version. For example, scanning an image with Trivy might report an entry for the “nginx” package with an installed version, as shown below :
In this Trivy output, the NGINX package is identified (version 1.18.0) and is flagged with a CVE. Similarly, Syft (SBOM generator) will list NGINX in the software bill of materials. These tools are commonly used in CI pipelines (DevSecOps) to flag outdated or vulnerable NGINX in container builds.
Configuration Files: NGINX configuration files themselves don’t typically contain the version. However, they might hint at a distribution (for example, an /etc/nginx/nginx.conf from Ubuntu vs Alpine differ ) which can imply the NGINX build version. If config files are packaged, they could indicate if it’s NGINX Open Source or a custom build (e.g., references to modules like ngx_http_js_module might suggest NGINX Plus or OpenResty).
Limitations (Static): In multi-stage builds or minimal images, the package metadata might be absent (e.g. if NGINX was copied in). In such cases, scanners might miss it. Trivy and Grype have improved detection (even scanning for known binary signatures ), but a custom-built or stripped binary could evade easy identification. Always ensure the scanner covers “unpackaged” binaries if using a custom NGINX build. If the image uses an OS distro package, note that the apparent version string may not reflect security patches (distributions often backport fixes without changing the version string, which can confuse naive version checks).
Using Vulnerability Scanner Outputs
Security scan reports (from tools like Trivy, Grype, etc.) often explicitly list the NGINX version. In vulnerability reports, NGINX may appear either as an installed package (for image scanners) or as a detected service (for network scanners). For example, an external web scan might show “nginx 1.14.2 (Ubuntu) detected” and enumerate vulnerabilities. Similarly, Trivy/Grype output will list NGINX under vulnerable packages with CVE IDs, as shown in the example above, where CVE-2023-44487 is flagged for a specific NGINX version.
You can input those vulnerabilities automatically into Phoenix with this module :
Tools and Commands:
• Trivy/Grype: trivy image <image>:<tag> or grype <image>:<tag> will produce a table of vulnerabilities. Look for “nginx” in the package name column to find the version.
• Kubernetes-specific: If using Trivy’s K8s integration, running trivy k8s will scan images of running pods (including NGINX ingress controllers) . This helps detect NGINX versions in cluster workloads as part of a DevSecOps routine.
Key Security Takeaways
• RCE on the Frontend: Externally exposed ingress controllers are popular targets due to their visibility. The flaws discussed here place a severe spotlight on remote code execution paths through NGINX.
• Wide Impact: Compromise of the ingress-nginx pod allows secret exfiltration across all namespaces. This scenario is impactful for any business reliant on Kubernetes.
• ASPM and Phoenix Security Integration: Tools and processes for application security posture management benefit from scanning for vulnerable admission controllers. Quick identification and patching reduce the attack surface.
• Ongoing Vigilance: Admission controllers are high-privilege components. Code reviews and strong network boundaries are critical. Additional threat modeling for SSRF or container-escape vectors strengthens overall security posture.
Keeping ingress-nginx fully updated and ensuring minimal exposure of its admission controller block these significant threats. Security practitioners, especially those focused on remediation and multi-cloud cybersecurity, should verify that recent patches are installed to avoid infiltration by adversaries seeking cluster-level control. Regular assessments of RBAC configurations and network boundaries can prevent similar vulnerabilities from escalating into more extensive breaches.
Get on top of your code and container vulnerabilities with Phoenix Security Actionable ASPM
Organizations often face an overwhelming volume of security alerts, including false positives and duplicate vulnerabilities, which can distract from real threats. Traditional tools may overwhelm engineers with lengthy, misaligned lists that fail to reflect business objectives or the risk tolerance of product owners.
Phoenix Security offers a transformative solution through its Actionable Application Security Posture Management (ASPM), powered by AI-based Contextual Quantitative analysis. This innovative approach correlates runtime data with code analysis to deliver a single, prioritized list of vulnerabilities. This list is tailored to the specific needs of engineering teams and aligns with executive goals, reducing noise and focusing efforts on the most critical issues. Why do people talk about Phoenix
• Automated Triage: Phoenix streamlines the triage process using a customizable 4D risk formula, ensuring critical vulnerabilities are addressed promptly by the right teams.
• Contextual Deduplication: Utilizing canary token-based traceability, Phoenix accurately deduplicates and tracks vulnerabilities within application code and deployment environments, allowing teams to concentrate on genuine threats.
• Actionable Threat Intelligence: Phoenix provides real-time insights into vulnerabilities’ exploitability, combining runtime threat intelligence with application security data for precise risk mitigation.
By leveraging Phoenix Security, you not only unravel the potential threats but also take a significant stride in vulnerability management, ensuring your application security remains up to date and focuses on the key vulnerabilities.
Get in control of your Application Security posture and Vulnerability management
Get on top of your code and container vulnerabilities with Phoenix Security Actionable ASPM powered by AI-based Reachability Analysis
Organizations often face an overwhelming volume of security alerts, including false positives and duplicate vulnerabilities, which can distract from real threats. Traditional tools may overwhelm engineers with lengthy, misaligned lists that fail to reflect business objectives or the risk tolerance of product owners.
Phoenix Security offers a transformative solution through its Actionable Application Security Posture Management (ASPM), powered by AI-based Contextual Quantitative analysis. This innovative approach correlates runtime data with code analysis to deliver a single, prioritized list of vulnerabilities. This list is tailored to the specific needs of engineering teams and aligns with executive goals, reducing noise and focusing efforts on the most critical issues.
Why do people talk about Phoenix?
• Automated Triage: Phoenix streamlines the triage process using a customizable 4D risk formula, ensuring critical vulnerabilities are addressed promptly by the right teams.
• Contextual Deduplication with reachability analysis: Utilizing canary token-based traceability for network reachability and static and dynamic runtime reachability, Phoenix accurately deduplicates and tracks vulnerabilities within application code and deployment environments, allowing teams to concentrate on genuine threats.
• Actionable Threat Intelligence: Phoenix provides real-time insights into vulnerabilities’ exploitability, combining runtime threat intelligence with application security data for precise risk mitigation.
By leveraging Phoenix Security, you not only unravel the potential threats but also take a significant stride in vulnerability management, ensuring your application security remains up to date and focuses on the key vulnerabilities.
