Kubernetes

IngressNightmare Vulnerabilities in Kubernetes NGINX Controller

David Wilson

David Wilson

— 3 min read

Introduction

On March 24, 2025, a set of critical security vulnerabilities known collectively as "IngressNightmare" were disclosed in the Ingress NGINX Controller for Kubernetes. These vulnerabilities (CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, and CVE-2025-1974) affect the admission controller component and could allow attackers to execute code remotely without authentication.

This technical analysis examines the vulnerabilities, their impact, and remediation strategies for affected organizations.

Background on Ingress NGINX Controller

Ingress NGINX Controller is one of the most widely used ingress controllers for Kubernetes environments with over 18,000 GitHub stars. It functions as a reverse proxy that manages external access to services within a Kubernetes cluster, routing incoming traffic based on defined rules.

Research indicates approximately 43% of cloud environments may be affected by these vulnerabilities, with an estimated 6,500 clusters exposing vulnerable controllers to the public internet.

The Vulnerable Component

The vulnerabilities are located within the admission controller of Ingress NGINX. Admission controllers in Kubernetes validate and can modify resources before they're stored in etcd and processed by the Kubernetes API server.

The Ingress NGINX admission controller follows a specific process to validate ingress objects:

  1. It creates an NGINX configuration based on the incoming ingress object
  2. It runs the NGINX binary to validate this configuration

This validation method became the attack vector for the IngressNightmare vulnerabilities.

Technical Analysis

CVE-2025-1974: Configuration Validation RCE

The most severe vulnerability in the set allows for remote code execution through the configuration validation process. The issue stems from the lack of proper sandboxing when validating NGINX configurations.

When validating an ingress object, the controller:

  • Generates a temporary NGINX configuration file
  • Executes the NGINX binary to validate the configuration

Without adequate sandboxing, an attacker could submit an ingress object that would generate an NGINX configuration with malicious code that executes during validation.

The Kubernetes team addressed this vulnerability by removing the validation step entirely:

/* Deactivated to mitigate CVE-2025-1974
// TODO: Implement sandboxing so this test can be done safely
err = n.testTemplate(content)
if err != nil {
    n.metricCollector.IncCheckErrorCount(ing.ObjectMeta.Namespace, ing.Name)
    return err
}
*/

The commented code shows the original implementation that was vulnerable. The team plans to eventually restore this functionality with proper sandboxing.

Template Injection Vulnerabilities

The remaining vulnerabilities relate to template injection in the NGINX configuration:

CVE-2025-1097: Authentication URL Injection

User-supplied authentication URLs were being inserted into NGINX templates without proper quoting:

- set $target {{ $externalAuth.URL }};
+ set $target {{ $externalAuth.URL | quote }};

The fix adds proper quoting to prevent arbitrary NGINX configuration directives from being injected.

CVE-2025-1098: Mirror Source Injection

Mirror sources had a similar quoting vulnerability:

- mirror {{ $location.Mirror.Source }};
+ mirror {{ $location.Mirror.Source | quote }};

Path Traversal in Auth File Names

Another vulnerability allowed for path traversal through authentication file names:

// Ensure password file name does not contain any path traversal characters.
if a.authDirectory != filepath.Dir(passFilePath) || passFileName != filepath.Base(passFilePath) {
    return nil, ing_errors.LocationDeniedError{
        Reason: fmt.Errorf("invalid password file name: %s", passFileName),
    }
}

This check prevents directory traversal attacks via crafted file names.

Certificate DN Matching Injection

A similar injection vulnerability existed in certificate DN matching:

- if ( $ssl_client_s_dn !~ {{ $server.CertificateAuth.MatchCN }} ) {
+ if ( $ssl_client_s_dn !~ {{ $server.CertificateAuth.MatchCN | quote }} ) {

Exploitation Path

The attack sequence for exploiting these vulnerabilities follows this pattern:

  1. An attacker submits a specially crafted ingress object to the admission controller
  2. The controller processes the object and generates an NGINX configuration with injected code
  3. The NGINX binary executes this code during validation
  4. The code runs with the privileges of the Ingress NGINX Controller pod
  5. With these privileges, the attacker can access secrets across namespaces
  6. These secrets could potentially be used for further privilege escalation

Impact Assessment

The IngressNightmare vulnerabilities have been assigned a CVSS v3.1 base score of 9.8 (Critical). This high severity rating is based on:

  • No authentication required for exploitation
  • Potential for remote exploitation
  • Ability to execute arbitrary code
  • Access to secrets across namespaces
  • Potential for significant cluster access

Remediation

Update to Patched Versions

Organizations should update to patched versions as soon as possible:

  • Ingress NGINX Controller version 1.12.1
  • Ingress NGINX Controller version 1.11.5

Disclosure Timeline

The research team followed responsible disclosure practices:

  • December 31, 2024 – Initial report of CVE-2025-1974 and CVE-2025-24514
  • January 2-21, 2025 – Additional vulnerabilities reported and fix bypass issues identified
  • February 7-20, 2025 – Kubernetes released internal patches
  • March 10, 2025 – Kubernetes sent embargo notifications
  • March 24, 2025 – Public disclosure

Conclusion

The IngressNightmare vulnerabilities represent a significant security concern for organizations using the Ingress NGINX Controller in their Kubernetes environments. The combination of unauthenticated access, code execution capabilities, and access to sensitive cluster resources makes addressing these vulnerabilities a priority.

This vulnerability chain serves as a reminder of the importance of implementing proper input sanitization, sandboxing, and network security controls in containerized environments. Organizations should prioritize updating to patched versions and implement the recommended security practices to protect their Kubernetes deployments.

Read more