CVE-2025-1974 - NGINX Ingress Controller

Abstract

A critical vulnerability discovered in the NGINX Ingress Controller for Kubernetes. The vulnerability allows attackers to inject arbitrary directives into the NGINX configuration through a race condition, potentially leading to remote code execution. This research presents the technical details of the vulnerability, the exploitation path, and the mitigations implemented to remediate the issue.

Technical Analysis

Root Cause

Basically the issue exists in the NGINX Ingress Controller's configuration validation mechanism. When processing Ingress resources, the controller generates a new NGINX configuration and validates it using nginx -t. This validation occurs in an insecure context, allowing arbitrary configuration directives to be injected and executed during the test phase.

Basically from this AdmissionReview request

---snip---
{'name': 'xxx', 'namespace': 'default', 'creationTimestamp': None, 'annotations': {'nginx.ingress.kubernetes.io/auth-url': 'http://example.com/#;}}}\n\nssl_engine /proc/1/fd/1;\n\n'}

to nginx conf that will load our so

		---snip--	
		# Pass the extracted client certificate to the auth provider
			
		proxy_http_version 1.1;
		set $target http://example.com/#;}}}
			
		ssl_engine /proc/43/fd/96;
		proxy_pass $target;
		}

Attack

We have two primary components:

1. Configuration Directive Injection: The ability to inject arbitrary NGINX directives through Kubernetes Ingress resources
2. File Upload Mechanism: NGINX's behavior of storing HTTP request bodies as temporary files when they exceed a certain size threshold

Exploitation Path

The full exploitation chain consists of the following steps:

1. Directive Injection:

   • Attacker creates or modifies an Ingress resource with malicious configuration directives
   • The controller processes this resource and generates a new NGINX configuration
   • The ssl_engine directive is particularly valuable as it can be placed anywhere in the configuration

2. File upload:

   • Attacker sends an HTTP request with a body larger than 8KB (the default threshold)
   • NGINX saves this request body to a temporary file on the filesystem
   • Although NGINX immediately deletes the file after processing, it maintains an open file descriptor

3. Race Condition Exploitation:

   • By manipulating the Content-Length header to be larger than the actual content, the attacker creates a time window
   • During this window, the file descriptor remains open but the file is deleted from the filesystem
   • The attacker must identify the correct PID and file descriptor in /proc/{PID}/fd/ to access the payload

4. Code Execution:

   • The injected ssl_engine directive loads the attacker's shared library from the procfs path
   • The shared library contains malicious code that executes when loaded
   • This execution happens with the privileges of the NGINX process

Code Analysis

Changes in internal/ingress/controller/controller.go

index 652a80e498..5a263551ef 100644
--- a/internal/ingress/controller/controller.go
+++ b/internal/ingress/controller/controller.go
@@ -420,11 +420,15 @@ func (n *NGINXController) CheckIngress(ing *networking.Ingress) error {
        return err
    }

+   /* 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
    }
+   */
+
    n.metricCollector.IncCheckCount(ing.ObjectMeta.Namespace, ing.Name)
    endCheck := time.Now().UnixNano() / 1000000
    n.metricCollector.SetAdmissionMetrics(

Changes in internal/ingress/controller/controller_test.go

index 9d3fea4708..3b7a3c4eb2 100644
--- a/internal/ingress/controller/controller_test.go
+++ b/internal/ingress/controller/controller_test.go
@@ -250,6 +250,8 @@ func TestCheckIngress(t *testing.T) {
            }
        })

+       /* Deactivated to mitigate CVE-2025-1974
+       // TODO: Implement sandboxing so this test can be done safely
        t.Run("When nginx test returns an error", func(t *testing.T) {
            nginx.command = testNginxTestCommand{
                t:        t,
@@ -261,6 +263,7 @@ func TestCheckIngress(t *testing.T) {
                t.Errorf("with a new ingress with an error, an error should be returned")
            }
        })
+       */
 
        t.Run("When the default annotation prefix is used despite an override", func(t *testing.T) {
            defer func() {

Changes in test/e2e/admission/admission.go

index 873e6719da..49534620f2 100644
--- a/test/e2e/admission/admission.go
+++ b/test/e2e/admission/admission.go
@@ -99,6 +99,8 @@ var _ = framework.IngressNginxDescribeSerial("[Admission] admission controller",
        assert.NotNil(ginkgo.GinkgoT(), err, "creating an ingress with invalid path should return an error")
    })

+   /* Deactivated to mitigate CVE-2025-1974
+   // TODO: Implement sandboxing so this test can be done safely
    ginkgo.It("should return an error if there is an error validating the ingress definition", func() {
        disableSnippet := f.AllowSnippetConfiguration()
        defer disableSnippet()
@@ -112,6 +114,7 @@ var _ = framework.IngressNginxDescribeSerial("[Admission] admission controller",
        _, err := f.KubeClientSet.NetworkingV1().Ingresses(f.Namespace).Create(context.TODO(), firstIngress, metav1.CreateOptions{})
        assert.NotNil(ginkgo.GinkgoT(), err, "creating an ingress with invalid configuration should return an error")
    })
+   */
 
    ginkgo.It("should return an error if there is an invalid value in some annotation", func() {
        host := admissionTestHost

the most important thing we can notice here is that The directive injection vulnerability is mitigated by commenting out the n.testTemplate(content) call, which executes the configuration test.

My Poc

https://github.com/zwxxb/CVE-2025-1974