Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
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.
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.
Konkret geht es um folgende Versionen des Ingress NGINX Controllers:
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.
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:
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.
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:
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.
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.
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.