CVE-2025-1974 — IngressNightmare (ingress-nginx)

Einleitung

Dieses Dokument bietet eine Untersuchung der Schwachstelle CVE-2025-1974, die die Komponente ingress-nginx (Validating Admission Controller) für Kubernetes betrifft.
CVE-2025-1974 ist eine kritische Schwachstelle (CVSS 3.1 9.8), die eine nicht authentifizierte Remote Code Execution (RCE) im Kontext des ingress-nginx-Prozesses darstellt. Bei Ausführung des Angriffs kann ein Angreifer, der Zugriff auf das Pod-Netzwerk hat (oder eine AdmissionReview an den Validating Webhook senden kann), die Ausführung beliebigen Codes im Pod des Controllers erreichen, was potenziell zur Offenlegung von Secrets und zur Übernahme des Clusters führt.

Ingress-nginx ist einer der am weitesten verbreiteten Ingress-Controller in Kubernetes (Schätzungen gehen von einer Nutzung in Dutzenden von Prozent der Cluster aus), daher ist die praktische Auswirkung der Schwachstelle sehr hoch. Beschreibung, technische Analyse und offizielle Empfehlungen für Fixes wurden von Kubernetes, Forschern von Wiz und mehreren Vendor-Blogs veröffentlicht.

---

Ziel des Berichts

Schrittweise Analyse von CVE-2025-1974 und Erstellung der für einen Write-up erforderlichen Materialien:

1. Sammlung und Strukturierung von Materialien. Offizielle Advisories, Forschungs-Write-ups und Vendor-Analysen sammeln; wichtige technische Details und PoC-Richtungen hervorheben.
2. Verständnis des Wesens der Schwachstelle und ihrer Auswirkungen. Grundursache, Angriffskette und mögliche Folgen (RCE → Offenlegung von Secrets → Cluster-Übernahme) erklären.
3. Bestimmung von CPE und Konfigurationsbedingungen. Auflistung der Versionen/Pakete und Konfigurationen von Kubernetes/ingress-nginx, bei denen die Schwachstelle relevant ist.
4. Empfehlungen für sicheres Testen im Labor und Minimierung des Risikos bei Massenüberprüfungen.

---

⚠️ Haftungsausschluss

Diese Untersuchung dient ausschließlich Bildungs- und ethischen Zwecken und ist auf Test-/kontrollierte Umgebungen ausgerichtet.
Starte unter keinen Umständen Exploits/PoCs gegen fremde Cluster oder öffentlich zugängliche Instanzen ohne schriftliche Genehmigung des Eigentümers. Die Veröffentlichung eines voll funktionsfähigen, „weaponized“ PoC im offenen Raum erhöht das Risiko von Missbrauch erheblich – im öffentlichen Teil sind besser ein Safe-PoC und die Methodik anzugeben. (Offizielle Advisories und Anbieter betonen ebenfalls die Vorsicht bei der Verbreitung von Exploits.)

---

CPE und Konfigurationsbedingungen

• cpe:2.3:a:kubernetes:ingress-nginx_controller:<version> — anfällige Versionen von ingress-nginx (in den Advisories sind konkrete Versionen angegeben; aktualisieren Sie die Werte bei der endgültigen Veröffentlichung).
• Anbieter/Distributionen, die den anfälligen Controller enthalten:
  • RKE2 / Rancher-Distributionen mit ingress-nginx bis zu den genannten Patch-Versionen.
  • Harvester-Versionen, die anfälliges ingress-nginx verwenden (Vendor-KB enthält konkrete betroffene Builds).
  • Benutzerdefinierte Cluster, in denen ingress-nginx separat installiert ist (Helm-Chart/Manifest) – Versionen von Chart/Image prüfen.

Konfigurationsbedingungen, unter denen die Schwachstelle relevant ist:

1. Anfällige Version von ingress-nginx (vor dem in den Advisories genannten Release/Patch). Genaue Versionsnummern siehe NVD und Anbieter-Advisories.
2. Validating Admission Webhook ist außerhalb des Pod-Netzwerks erreichbar – wenn der Webhook von außen zugänglich ist (z. B. öffentlicher Endpunkt, Anbieter hat den Dienst versehentlich weitergeleitet), kann der Exploit remote ausgeführt werden. Wiz und andere Forscher haben zahlreiche Fälle öffentlicher Exposition dokumentiert.
3. Fehlen von NetworkPolicy / Isolierung des Pod-Netzwerks: Wenn ein Angreifer Anfragen von einem beliebigen Pod im Cluster-Netzwerk senden kann (kompromittierter Pod), reicht das für die Ausnutzung aus.
4. Fehlen zusätzlicher Validierungen/ACLs vor dem Admission Controller: zusätzliche Filter/Ingress-Proxy-Authentifizierung können das Risiko verringern.
5. Vorhandensein eines ServiceAccounts mit weitreichenden Rechten und Zugriff auf Secrets im Container von ingress-nginx – standardmäßig montiert der Controller oft einen ServiceAccount mit weitreichenden Rechten; dies erhöht die Auswirkungen bei erfolgreicher Ausnutzung.

