Kubernetes Sicherheitslücke kritisch: IngressNightmare im Krankenhaus-Umfeld

Anfang 2025 hat die Kubernetes-Community eine der schwerwiegendsten Sicherheitslücken der jüngeren Geschichte veröffentlicht: Unter dem Namen „IngressNightmare" wurden fünf Schwachstellen im Ingress NGINX Controller bekannt, darunter eine mit dem CVSS-Score 9.8 als „kritisch" eingestufte Lücke (CVE-2025-1974). Für Krankenhäuser und Kliniken, die containerbasierte Infrastruktur betreiben, ist diese Kubernetes Sicherheitslücke kritisch – nicht nur technisch, sondern auch regulatorisch. Eine vollständige Clusterübernahme durch externe Angreifer wäre in einer klinischen Umgebung ein Worst-Case-Szenario mit direktem Patientenschutz-Bezug.

Dieser Artikel gibt IT-Sicherheitsverantwortlichen in Gesundheitseinrichtungen eine strukturierte Einordnung: Was ist bekannt, welche Systeme sind betroffen, welche Sofortmaßnahmen sind erforderlich – und welche regulatorischen Pflichten entstehen im deutschen Gesundheitswesen.

Was ist IngressNightmare – und warum trifft es den Gesundheitssektor hart?

Der Ingress NGINX Controller ist eine der meistgenutzten Komponenten in Kubernetes-Clustern. Er fungiert als Reverse Proxy und Load Balancer, der externen HTTP(S)-Traffic auf interne Services weiterleitet. Wer Kubernetes in Produktion betreibt – ob für Patientenportale, Labor-Middleware, KIS-Integrationen oder Cloud-native Applikationen –, setzt in vielen Fällen genau diesen Controller ein.

Am 24. März 2025 veröffentlichte das Kubernetes-Projekt Advisories zu fünf Schwachstellen in diesem Controller. Das IT-Sicherheitsunternehmen Wiz, das die Lücken entdeckt hatte, fasste den Sachverhalt unter dem Namen „IngressNightmare" zusammen. Der Begriff ist programmatisch: Vier der fünf Schwachstellen ermöglichen Remote Code Execution (RCE), also die unautorisierte Codeausführung aus der Ferne ohne vorherige Authentifizierung.

Das BSI stufte den Vorfall mit Kritikalität 2 (auf seiner 4-stufigen Skala) ein und veröffentlichte am 25. März 2025 eine Cybersicherheitswarnung (2025-230373-1032).

Die betroffenen CVEs im Überblick:

CVE	CVSS 3.1	Einstufung	Art
CVE-2025-1974	9.8	Kritisch	RCE, unauthentifiziert
CVE-2025-1097	8.8	Hoch	RCE
CVE-2025-1098	8.8	Hoch	RCE
CVE-2025-24514	8.8	Hoch	RCE
(fünfte CVE)	–	Mittel	Weitere Schwachstelle

Betroffene Versionen: - Alle Versionen < v1.11.0 - v1.11.0 bis v1.11.4 - v1.12.0

Zum Zeitpunkt der BSI-Warnung war keine aktive Ausnutzung bekannt. Das bedeutet jedoch nicht, dass keine Angriffe stattgefunden haben – Kubernetes-Umgebungen sind aufgrund ihrer Komplexität häufig forensisch schwer zu überwachen.

Im Gesundheitswesen ist das Schadenspotenzial besonders hoch: Ein Angreifer, der das gesamte Cluster übernimmt, erhält potenziell Zugriff auf Patientendaten, klinische Systeme, Schnittstellen zu Medizingeräten und Backup-Infrastruktur. Die Kombination aus Datenschutz (DSGVO, BDSG), Verfügbarkeitsanforderungen und klinischer Kritikalität macht einen solchen Angriff zu einem sektorspezifischen Hochrisiko-Event.

Technische Ursachen: Wie die Schwachstellen funktionieren

Das Verständnis der Angriffslogik ist essenziell, um Schutzmaßnahmen richtig zu priorisieren. Laut Wiz-Analyse liegt die Hauptursache in der Art, wie der Ingress NGINX Controller Annotationen und Konfigurationsparameter verarbeitet, die über Kubernetes-Ingress-Ressourcen eingeschleust werden können.

CVE-2025-1974 – die kritischste Lücke:

