Redis Sicherheitslücke kritisch: CVE-2025-49844 im Klinikbetrieb

Eine kritische Schwachstelle in Redis – bewertet mit dem maximal möglichen CVSS-Score von 10,0 – gefährdet seit Oktober 2025 ungepatchte Redis-Installationen weltweit. Für Krankenhäuser und Kliniken, die Redis als Caching- oder Session-Layer in klinischen Anwendungen einsetzen, ist die Lage besonders ernst: Rund 4.000 Redis-Server in Deutschland sind ohne Authentifizierung direkt aus dem Internet erreichbar. Dieser Artikel erklärt die technischen Details der Schwachstelle, bewertet die Risikolage im Gesundheitswesen und zeigt konkrete Maßnahmen für ISB und IT-Leitung.

Was ist CVE-2025-49844 – und warum ist sie so kritisch?

Am 3. Oktober 2025 veröffentlichte Redis ein Advisory zu CVE-2025-49844, einer Remote Code Execution (RCE)-Schwachstelle in der gleichnamigen In-Memory-Datenbank- und Caching-Lösung. Redis selbst bewertet die Schwachstelle mit CVSS 10,0 – dem theoretischen Maximum. Andere CVE-Datenbanken vergeben 9,9. Beide Einschätzungen signalisieren: höchste Dringlichkeit.

Der technische Angriffsmechanismus nutzt präparierte Lua-Skripte, um den internen Garbage Collector von Redis zu manipulieren. Der Garbage Collector ist ein Prozess zur automatischen Speicherbereinigung. Durch gezielte Manipulation lässt sich dieser Prozess missbrauchen, um beliebigen Code auf dem Redis-Host auszuführen – ohne vorherige Authentifizierung, sofern diese nicht explizit aktiviert wurde.

Das IT-Sicherheitsunternehmen Wiz veröffentlichte am 6. Oktober 2025 einen ergänzenden technischen Bericht, der das Angriffsszenario weiter konkretisiert. Ein zentraler Befund: Redis wird im Standard-Container-Image mit deaktivierter Authentifizierung ausgeliefert. Wer Redis in einer Container-Umgebung (Docker, Kubernetes) betreibt, ohne explizit Authentifizierung zu konfigurieren, exponiert einen vollständig unkompromittierten Zugriffspfad für Angreifer.

Das BSI hat die Schwachstelle am 7. Oktober 2025 in einer eigenen Sicherheitsmitteilung aufgegriffen und mit Kritikalität 2 (auf der BSI-internen Skala) klassifiziert. Die BSI-Warnung unterstreicht explizit: In Deutschland sind nach aktuellem Kenntnisstand ca. 4.000 Redis-Server ohne Authentifizierung aus dem Internet erreichbar.

Redis im Krankenhaus: Wo steckt die Technologie?

Redis ist keine Nischen-Technologie. Als schneller In-Memory-Datenspeicher findet sich Redis in zahlreichen modernen Softwarearchitekturen – auch in klinischen Umgebungen. Typische Einsatzszenarien im Gesundheitswesen:

  • KIS/RIS/PACS-Backends: Moderne klinische Informationssysteme nutzen Redis häufig als Session-Cache oder für temporäre Datenpuffer.
  • Web-Applikationen und Patientenportale: Patientenportale, Terminbuchungssysteme oder interne Kommunikationsplattformen setzen auf Redis für Session-Management.
  • Microservice-Architekturen: Containerisierte Anwendungen in Kubernetes-Clustern – zunehmend auch in Krankenhäusern anzutreffen – verwenden Redis als Message Broker oder Zwischenspeicher.
  • Analyse- und BI-Plattformen: Datenintegrationsplattformen und klinische Auswertungstools können Redis als Caching-Schicht einsetzen.
  • Drittanbieter-Software: Entscheidend: Redis muss nicht von der eigenen IT installiert worden sein. Viele Drittanbieter-Applikationen bringen Redis als Abhängigkeit mit – ohne dass der Betreiber dies explizit weiß.

Dieser letzte Punkt ist für ISB besonders relevant. Im Kontext von §391 SGB V und dem B3S Krankenhaus sind Betreiber verpflichtet, ein vollständiges Asset-Inventar vorzuhalten und Risiken durch eingesetzte Software – einschließlich eingebetteter Komponenten – zu bewerten. Wer Redis nicht im Asset-Inventar hat, kann diese Schwachstelle auch nicht systematisch adressieren.

Risikolage: Was bedeutet CVE-2025-49844 konkret für Kliniken?