---

Details der Schwachstelle

Kurzfassung.
Die Schwachstelle wurde in der Komponente Validating Admission Controller des Controllers Ingress-NGINX entdeckt und hängt damit zusammen, wie diese Komponente temporäre NGINX-Konfigurationen basierend auf eingehenden Ingress / AdmissionReview erstellt und überprüft. Während der Verarbeitung generiert der Controller nginx.conf und führt eine Konfigurationsprüfung (nginx -t) durch. Bei unzureichender Bereinigung der Felder von Ingress/AdmissionReview kann ein Angreifer speziell präparierte Fragmente einfügen, die in die generierte Konfiguration gelangen und letztlich zur Ausführung von Befehlen im Controller-Prozess führen – also zu Remote Code Execution (RCE) im Pod von ingress-nginx.

Wichtigste technische Punkte

• Einstiegspunkt. Eingehende AdmissionReview/Ingress-Objekte, die vom Validating Webhook des Controllers akzeptiert werden, dienen als Ausgangsdaten für die Generierung der NGINX-Konfiguration (einschließlich Annotationsfelder, Backend-Einstellungen usw.).
• Ausnutzungsmechanismus. Ein erstellter bösartiger Ingress oder eine direkte AdmissionReview kann kontrollierte Zeichenfolgen in Vorlagen/Konfigurationsfragmente einschleusen. Bei der Überprüfung/Ladung einer solchen nginx.conf kann der Prüfprozess (nginx -t) und nachfolgende Operationen mit der Konfigurationsdatei zur Ausführung beliebigen Codes, zum Schreiben/Starten von Dateien oder zur Ausführung von Befehlen im Kontext des Controllers führen.
• Erforderliche Bedingungen. Für eine erfolgreiche Ausnutzung sind erforderlich: eine anfällige Version von ingress-nginx; die Möglichkeit, eine AdmissionReview an den Validating Webhook zu senden (Zugriff aus dem Pod-Netzwerk oder direkter Netzwerkzugriff); Fehlen von Ausgleichsmaßnahmen – NetworkPolicy, RBAC-Einschränkungen oder zusätzliche Webhook-Authentifizierung. In einigen Szenarien kann die Einschränkung der Create/Update-Berechtigungen umgangen werden, indem eine manipulierte AdmissionReview direkt an den Webhook gesendet wird.

Warum dies gefährlich ist – Folgen der Ausnutzung

Eine erfolgreiche Ausnutzung ermöglicht die Codeausführung im Container von ingress-nginx, was in der Regel Folgendes erlaubt:

• Abrufen des ServiceAccount-Tokens des Controllers und Zugriff auf die Kubernetes-API;
• Lesen von Secrets und anderen vertraulichen Informationen in zugänglichen Namespaces;
• Erstellen/Ändern von Cluster-Ressourcen und Ausweitung des Zugriffs (Privilegieneskalation, Lateral Movement);
• in einigen Fällen – vollständige Cluster-Übernahme.

Verhaltens- und Erkennungsbeobachtungen

• Bei ordnungsgemäßem Betrieb des Controllers gibt es normalerweise keinen Anfragefluss zum Admission Controller – der Validating Webhook dient als interne Komponente, die innerhalb des Clusters arbeitet. Während der Ausnutzung wird eine Anomalie beobachtet: Auf der Netzwerkkarte (z. B. Luntry) treten eingehende Verbindungen zu ingress-nginx-controller-admission und dem Service ingress-nginx-controller von ungewöhnlichen Quellen auf (in Berichten von Containern wie alpine), was bei normalem Betrieb nicht vorkommen sollte.
• Die Analyse der Netzwerkkarte des Clusters gibt Aufschluss über die Interaktionen zwischen Microservices; wenn man das Deployment ingress-nginx im Namespace auswählt, kann man eingehende/ausgehende Verbindungen sehen. Das Auftreten eingehender Verbindungen zum Admission-Endpunkt zum Zeitpunkt des Angriffs ist ein deutlicher Indikator für eine Kompromittierung.
• Zur Erkennung von Ausnutzungsversuchen ist es nützlich, Folgendes zu überwachen: POST-Anfragen an den Validating Webhook, Erstellung atypischer Ingress-Objekte, Aufrufe von nginx -t und plötzliche Neustarts des Controllers sowie unerwartete Dateischreiboperationen durch den ingress-nginx-Prozess.

