IngressNightmare (CVE-2025-1974): Vulnerability Deep Dive and Gateway API Migration Guide

Sat, 27 Dec 2025 10:00:00 +0800

The recently disclosed “IngressNightmare” vulnerability in Ingress-NGINX has once again thrust nginx-ingress into the spotlight, serving as a stark warning for clusters still relying on traditional Ingress.

Below is a technical review focused on engineering practice, covering the vulnerability recap, risk analysis, short-term fixes, how to leverage this as an opportunity to migrate to Gateway API, and a comparison of pros and cons before and after migration.

Vulnerability Brief: IngressNightmare (CVE‑2025‑1974)

Severity: In March 2025, researchers disclosed a set of high-severity vulnerabilities in the Ingress-NGINX controller, collectively known as “IngressNightmare.” Among them, CVE‑2025‑1974 has a CVSS score of 9.8, rated as “Critical” by the official team and multiple security vendors, affecting a vast number of Kubernetes clusters.
Root Cause: The core issue lies in the Validating Admission Webhook. When validating an Ingress object, the controller generates an NGINX configuration based on the object and its annotations, then uses nginx -t for validation. During this process, insufficient filtering of annotations and configuration fragments allows attackers to inject arbitrary NGINX directives, ultimately leading to Remote Code Execution (RCE) on the controller Pod.
Low Attack Barrier: An attacker only needs access to the admission webhook within the Pod network (many clusters even expose it to the public internet) to trigger the vulnerability via unauthenticated requests. This is an unauthenticated RCE, highly susceptible to mass exploitation by worms or automated attack tools.
Vulnerability Chain: The same disclosure includes several other high-severity injection vulnerabilities (e.g., CVE‑2025‑24514, CVE‑2025‑1097, CVE‑2025‑1098), collectively forming the IngressNightmare vulnerability chain, with an attack surface far exceeding a single CVE.

Risk and Impact: From NGINX to Full Cluster Takeover

Sensitive Information Leakage: Once RCE is achieved within the ingress-nginx controller container, attackers can read all Kubernetes Secrets mounted to that Pod. Crucially, the NGINX Ingress Controller typically has extremely high privileges (ClusterRole), requiring it to read Secrets from all namespaces in the cluster to obtain TLS certificates. This means the consequence of RCE is not just the current Namespace, but the complete leakage of all cluster certificates and credentials.
Traffic Hijacking and Tampering: The controller usually has read and write permissions for Ingress resources in the cluster. Combined with RCE, attackers can further tamper with routing, transparently forwarding user traffic to attacker-controlled backends for man-in-the-middle attacks or data theft.
“One Hole to Rule the Cloud”: Practical tests by multiple security vendors show that in clusters with loose default network policies, an attacker only needs execution permissions on any Pod to laterally access the admission webhook, thereby escalating to cluster-level control.

Short-Term Remediation: Patch First, Rebuild Later

Before discussing Gateway API migration, all clusters still running ingress-nginx need to take two immediate actions:

CVE-2025-1974 - Tag - Shengxu · Cloud Architecture & DevOps

IngressNightmare (CVE-2025-1974): Vulnerability Deep Dive and Gateway API Migration Guide

Vulnerability Brief: IngressNightmare (CVE‑2025‑1974)

Risk and Impact: From NGINX to Full Cluster Takeover

Short-Term Remediation: Patch First, Rebuild Later