Eine erfolgreich ausgenutzte RCE-Schwachstelle in einem Redis-Server, der mit klinischen Systemen kommuniziert, eröffnet Angreifern weitreichende Möglichkeiten:

Sofortige Auswirkungen - Vollständige Kontrolle über den Redis-Prozess und den Host-Rechner (bei unsicherer Container-Konfiguration auch über den Host hinaus) - Auslesen aller im Cache gespeicherten Daten – darunter potenziell Session-Tokens, Patientendaten, Authentifizierungsinformationen - Manipulation von gecachten Daten, die von klinischen Anwendungen gelesen werden

Eskalationspfade - Lateral Movement im Krankenhausnetz, sofern Redis nicht segmentiert ist - Persistenz durch Einschleusen von Malware oder Backdoors - Als Einstiegspunkt für Ransomware-Kampagnen – ein in deutschen Krankenhäusern leider etabliertes Angriffsmuster

Regulatorische Konsequenzen Ein erfolgreicher Angriff über CVE-2025-49844 hätte im KRITIS-Kontext unmittelbare Meldepflichten ausgelöst: Gemäß §32 BSIG (in der seit der NIS2-Umsetzung durch das NIS2UmsuCG geltenden Fassung) müssen erhebliche Sicherheitsvorfälle innerhalb von 24 Stunden als Frühwarnung an das BSI gemeldet werden. Hinzu kommt die Meldepflicht nach Art. 33 DSGVO gegenüber der zuständigen Datenschutzaufsichtsbehörde, wenn personenbezogene – insbesondere Gesundheits- – Daten betroffen sind, innerhalb von 72 Stunden.

Für rechtliche Beratung zu Ihren spezifischen Meldepflichten wenden Sie sich an einen auf IT- und Datenschutzrecht spezialisierten Anwalt.

Sofortmaßnahmen: Was jetzt zu tun ist

Die Redis Sicherheitslücke CVE-2025-49844 erfordert strukturiertes, zügiges Handeln. Die folgenden Maßnahmen sind nach Priorität geordnet.

1. Bestandsaufnahme: Redis-Instanzen identifizieren

Bevor gepatcht werden kann, muss bekannt sein, wo Redis läuft. Führen Sie eine gezielte Inventarisierung durch:

  • Netzwerk-Scan auf den Standard-Redis-Port 6379/TCP im gesamten Klinik-Netz, inklusive DMZ und Container-Netzwerken
  • Prüfung aller Container-Registries und Kubernetes-Deployments auf Redis-Images
  • Rücksprache mit Drittanbietern klinischer Software: Welche Ihrer Produkte nutzen Redis als Abhängigkeit?
  • Prüfung ob Redis-Instanzen ohne Authentifizierung (requirepass nicht gesetzt) betrieben werden

2. Patch einspielen

Redis hat Updates für die betroffenen Versionen bereitgestellt. Prüfen Sie die von Redis veröffentlichten Patch-Informationen und aktualisieren Sie auf die korrigierte Version. Für Container-Deployments bedeutet dies: neue Image-Versionen ziehen, bestehende Pods neu starten.

3. Authentifizierung erzwingen – sofort

Unabhängig vom Patch-Status: Aktivieren Sie sofort die Redis-Authentifizierung (requirepass in der redis.conf bzw. als Kubernetes-Secret). Dies reduziert das Angriffsfenster signifikant, auch wenn der Patch noch nicht eingespielt ist. Starke, zufällige Passwörter verwenden (mindestens 32 Zeichen).

4. Netzwerkzugang einschränken

Redis-Ports dürfen unter keinen Umständen aus dem Internet erreichbar sein. Prüfen Sie:

  • Firewall-Regeln: Ist Port 6379 (und 6380 für TLS) von außen erreichbar?
  • Sind Redis-Instanzen in separaten Netzwerksegmenten, die nur von autorisierten Applikationsservern erreichbar sind?
  • Kubernetes NetworkPolicies: Schränken diese den Zugriff auf Redis-Pods explizit ein?

5. Lua-Scripting deaktivieren (falls nicht benötigt)

Da der Angriff Lua-Skripte als Vehikel nutzt, kann das Deaktivieren des Lua-Scripting-Features (enable-debug-command no, script-enabled no je nach Redis-Version) den spezifischen Angriffsvektor schließen, wenn die Funktion betrieblich nicht benötigt wird. Prüfen Sie Abhängigkeiten der eingesetzten Anwendungen.

Checkliste für ISB und IT-Leitung

