Kubernetes Sicherheitslücke kritisch: IngressNightmare im Klinik-ISMS

Kubernetes-Umgebungen gelten im Gesundheitswesen zunehmend als Standardplattform für containerisierte Anwendungen – von Patientenportalen über PACS-Infrastrukturen bis hin zu KI-gestützten Diagnosesystemen. Am 24. März 2025 veröffentlichte das Kubernetes-Projekt Sicherheitsadvisories zu einer Schwachstellengruppe im Ingress NGINX Controller, die das IT-Sicherheitsunternehmen Wiz treffend als „IngressNightmare" bezeichnet. Das BSI stufte die Lage mit Kritikalität 2 ein und warnte ausdrücklich vor der Möglichkeit einer vollständigen Clusterübernahme durch unauthentifizierte Angreifer. Für Krankenhäuser, die Kubernetes-Cluster betreiben, ergibt sich daraus unmittelbarer Handlungsbedarf – technisch, organisatorisch und aus Compliance-Sicht.

Was ist passiert: Die IngressNightmare-Schwachstellen im Überblick

Der Ingress NGINX Controller ist eine der meistgenutzten Kubernetes-Komponenten überhaupt. Er fungiert als Reverse Proxy und Load Balancer und leitet eingehenden HTTP(S)-Traffic auf interne Kubernetes-Services weiter. Genau diese exponierte Position macht ihn zu einem hochattraktiven Angriffsziel.

Am 24. März 2025 wurden fünf Schwachstellen öffentlich gemacht, davon vier mit der Einstufung Remote Code Execution (RCE):

CVE CVSS 3.1 Einstufung Beschreibung
CVE-2025-1974 9.8 Kritisch Unauthentifizierte RCE, vollständige Clusterübernahme möglich
CVE-2025-1097 8.8 Hoch RCE über manipulierte Ingress-Annotationen
CVE-2025-1098 8.8 Hoch RCE über fehlerhafte Validierungslogik
CVE-2025-24514 8.8 Hoch RCE durch unsichere Konfigurationsverarbeitung
(5. CVE) niedriger Mittel Weitere Schwachstelle ohne RCE-Potenzial

Besonders CVE-2025-1974 ist aus Sicherheitsperspektive alarmierend: Ein Angreifer kann ohne vorherige Authentifizierung aus der Ferne Code auf dem Controller ausführen und sich von dort aus lateral durch den Cluster bewegen – bis hin zur vollständigen Übernahme aller darin laufenden Workloads und Secrets.

Betroffene Versionen: - Alle Versionen < 1.11.0 - Versionen 1.11.0 bis einschließlich 1.11.4 - Version 1.12.0

Zum Zeitpunkt der BSI-Warnung war eine aktive Ausnutzung nicht bekannt. Angesichts des öffentlich verfügbaren Proof-of-Concept-Materials von Wiz und des CVSS-Scores von 9.8 ist das Zeitfenster für sicheres Patchen jedoch sehr begrenzt – Erfahrungen aus vergleichbaren Schwachstellen (Log4Shell, Spring4Shell) zeigen, dass Angreifer binnen Stunden nach Publikation mit Scanning-Kampagnen beginnen.

Warum Krankenhäuser besonders exponiert sind

Kubernetes ist im Gesundheitswesen keine Nischenanwendung mehr. Container-Plattformen werden eingesetzt für:

  • Patientenportale und digitale Gesundheitsanwendungen (DiGA-Infrastrukturen, Apps auf Rezept)
  • Radiologie- und PACS-Backends mit containerisierten Viewer-Applikationen
  • KI-Inferenz-Dienste für Bildauswertung oder klinische Entscheidungsunterstützung
  • Interne Entwicklungsplattformen für Softwareentwicklung im Klinikverbund
  • API-Gateways zwischen Primärsystemen (KIS, LIS, RIS) und Drittanwendungen

In vielen dieser Szenarien ist der Ingress NGINX Controller das einzige exponierte Element zwischen dem öffentlichen Internet und hochsensiblen klinischen Daten. Eine erfolgreiche Ausnutzung von CVE-2025-1974 bedeutet im schlimmsten Fall:

  1. Zugriff auf Kubernetes Secrets – darunter Datenbankpasswörter, API-Tokens, TLS-Zertifikate
  2. Lateral Movement in angrenzende Systeme über Service-Account-Berechtigungen
  3. Ransomware-Deployment in containerisierten Umgebungen oder auf angebundene persistente Speicher
  4. Datenschutzverletzung mit unmittelbarer Meldepflicht nach DSGVO Art. 33 (72-Stunden-Frist gegenüber der zuständigen Datenschutzaufsichtsbehörde)