Kontext: Was ist der Ingress-Controller NGINX und warum ist er wichtig

Ingress-NGINX ist einer der am weitesten verbreiteten Ingress-Controller in Kubernetes (wird häufig zur Organisation des externen Zugriffs auf Dienste verwendet). Der Controller fungiert als Reverse Proxy: Er nimmt externen Traffic entgegen und leitet ihn basierend auf einer Reihe von Ingress-Regeln an die entsprechenden Services/Pods weiter. Das Projekt Ingress-NGINX erfreut sich großer Beliebtheit und hat einen erheblichen Installationsanteil in internetzugänglichen Clustern.

Ingress-NGINX wird in der Kubernetes-Dokumentation als Referenzbeispiel für einen Ingress-Controller angeführt. Schätzungen zufolge verwenden ein erheblicher Teil der offenen Cluster genau diesen Controller; in einigen Studien wird angegeben, dass etwa 41 % der öffentlich zugänglichen Cluster Ingress-NGINX verwenden. Gerade wegen der weiten Verbreitung und der zentralen Rolle bei der Verkehrslenkung haben Schwachstellen in dieser Komponente eine hohe praktische Auswirkung.

Warum der Validating Webhook ein bequemer Angriffsvektor wird

• Standardmäßig ist der Validating Webhook des Controllers innerhalb des Kubernetes-Netzwerks erreichbar und erfordert oft keine zusätzliche Authentifizierung beim Zugriff auf seine Adresse (z. B. validate.nginx.ingress.kubernetes.io). Dies macht es einfach, von innerhalb des Clusters darauf zuzugreifen.
• Die Kombination aus: weite Verbreitung des Controllers + Netzwerkzugriff + potenziell weitreichende Berechtigungen des ServiceAccounts = kritische Kombination, die einen effektiven Weg zur Kompromittierung bietet.
• In der Praxis ist es nicht schwer, einen „ersten Einstiegspunkt“ in den Cluster zu erhalten: Anwendungen enthalten oft Schwachstellen, die zur Kompromittierung eines einzelnen Containers führen; von diesem Container aus kann der Angreifer dann auf interne Webhooks zugreifen. Darüber hinaus werden ausnutzbare Schwachstellen wie SSRF in Webanwendungen häufig verwendet, um Anfragen innerhalb des Cluster-Netzwerks zu initiieren und solche Webhooks zu nutzen.

Wiederholte Beschreibung der Exploit-Kette (zusammenfassend)

1. Der Angreifer erhält die Möglichkeit, Anfragen in das Pod-Netzwerk zu senden oder direkt auf den Validating Webhook zuzugreifen.
2. Es wird ein speziell manipulierter Ingress / AdmissionReview erstellt, bei dem bestimmte Felder bösartige Zeichenfolgen enthalten, die nicht ordnungsgemäß gefiltert wurden.
3. Der Controller generiert basierend auf diesen Eingabedaten nginx.conf und führt nginx -t / andere Prüfoperationen durch.
4. Die eingefügten Fragmente führen zur Ausführung von Befehlen/Skripten oder zum Schreiben/Starten von Dateien im Kontext des Controller-Prozesses.
5. Nach Erhalt der Ausführung extrahiert der Angreifer das ServiceAccount-Token, greift auf die Kubernetes-API zu und setzt die Bewegung und Eskalation im Cluster fort.

Anmerkungen zur Kompatibilität mit anderen Schwachstellen

Solche Schwachstellen sind besonders gefährlich in Kombination mit anderen Defekten: Ein kompromittierter Pod (oder SSRF in einer öffentlichen Anwendung) + exponierter Validating Webhook bietet eine hohe Wahrscheinlichkeit einer vollständigen Kompromittierung. Daher sollte die Analyse von Vorfällen die Abhängigkeitskette und potenzielle Vektoren berücksichtigen, nicht nur die Version von ingress-nginx.

---