Eine kürzlich offengelegte Schwachstelle in ingress-nginx könnte es authentifizierten Angreifern ermöglichen, Code auszuführen und auf Kubernetes-Secrets in betroffenen Clustern zuzugreifen.
Die Schwachstelle könnte „… zur Ausführung beliebigen Codes im Kontext des ingress-nginx-Controllers und zur Offenlegung von Secrets führen, auf die der Controller zugreifen kann“, sagten die Kubernetes-Forscher.
Die Sicherheitslücke in Ingress-Nginx
Ingress-Controller befinden sich am Rand von Kubernetes-Clustern. Dort verwalten sie eingehenden Datenverkehr und leiten Anfragen an interne Dienste weiter.
Da ingress-nginx häufig mit erweiterten Berechtigungen betrieben wird, können Schwachstellen in dieser Komponente überproportional große Auswirkungen haben.
In vielen Standardbereitstellungen verfügt der ingress-nginx-Controller über die Berechtigung, Secrets im gesamten Cluster zu lesen. Ein einziger erfolgreicher Exploit könnte daher Zugangsdaten, Token oder Konfigurationsdaten offenlegen, die von mehreren Anwendungen verwendet werden.
Die als CVE-2026-24512 erfasste Schwachstelle ist ein Problem durch Konfigurationsinjektion, das mit dem Feld rules.http.paths.path von Kubernetes-Ingress-Ressourcen zusammenhängt.
Eine unzureichende Validierung dieses Feldes ermöglicht es einem Angreifer, speziell präparierte Werte einzuschleusen, die direkt in die von ingress-nginx generierte nginx-Konfiguration eingefügt werden.
Dieses Verhalten widerlegt die Annahme, dass Ingress-Definitionen sicher in eine Serverkonfiguration übersetzt werden.
Ein Angreifer mit der Berechtigung, Ingress-Ressourcen zu erstellen oder zu ändern, kann diese Schwachstelle ausnutzen, um beliebige nginx-Direktiven einzuschleusen.
In der Praxis ermöglicht dies die Ausführung beliebigen Codes im Kontext des ingress-nginx-Controllers. Der Angreifer kann dadurch Befehle innerhalb des Controller-Pods ausführen.
Obwohl eine Authentifizierung erforderlich ist, sind die notwendigen Zugriffsrechte relativ gering. Dadurch steigt das Risiko in Umgebungen, in denen Entwickler oder Servicekonten Ingress-Ressourcen verwalten dürfen.
Die Schwachstelle lässt sich aus der Ferne über das Netzwerk ausnutzen, weist eine geringe Angriffskomplexität auf und erfordert keine Benutzerinteraktion.
Neben der Codeausführung kann eine erfolgreiche Ausnutzung zu unbefugtem Zugriff auf Kubernetes-Secrets führen, die der Controller lesen darf.
Da ingress-nginx standardmäßig häufig clusterweit auf Secrets zugreifen kann, reicht die potenzielle Schadensausbreitung über einen einzelnen Namespace hinaus und kann den gesamten Cluster betreffen.
CVE-2026-24512 betrifft mehrere ingress-nginx-Versionen, darunter alle Versionen vor v1.13.7 und v1.14.3. Die Schwachstelle wurde in den ingress-nginx-Versionen 1.13.7, 1.14.3 und allen späteren Versionen behoben.
Zum Zeitpunkt der Veröffentlichung liegen keine Informationen darüber vor, dass die Schwachstelle aktiv in freier Wildbahn ausgenutzt wird.
Risiken durch Ingress-Schwachstellen reduzieren
Ein Upgrade bleibt die wichtigste Abhilfemaßnahme. Zusätzliche Kontrollen können jedoch während der Verteilung von Patches das Risiko senken und die Sicherheit des Clusters insgesamt verbessern.
Die folgenden Maßnahmen konzentrieren sich darauf, die Angriffsfläche zu reduzieren, Berechtigungen zu beschränken und die Transparenz über Ingress-Aktivitäten zu verbessern.
- Aktualisieren Sie ingress-nginx auf Version 1.13.7, 1.14.3 oder höher vollständig, um die Schwachstelle zu beheben.
- Einen validierenden Admission-Controller bereitstellen, der Ingress-Ressourcen blockiert , die den Pfadtyp ImplementationSpecific verwenden, falls sofortige Upgrades nicht möglich sind.
- Die Berechtigungen zum Erstellen oder Ändern von Ingress-Ressourcen beschränken und den RBAC-Zugriff von ingress-nginx auf die erforderlichen Namespaces und Secrets reduzieren.
- Überwachen Sie Kubernetes-Auditprotokolle und Konfigurationsänderungen von ingress-nginx auf verdächtige oder fehlerhafte Pfadwerte und unerwartete Änderungen.
- Die Schadensausbreitung durch die Anwendung von Netzwerkrichtlinien begrenzen und die ingress-nginx-Bereitstellungen durch Namespace-Isolierung abschotten.
- Zur Laufzeit-Sicherheitsüberwachung verwenden, um anomales Verhalten innerhalb von ingress-nginx-Controller-Pods zu erkennen, etwa unerwartete Prozessausführung oder Dateizugriffe.
- Auf Eindämmung und Wiederherstellung vorbereiten, indem Kubernetes-Auditdaten aufbewahrt werden und regelmäßig Incident-Response-Pläne getestet werden, die Szenarien einer Kompromittierung von Ingress und Controllern abdecken.
Diese Maßnahmen tragen dazu bei, die Schadensausbreitung einer Ingress-Kompromittierung zu begrenzen und die Widerstandsfähigkeit von Kubernetes zu stärken.
Warum Ingress-Sicherheit wichtig ist
Diese Schwachstelle verdeutlicht die Sicherheitsaspekte, die mit hochprivilegierten Kubernetes-Komponenten am Rand des Clusters verbunden sind.
Zeitnahe Upgrades sind zwar wichtig. In Kombination mit strengeren Zugriffskontrollen, einer verbesserten Überwachung und erprobten Reaktionsprozessen können sie jedoch dazu beitragen, die Auswirkungen zu begrenzen.
Die Einbindung der Ingress-Sicherheit in eine umfassendere Resilienzstrategie unterstützt langfristig einen konsequenteren Schutz.
Der Fokus auf die Beschränkung von Privilegien und die Validierung des Zugriffs spiegelt die Kernprinzipien von Zero-Trust.