Für KRITIS-Krankenhäuser und Einrichtungen im Anwendungsbereich des NIS2UmsuCG (gilt seit Oktober 2024 in Deutschland) kommt hinzu, dass erhebliche Sicherheitsvorfälle nach §32 BSIG gegenüber dem BSI gemeldet werden müssen. Eine Clusterübernahme mit Patientendaten-Exposition ist ohne Zweifel ein meldepflichtiges Ereignis.

Sofortmaßnahmen: Patch-Priorisierung und temporäre Mitigationen

Primäre Maßnahme: Update auf gepatchte Version

Das Kubernetes-Projekt hat mit den Versionen 1.11.5 und 1.12.1 (oder aktueller) Korrekturen bereitgestellt. Das Update ist die einzige vollständige Remediation.

Empfohlenes Vorgehen im Krankenhaus-Kontext:

1. Bestandsaufnahme: Welche Kubernetes-Cluster existieren? 
   Welche Version des Ingress NGINX Controllers ist installiert?
   → kubectl get pods -A | grep ingress-nginx
   → kubectl exec -n ingress-nginx <pod> -- /nginx-ingress-controller --version

2. Risikopriorisierung: 
   → Intern exponiert vs. extern erreichbar?
   → Welche Workloads und Secrets sind im Cluster?

3. Patch-Deployment in Testumgebung validieren

4. Patch-Deployment in Produktion nach Change-Management-Prozess

5. Post-Patch: Überprüfung auf Indicators of Compromise (IoC)

Temporäre Mitigation bei verzögertem Patching

Wenn ein sofortiges Update nicht möglich ist (etwa wegen Change-Freeze oder fehlender Testumgebung), empfiehlt das BSI folgende Sofortmaßnahmen:

  • Netzwerksegmentierung: Den Admission Webhook des Ingress NGINX Controllers (Port 8443) auf interne Quellen beschränken. Kein direkter Zugriff aus dem Internet oder aus nicht vertrauenswürdigen Netzwerksegmenten.
  • Network Policies: Kubernetes-native Network Policies implementieren, die eingehende Verbindungen zum Webhook-Service auf autorisierte Quellen limitieren.
  • Monitoring schärfen: Logs des Ingress NGINX Controllers auf ungewöhnliche Annotationen, unbekannte Anfragen und Fehler bei der Konfigurationsverarbeitung überwachen.
  • Webhook temporär deaktivieren: In Umgebungen ohne aktive Nutzung des Admission Webhooks kann dieser deaktiviert werden – Auswirkungen auf den Betrieb sind vorher sorgfältig zu prüfen.

Wichtig: Mitigationen ersetzen das Patching nicht. Sie reduzieren die Angriffsfläche, schließen die Schwachstelle aber nicht.

ISMS-Integration: Vom Einzelvorfall zur systematischen Kontrolle

IngressNightmare ist kein isoliertes Ereignis, sondern ein Muster. Supply-Chain-Schwachstellen in weit verbreiteten Open-Source-Komponenten (Ingress NGINX hat Millionen von Installationen weltweit) treffen Krankenhäuser häufig unvorbereitet, weil Container-Infrastrukturen oft außerhalb des klassischen Schwachstellenmanagements liegen.

Kubernetes in den Asset-Bestand aufnehmen

Ein häufiger Befund in Audits: Kubernetes-Cluster tauchen im ISMS-Asset-Register gar nicht oder nur unvollständig auf. Ohne Inventar kein Vulnerability Management. Mindestanforderung:

  • Asset-Klasse „Kubernetes-Cluster" mit Attributen: Betreiber, enthaltene Workloads, Kritikalitätsstufe, installierte Komponenten inkl. Versionsstand
  • Regelmäßiges Scanning mit Tools wie Trivy, Kube-Bench oder vergleichbaren Lösungen
  • SBOM (Software Bill of Materials) für containerisierte Eigenentwicklungen, um Drittkomponenten wie den Ingress NGINX Controller schnell identifizieren zu können

Patch-Prozess für Container-Umgebungen definieren

Der klassische Patch-Zyklus (monatlich, quartalsweise) ist für kritische RCE-Schwachstellen mit CVSS ≥ 9.0 nicht ausreichend. Im Rahmen des ISMS sollte eine Eskalationsstufe für kritische Schwachstellen definiert sein:

  • CVSS ≥ 9.0 → Patch innerhalb von 72 Stunden nach Verfügbarkeit, sofern Exposition vorhanden
  • CVSS 7.0–8.9 → Patch innerhalb von 7 Tagen
  • Niedrigere Stufen → regulärer Patch-Zyklus

