Ingress NGINX Controller vulnerabilities

Critical Ingress NGINX Controller vulnerabilities disclosed in Kubernetes

On March 24, 2025, four critical Ingress NGINX Controller vulnerabilities were publicly disclosed. These flaws enable unauthenticated remote code execution (RCE), unrestricted access to secrets across all namespaces, and the possibility of full Kubernetes cluster takeover. Each vulnerability resides in the controller’s admission component, a service commonly exposed to the internet without authentication controls.

Ingress NGINX Controller is widely used in production Kubernetes environments as the default ingress implementation. It routes external traffic to internal services and is deployed in over 40% of internet-facing Kubernetes clusters.

Vulnerabilities Overview

CVETitleTypeCVSSRisk
CVE-2025-1974NGINX Configuration Code ExecutionRCE9.8Critical
CVE-2025-1097Auth-TLS-Match-CN Annotation InjectionTemplate Injection9.8Critical
CVE-2025-1098Mirror UID InjectionTemplate Injection9.8Critical
CVE-2025-24514Auth-URL Annotation InjectionTemplate Injection9.8Critical

1. CVE-2025-1974: NGINX Configuration Code Execution

The admission controller validated configurations by generating temporary NGINX config files and executing nginx -t. These temporary files were created directly from ingress object data without proper sandboxing. A crafted ingress object could inject malicious content into the configuration. When processed, arbitrary commands could be executed in the controller’s runtime environment.

Code flow:

tmpfile, err := os.CreateTemp(...)

os.WriteFile(tmpfile.Name(), cfg, ...)

exec.Command(nc.Binary, "-c", cfg, "-t").CombinedOutput()

This logic allowed attackers to trigger execution during config testing. The mitigation was the complete removal of this configuration validation logic in patched versions.

2. CVE-2025-24514: Auth-URL Annotation Injection

Ingress annotations allow customization of NGINX behavior. In this case, unsanitized user input in the auth-url annotation was directly inserted into the NGINX config template.

Vulnerable template line:

set $target {{ $externalAuth.URL }};

This allowed injection of arbitrary directives. The fix applied proper quoting:

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

3. CVE-2025-1097: Auth-TLS-Match-CN Annotation Injection

The auth-tls-match-cn annotation required values starting with CN= and a valid regex. However, these constraints were bypassed, allowing crafted inputs to inject configuration directives.

Vulnerable line:

if ( $ssl_client_s_dn !~ {{ $server.CertificateAuth.MatchCN }} ) {

Fix:

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

4. CVE-2025-1098: Mirror UID Injection

This vulnerability involved injecting malicious input into the mirror directive via the ingress object UID. Since UID is not treated as an annotation, it bypassed regex validation and was directly inserted into the configuration.

Vulnerable line:

mirror {{ $location.Mirror.Source }};

Fix:

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

Exploitation Path

Researchers demonstrated an attack chain combining these vulnerabilities with NGINX’s undocumented ssl_engine directive. This directive can load shared libraries during config parsing. Exploitation involves:

  1. Uploading a shared library payload to a pod using the client_body_buffer feature.
  2. Submitting an AdmissionReview request with injected config.
  3. Triggering ssl_engine to load the library and execute code.

This leads to unauthenticated remote code execution inside the admission controller pod.

Risk Impact

  • No authentication required for exploitation
  • Full access to secrets in all namespaces
  • Remote execution of arbitrary code
  • Potential for lateral movement and full cluster compromise
  • Public exposure of admission controllers confirmed in over 6,500 clusters

Recommended Mitigation

Update to patched versions immediately:

  • v1.12.1
  • v1.11.5

If immediate update is not possible:

  • Restrict network access to the admission controller via Kubernetes Network Policies
  • Disable the admission controller temporarily:
    • Helm:
      controller.admissionWebhooks.enabled=false
    • Manual install:

Remove the ingress-nginx-admission ValidatingWebhookConfiguration
Remove --validating-webhook from the controller’s arguments

Re-enable the admission controller after upgrading to maintain configuration validation functionality.

Operational Recommendations

  • Inventory: Identify clusters using Ingress NGINX Controller and assess exposure
  • Patch: Apply fixed versions in production environments without delay
  • Harden network access: Restrict access to internal controllers and APIs
  • Monitor: Set up detection for unexpected API activity or admission webhook access
  • Investigate: Perform log analysis and memory inspection for signs of compromise

Final Notes

These Ingress NGINX Controller vulnerabilities expose fundamental security gaps in admission controllers and the handling of untrusted input during configuration validation. Mitigating cluster-wide risk in Kubernetes requires secure defaults, strict input sanitization, and proper isolation of internal components.

Leave a Comment

Your email address will not be published. Required fields are marked *