Die folgende Checkliste unterstützt bei der strukturierten Abarbeitung. Sie eignet sich auch als Nachweis-Dokument für das ISMS.

Inventarisierung - [ ] Netzwerk-Scan auf Port 6379/TCP im gesamten Kliniknetz durchgeführt - [ ] Container-Deployments auf Redis-Images geprüft - [ ] Drittanbieter nach Redis-Nutzung befragt und dokumentiert - [ ] Alle Redis-Instanzen im Asset-Inventar erfasst

Sofortsicherung (auch ohne Patch) - [ ] Authentifizierung (requirepass) auf allen Redis-Instanzen aktiviert - [ ] Lua-Scripting deaktiviert, sofern betrieblich möglich - [ ] Netzwerkzugang auf Redis-Ports auf autorisierte Quellen beschränkt - [ ] Öffentliche Erreichbarkeit (Internet-facing) ausgeschlossen und dokumentiert

Patching - [ ] Betroffene Redis-Versionen identifiziert - [ ] Patches eingespielt und Versionsstand dokumentiert - [ ] Container-Images aktualisiert und neu deployed

Monitoring & Incident Response - [ ] SIEM-Regeln für Redis-Zugriffsmuster aktiviert oder erstellt - [ ] Log-Auswertung auf ungewöhnliche Lua-Script-Ausführungen geprüft (rückwirkend ab Oktober 2025) - [ ] Vorfalls-Eskalationspfad für den Fall eines erkannten Angriffs definiert

Dokumentation & Compliance - [ ] Risikobehandlungsentscheidung im ISMS dokumentiert - [ ] Meldepflicht-Prüfung durchgeführt (§32 BSIG, Art. 33 DSGVO) - [ ] Drittanbieter-Verträge auf Patch-SLAs geprüft (relevant nach §30 BSIG und B3S)

Einordnung in den regulatorischen Rahmen

Für Krankenhäuser, die unter §391 SGB V fallen (KRITIS-relevante Einrichtungen ab 30.000 vollstationären Fällen jährlich) sowie für Einrichtungen, die seit dem Inkrafttreten des NIS2UmsuCG als „wichtige" oder „besonders wichtige" Einrichtungen nach BSIG gelten, ist der Umgang mit CVE-2025-49844 kein optionales Best-Practice-Thema, sondern eine Compliance-Anforderung.

§30 BSIG verpflichtet betroffene Einrichtungen zur Umsetzung geeigneter technischer und organisatorischer Maßnahmen, darunter explizit Patch-Management, Schwachstellenmanagement und Netzwerksegmentierung. Die Nichtbehebung einer CVSS-10,0-Schwachstelle bei bekanntem Patch wäre im Rahmen eines BSI-Audits schwer begründbar.

B3S Krankenhaus: Der Branchenspezifische Sicherheitsstandard für die Gesundheitsversorgung im Krankenhaus fordert ein systematisches Schwachstellenmanagement und die zeitnahe Behandlung kritischer Schwachstellen. CVE-2025-49844 erfüllt alle Kriterien für höchste Behandlungspriorität.

ISO 27001 / ISO 27799: Im Rahmen eines zertifizierten ISMS wäre CVE-2025-49844 als Risiko zu dokumentieren, zu bewerten und mit einer Risikobehandlungsentscheidung zu versehen. Die gewählten Maßnahmen sind im Statement of Applicability und im Risikobehandlungsplan zu aktualisieren.

Wenn Sie noch kein strukturiertes Vulnerability-Management-Prozess im Einsatz haben oder prüfen möchten, wie Ihr Krankenhaus bei der Umsetzung dieser Anforderungen aufgestellt ist, unterstützt das kostenlose Self-Assessment unter ismshield.bpcgmbh.com/assessment/ bei der Standortbestimmung.

Weitere Hintergrundartikel zu verwandten Themen finden Sie im ISMShield Wissenszentrum unter ismshield.ai/wissen/.

  • BSI Sicherheitsmitteilung CVE-2025-49844 (07.10.2025): https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2025/2025-287813-1032_bits.html
  • Redis Advisory zu CVE-2025-49844: redis.io (offizielle Release Notes und Patch-Informationen)
  • Wiz Research Blog (06.10.2025): Technische Analyse der Schwachstelle und Standardkonfiguration
  • BSI IT-Grundschutz-Kompendium: Baustein SYS.1.6 Containerisierung – [https://www.bsi.bund.de/grundschutz](https://www.bsi.bund.de/grundsc
Kostenlose NIS2-Bestandsaufnahme starten →
Weitere Artikel im Wissensbereich