Diese Anforderungen decken sich mit den technischen Mindestmaßnahmen nach §30 BSIG und den Empfehlungen des B3S Krankenhaus (Branchenspezifischer Sicherheitsstandard), der explizit ein risikobasiertes Schwachstellenmanagement fordert.

Incident-Response-Plan für Kubernetes-Szenarien

Viele Incident-Response-Pläne in Krankenhäusern adressieren klassische IT-Szenarien (Ransomware auf Windows-Systemen, Datenpanne im KIS). Container-spezifische Szenarien fehlen häufig. Notwendige Erweiterungen:

  • Forensik in Container-Umgebungen: Wie werden Logs gesichert, wenn Pods bereits beendet wurden? (→ zentrales Log-Aggregation-System wie Loki oder Elastic voraussetzen)
  • Cluster-Isolation: Wer darf einen Kubernetes-Cluster im Notfall vom Netz nehmen? Ist die Auswirkung auf den klinischen Betrieb bekannt?
  • Secret-Rotation: Prozedur für den Fall, dass Kubernetes Secrets kompromittiert wurden – wer rotiert welche Credentials in welcher Reihenfolge?

Eine Vorlage für ein Kubernetes-spezifisches Incident-Response-Playbook können Sie im ISMShield.ai Wissenszentrum finden.

Compliance-Einordnung: Was ISBs jetzt dokumentieren müssen

Unabhängig davon, ob ein Vorfall eingetreten ist: Die Existenz einer kritischen, öffentlich bekannten Schwachstelle in produktiv genutzter Infrastruktur erzeugt Dokumentationspflichten im ISMS.

Risikobehandlungsentscheidung dokumentieren: Halten Sie schriftlich fest: Ist die betroffene Software im Einsatz? Wenn ja: Welche Version? Welche Maßnahme wurde ergriffen (Patch, Mitigation, Risikoakzeptanz mit Begründung)? Bis wann?

Meldepflichten prüfen: - Bereits bei begründetem Verdacht auf eine Kompromittierung sind KRITIS-Betreiber und Einrichtungen im NIS2-Scope nach §32 BSIG zur Meldung verpflichtet. - Bei Betroffenheit personenbezogener Gesundheitsdaten greift DSGVO Art. 33 (Meldung an Aufsichtsbehörde binnen 72 Stunden) und Art. 34 (ggf. Betroffeneninformation). - §391 SGB V verpflichtet Krankenhäuser ab einer bestimmten Größe zur Umsetzung eines ISMS nach dem B3S oder einer gleichwertigen Norm – das Schwachstellenmanagement ist explizit Bestandteil dieser Anforderungen.

Für rechtliche Einordnung im Einzelfall wenden Sie sich an einen auf IT-Recht spezialisierten Anwalt.

Checkliste: Sofortmaßnahmen für ISBs und IT-Leitung

  • [ ] Bestandsaufnahme: Kubernetes-Cluster und installierte Ingress NGINX Controller-Versionen inventarisieren
  • [ ] Exposition prüfen: Ist Port 8443 (Admission Webhook) aus dem Internet oder aus nicht vertrauenswürdigen Segmenten erreichbar?
  • [ ] Priorität eskalieren: IngressNightmare als kritisches Sicherheitsereignis in das ISMS-Risikolog aufnehmen
  • [ ] Patch-Deployment planen: Update auf Version ≥ 1.11.5 bzw. ≥ 1.12.1 im Change-Management einplanen – Zeitziel: 72 Stunden für exponierte Systeme
  • [ ] Temporäre Mitigation umsetzen: Network Policies und Webhook-Zugriffsbeschränkung sofort konfigurieren
  • [ ] Monitoring aktivieren: Logs des Ingress NGINX Controllers auf Anomalien überwachen, SIEM-Regeln anpassen
  • [ ] IoC-Prüfung: Nach Patch retrospektiv auf Indicators of Compromise prüfen
  • [ ] Dokumentation: Risikobehandlungsentscheidung schriftlich festhalten
  • [ ] Meldepflichten evaluieren: Juristische Bewertung, ob §32 BSIG oder DSGVO Art. 33 greift

Möchten Sie Ihre aktuelle Kubernetes-Sicherheitslage systematisch bewerten? Das ISMShield Assessment hilft Ihnen, Lücken im Container-Sicherheitsprogramm schnell zu identifizieren.

  • **BSI Cybersicherheitswarnung (
Kostenlose NIS2-Bestandsaufnahme starten →
Weitere Artikel im Wissensbereich