Physical Address

304 North Cardinal St.
Dorchester Center, MA 02124

IngressNightmare: Kritische Schwachstelle im Kubernetes Ingress NGINX Controller

Am 24. März 2025 wurde eine neue Sicherheitswarnung veröffentlicht, die viele Kubernetes-Admins aufhorchen lässt. Betroffen ist der weit verbreitete Ingress NGINX Controller – eine Komponente, die in vielen Clustern als Reverse Proxy und Load Balancer eingesetzt wird. Das Problem: Eine kritische Schwachstelle ermöglicht es Angreifern, aus der Ferne Schadcode auszuführen und im schlimmsten Fall die vollständige Kontrolle über das Cluster zu übernehmen.

Die Sicherheitslücke mit der Kennung CVE-2025-1974 wurde mit einem CVSS-Score von 9.8 bewertet – das ist fast das Maximum und bedeutet: höchste Kritikalität.

Was genau ist passiert?

Insgesamt wurden fünf Schwachstellen bekannt gegeben, von denen vier Remote Code Execution ermöglichen – also die Ausführung von Code durch Angreifer, ohne dass diese direkten Zugriff auf das System haben. Eine davon sticht besonders hervor: CVE-2025-1974. Die anderen drei (CVE-2025-1097, -1098 und -24514) liegen ebenfalls im kritischen Bereich mit CVSS 8.8. Eine weitere Lücke (CVE-2025-24513) kann für Denial-of-Service-Angriffe ausgenutzt werden.

Veröffentlicht wurden die Details unter anderem vom Sicherheitsunternehmen Wiz, das den Vorfall als „IngressNightmare“ bezeichnet – und das durchaus mit gutem Grund.

Wer ist betroffen?

Konkret geht es um folgende Versionen des Ingress NGINX Controllers:

  • Alle Versionen vor v1.11.0
  • Versionen v1.11.0 bis einschließlich v1.11.4
  • v1.12.0

Besonders kritisch ist die Situation für Betreiber, deren Admission Controller öffentlich im Internet erreichbar ist – was laut Analyse mehr als 1000 Systeme in Deutschland betrifft.

Warum ist das so gefährlich?

Selbst wenn der Admission Controller nicht direkt von außen erreichbar ist, kann ein kompromittierter Container oder eine Schwachstelle in einem anderen Teil des Clusters ausreichen, um die Lücke auszunutzen. Angreifer könnten beispielsweise:

  • Schwachstellen in Container-Images oder Kubernetes-Diensten ausnutzen
  • Schwache Zugangsdaten erraten
  • Fehlkonfigurationen verwenden, um Zugriff zu erlangen

Kommt hinzu: Kubernetes-Cluster aktualisieren sich in der Regel nicht automatisch. Das bedeutet, es liegt in der Verantwortung der Administratoren, Sicherheitslücken wie diese zeitnah zu schließen.

Was ist jetzt zu tun?

Wer Kubernetes produktiv einsetzt, sollte möglichst schnell prüfen, ob der Ingress NGINX Controller im Einsatz ist und ob eine verwundbare Version genutzt wird. Das geht zum Beispiel mit folgendem Befehl:

kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

Ist das der Fall, sollte zügig ein Update auf eine der folgenden Versionen erfolgen:

  • v1.11.5 oder höher
  • v1.12.1 oder höher

Darüber hinaus ist es wichtig sicherzustellen, dass der Admission Controller (bzw. Validating Webhook) nicht aus dem Internet erreichbar ist. Wer möchte, kann zur Überprüfung ein öffentlich verfügbares Nuclei-Template nutzen.

Falls ein Update kurzfristig nicht möglich ist, empfiehlt es sich, den Admission Controller vorübergehend zu deaktivieren und den Clusterzugang streng zu limitieren.

Wie lässt sich eine Kompromittierung erkennen?

Aktuell gibt es keine spezifischen Indikatoren, die auf einen bereits erfolgten Angriff hinweisen. Allerdings sollten Admins alle eingehenden Verbindungen zum Port 8443 im Auge behalten – dieser Port ist für den Admission Controller zuständig. Im Normalfall sollten hier nur autorisierte Kubernetes-Komponenten (wie der API Server) kommunizieren.

Verdächtige Zugriffe von anderen IP-Adressen könnten auf eine Fehlkonfiguration oder sogar einen Angriff hindeuten.

Weiterführende Infos

Fazit

Diese Schwachstellen zeigen einmal mehr, wie wichtig ein sauberes Patch-Management und eine sorgfältige Absicherung von Kubernetes-Komponenten sind. Wer jetzt nicht reagiert, geht ein unnötig hohes Risiko ein – denn die Veröffentlichung technischer Details und möglicher Exploits dürfte nur eine Frage der Zeit sein.

Wer seine Cluster nicht nur verwalten, sondern auch wirklich schützen will, sollte handeln – besser gestern als heute.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

WordPress Appliance - Powered by TurnKey Linux