Diese Schwachstelle erlaubt es einem netzwerknahen, nicht authentifizierten Angreifer, über den Admission-Webhook-Endpunkt des Controllers beliebigen Code auszuführen. Der Admission Webhook ist eine Kubernetes-interne Schnittstelle, über die der Controller Ressourcen validiert, bevor sie im Cluster angelegt werden. Ist dieser Endpunkt erreichbar – was in fehlkonfigurierten oder offenen Umgebungen der Fall sein kann –, genügt eine manipulierte HTTP-Anfrage, um Schadcode einzuschleusen.

Die drei weiteren RCE-Lücken (CVE-2025-1097, CVE-2025-1098, CVE-2025-24514) bauen auf ähnlichen Schwächen in der Verarbeitung von NGINX-Konfigurationsdirektiven auf, die über Ingress-Annotationen injiziert werden können. Die sogenannte „Annotation Injection" ist ein bekanntes Angriffsmuster, das hier durch mangelnde Eingabevalidierung ausnutzbar wurde.

Angriffskettenszenarien im Klinikkontext:

Ein realistisches Angriffsszenario in einer Krankenhausumgebung könnte so aussehen:

Angreifer erlangt Netzwerkzugang (z.B. über kompromittiertes Endgerät, VPN-Credential oder exponiertes Management-Interface)
Angreifer sendet manipulierten Request an den Admission Webhook
RCE im Controller-Pod → Privileged Execution im Cluster-Kontext
Lateral Movement auf andere Namespaces und Service-Accounts
Zugriff auf Secrets, ConfigMaps, persistente Volumes – potenziell inklusive Datenbankverbindungen zu KIS, LIS oder RIS

Ein solcher Angriffspfad ist in wenigen Minuten automatisierbar. Bestehende Exploit-Frameworks werden nach Bekanntwerden von CVSS-9.8-Lücken typischerweise innerhalb von 24–72 Stunden aktualisiert.

Sofortmaßnahmen: Was jetzt zu tun ist

Die wichtigste Maßnahme ist eindeutig: Patchen auf eine nicht betroffene Version. Das Kubernetes-Projekt hat mit v1.11.5 und v1.12.1 (bzw. v1.13.0 für aktuelle Deployments) korrigierte Versionen veröffentlicht.

Schritt-für-Schritt-Vorgehen für Klinik-IT-Teams:

1. Bestandsaufnahme

Identifizieren Sie alle Kubernetes-Cluster in Ihrer Umgebung – auch solche in DMZ, Dev/Test-Umgebungen oder bei Managed-Service-Providern:

# Version des Ingress NGINX Controllers prüfen
kubectl get pods -n ingress-nginx -o jsonpath='{.items[*].spec.containers[*].image}'

Überprüfen Sie zusätzlich, ob der Admission Webhook aktiv und potenziell exponiert ist:

kubectl get validatingwebhookconfigurations | grep nginx

2. Netzwerkseitige Mitigation (als Sofortmaßnahme bis zum Patch)

Falls ein sofortiger Patch nicht möglich ist (z.B. aufgrund von Produktivbetrieb oder Change-Management-Prozessen):

Admission Webhook deaktivieren, sofern er nicht zwingend benötigt wird
Zugriff auf den Webhook-Port (typisch: 8443) durch Netzwerkpolicies oder externe Firewalling einschränken
Egress-Traffic aus dem ingress-nginx-Namespace limitieren
Network Policies so konfigurieren, dass nur der Kubernetes API-Server den Webhook erreichen kann

3. Patch einspielen

# Beispiel für Helm-basiertes Upgrade
helm upgrade ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --set controller.image.tag="v1.12.1"

Bei Managed-Kubernetes-Diensten (z.B. AKS, GKE, EKS mit Add-ons) prüfen Sie, ob der Anbieter automatische Updates anbietet oder ein manuelles Upgrade erforderlich ist.

4. Überprüfung nach dem Patch

Alle RBAC-Bindings im ingress-nginx-Namespace auf ungewöhnliche Service-Accounts prüfen
Audit-Logs auf auffällige API-Requests gegen den Admission Webhook analysieren (Zeitraum: mindestens 90 Tage rückwirkend, sofern verfügbar)
Container-Runtime-Logs auf unerwartete Prozessausführungen im Controller-Pod sichten

5. Langfristige Härtung

Ingress NGINX Controller in einem dedizierten Namespace mit minimalen RBAC-Rechten betreiben
Pod Security Standards (PSS) auf „Restricted" oder mindestens „Baseline" setzen
Network Policies als Standard für alle Namespaces einführen
Admission-Controller-Logs in SIEM integrieren

Regulatorische Pflichten im deutschen Gesundheitswesen

Für Krankenhäuser in Deutschland entstehen aus dieser Kubernetes Sicherheitslücke kritisch zu bewertende Compliance-Fragen – unabhängig davon, ob ein Angriff stattgefunden hat.

Meldepflichten nach BSIG und NIS2UmsuCG

Seit dem Inkrafttreten des NIS2-Umsetzungsgesetzes (NIS2UmsuCG) gelten für Einrichtungen des Gesundheitssektors, die als „wichtige" oder „besonders wichtige" Einrichtung eingestuft sind, verschärfte Anforderungen. Krankenhäuser ab einer bestimmten Größe fallen typischerweise unter diese Kategorien.

Nach §32 BSIG (in der durch das NIS2UmsuCG geänderten Fassung) müssen erhebliche Sicherheitsvorfälle dem BSI gemeldet werden. Eine erheblicher Sicherheitsvorfall liegt unter anderem dann vor, wenn:

die Verfügbarkeit, Integrität oder Vertraulichkeit von Systemen beeinträchtigt ist, oder
ein erheblicher Schaden eingetreten ist oder einzutreten droht.

Wichtig: Das bloße Vorhandensein einer ungepatchten kritischen Schwachstelle in Produktivsystemen begründet noch keine Meldepflicht, kann aber im Schadensfall als Versäumnis gewertet werden. Wenn jedoch Hinweise auf aktive Ausnutzung vorliegen (z.B. unerwartete Prozesse, laterale Bewegungen, Datenzugriffe), greift die Meldepflicht sofort.

Meldung an: BSI über die offizielle Meldeplattform, im Gesundheitsbereich ggf. auch an das zuständige Landesgesundheitsamt.

§391 SGB V – IT-Sicherheit in Krankenhäusern

Nach §391 SGB V sind Krankenhäuser verpflichtet, angemessene technische und organisatorische Maßnahmen zur IT-Sicherheit zu treffen. Als Referenzrahmen gilt der Branchenspezifische Sicherheitsstandard (B3S) Krankenhaus, der Anforderungen an Patch-Management, Schwachstellenmanagement und den Umgang mit kritischen Sicherheitslücken enthält.

Eine ungepatchte CVSS-9.8-Schwachstelle in produktiv genutzter Infrastruktur ist im Rahmen eines B3S-Audits oder einer BSI-Prüfung als erhebliches Defizit zu werten. Krankenhäuser, die dem KRITIS-Regime unterliegen (Schwellenwert: 30.000 vollstationäre Fälle/Jahr), müssen zudem Nachweise über ihr Patch-Management-Verfahren erbringen.

DSGVO und BDSG – Meldepflicht bei Datenpanne

Sollte die Schwachstelle ausgenutzt worden sein und zu einem unbefugten Zugriff auf personenbezogene Daten (insbesondere Gesundheitsdaten nach Art. 9 DSGVO) geführt haben, greift die Meldepflicht nach Art. 33 DSGVO: Meldung an die zuständige Datenschutzaufsichtsbehörde innerhalb von 72 Stunden nach Bekanntwerden.

Hinweis: Die Einordnung konkreter Vorfälle als meldepflichtige Datenpanne erfordert rechtliche Prüfung. Wenden Sie sich für rechtliche Beratung an einen spezialisierten Rechtsanwalt.

ISO 27001 / ISO 27799 – Anforderungen an Schwachstellenmanagement

Krankenhäuser mit ISO-27001-Zertifizierung sind über Anhang A, Maßnahme 8.8 (Management technischer Schwachstellen) verpflichtet, bekannte Schwachstellen systematisch zu erfassen und zeitgerecht zu beheben. Eine CVSS-9.8-Lücke in produktiv genutzten Systemen sollte nach gängigen SLAs innerhalb von 24–72 Stunden adressiert sein. Dokumentieren Sie Ihre Entscheidungen und Maßnahmen lückenlos für den nächsten Audit.

Checkliste: IngressNightmare-Response für Klinik-IT

Die folgende Checkliste fasst die wichtigsten Handlungsschritte zusammen:

Sofort (innerhalb 24 Stunden): - [ ] Alle Kubernetes-Cluster inventarisiert und Ingress-NGINX-Versionen geprüft - [ ] Betroffene Versionen identifiziert - [ ] Admission-Webhook-Exposition bewertet (intern vs. extern erreichbar) - [ ] Netzwerkseitige Mitigation für nicht sofort patchbare Systeme umgesetzt - [ ] CISO und IT-Leitung informiert - [ ] Change-Request für Notfall-Patch initiiert

Kurzfristig (innerhalb 72 Stunden): - [ ] Patch auf v1.11.5 / v1.

Kostenlose NIS2-Bestandsaufnahme starten →