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

Redis ist in vielen Krankenhaus-IT-Infrastrukturen unsichtbar, aber allgegenwärtig: als Session-Cache hinter Patientenportalen, als Message-Broker in Mikroservice-Architekturen, als temporärer Speicher für HL7-Nachrichten oder DICOM-Worklisten. Genau deshalb hat die im Oktober 2025 veröffentlichte kritische Schwachstelle CVE-2025-49844 für Informationssicherheitsbeauftragte im Gesundheitswesen eine andere Schwere als für den durchschnittlichen IT-Betrieb. Dieser Artikel erklärt die technischen Details, ordnet die Bedrohungslage für Kliniken ein und nennt konkrete Maßnahmen zur Abhilfe.

Was steckt hinter CVE-2025-49844?

Am 3. Oktober 2025 veröffentlichte Redis Ltd. einen Blogbeitrag sowie ein offizielles Advisory zur Schwachstelle CVE-2025-49844. Der CVSS-Score wurde vom Hersteller selbst mit 10,0 (Critical) bewertet; unabhängige CVE-Datenbanken bestätigen mit Werten von 9,9 die maximale Kritikalitätsstufe. Das BSI stufte die Schwachstelle am 7. Oktober 2025 in seiner Sicherheitsmitteilung (2025-287813-1032) ebenfalls mit Kritikalität 2 (von 4, entspricht „hoch bis kritisch" auf BSI-Skala) ein.

Technischer Angriffsmechanismus

Der Angriff setzt am Lua-Scripting-Interface von Redis an. Redis erlaubt es, serverseitige Lua-Skripte über den Befehl EVAL oder die Skript-Registry auszuführen. CVE-2025-49844 ermöglicht es einem Angreifer, durch präparierte Lua-Skripte den Garbage Collector – den internen Speicherbereinigungsprozess – so zu manipulieren, dass eine Remote Code Execution (RCE) möglich wird.

Konkret bedeutet das: Ein Angreifer, der Netzwerkzugriff auf einen Redis-Port (Standard: TCP 6379) hat, kann ohne gültige Credentials beliebigen Code mit den Rechten des Redis-Prozesses ausführen – sofern keine Authentifizierung konfiguriert ist. Aus dieser Position heraus sind typische Folgeaktionen möglich:

Lateral Movement im Krankenhausnetz über den Redis-Host als Pivotpunkt
Datenexfiltration aus dem In-Memory-Store (Sessiondaten, temporäre Patientendaten)
Persistenz durch Manipulation von Redis-Konfiguration oder cron-basierte Backdoors (bekannte Redis-Exploit-Technik)
Ransomware-Staging mit Verschlüsselung nachgelagerter Systeme

Default-Konfiguration als Brandbeschleuniger

Das IT-Sicherheitsunternehmen Wiz veröffentlichte am 6. Oktober 2025 einen ergänzenden Analysebericht mit einem entscheidenden Detail: Redis wird in seiner Standard-Container-Konfiguration mit deaktivierter Authentifizierung ausgeliefert. Das bedeutet, dass jede Container-Deployment-Pipeline, die Redis ohne explizite Härtung ausrollt – ob Kubernetes, Docker Compose oder ein Cloud-managed Service – unmittelbar verwundbar ist.

Das BSI quantifizierte das Ausmaß für Deutschland: Circa 4.000 Redis-Server sind ohne Authentifizierung direkt aus dem Internet erreichbar. Wie viele weitere hinter mangelhaft segmentierten internen Netzwerken betrieben werden, ist dabei nicht erfasst – und im Krankenhaususmfeld ist genau das die wahrscheinlichere Angriffsfläche.

Warum Krankenhäuser besonders exponiert sind

Die Redis Sicherheitslücke kritisch zu bewerten ist im Gesundheitswesen aus mehreren Gründen besonders geboten.

Redis als unsichtbare Infrastrukturkomponente

Redis ist selten Teil bewusster Kaufentscheidungen im Krankenhausumfeld. Es wird typischerweise als Abhängigkeit von Drittsoftware mitgeliefert: Krankenhausinformationssysteme (KIS), Radiologie-Informationssysteme (RIS), Patientenportale, VNA-Lösungen (Vendor Neutral Archive) und klinische Entscheidungsunterstützungssysteme nutzen Redis intern, ohne dass dies im Betriebshandbuch prominent dokumentiert ist. Das führt zu einem klassischen Shadow-Infrastructure-Problem: Der ISB weiß nicht, wo Redis läuft, und der Redis-Betreiber weiß nicht, was er betreibt.

Sensible Daten im In-Memory-Store

Redis-Instanzen in klinischen Umgebungen enthalten häufig:

Session-Tokens für Webanwendungen mit Patientendaten (DSGVO-Relevanz: Art. 32 DSGVO, Art. 9 besondere Kategorien)
Temporäre HL7/FHIR-Nachrichten im Message-Queuing-Betrieb
Zugangsdaten oder API-Keys als zwischengespeicherte Konfigurationswerte
Worklisten und Untersuchungsstatus aus RIS/PACS-Integrationen

Eine erfolgreiche Kompromittierung ist damit unmittelbar ein meldepflichtiges Datenschutzvorfalls-Szenario nach Art. 33/34 DSGVO und potenziell ein Sicherheitsvorfall nach §32 BSIG (Meldepflichten für KRITIS-Betreiber) beziehungsweise nach den Meldepflichten gemäß §391 SGB V für Krankenhäuser oberhalb der Schwellenwerte.

Flache Netzwerksegmentierung erhöht die Angriffsfläche

Viele Krankenhäuser betreiben historisch gewachsene, flach segmentierte Netzwerke. Ein Redis-Server, der eigentlich nur von einer spezifischen Applikation erreichbar sein sollte, ist in solchen Umgebungen häufig aus dem gesamten Klinik-VLAN erreichbar. Für einen Angreifer, der über einen anderen Weg – etwa eine Phishing-Mail oder eine kompromittierte Workstation – ins Netz gelangt ist, stellt ein ungepatchter, unauthentifizierter Redis-Server ein ideales Sprungbrett dar.

Sofortmaßnahmen: Was jetzt zu tun ist

Schritt 1: Inventarisierung – wo läuft Redis?

Vor jeder anderen Maßnahme steht die Bestandsaufnahme. Führen Sie einen internen Portscan auf TCP 6379 (Standard) und gängige Alternativports (6380, 16379, 26379 für Cluster/Sentinel) durch. Ergänzen Sie dies durch:

Auswertung Ihrer CMDB auf Redis-Einträge (häufig unvollständig)
Abfrage bei Anwendungsverantwortlichen und Lieferanten: „Enthält Ihre Software Redis als Komponente?"
Scan von Container-Registries und Kubernetes-Deployments auf Redis-Images
Log-Auswertung in Ihrem SIEM auf Verbindungen zu Port 6379

Setzen Sie für die Inventarisierung eine Frist von 24–48 Stunden nach Kenntnisnahme.

Schritt 2: Authentifizierung aktivieren und härten

Für alle identifizierten Redis-Instanzen gilt prioritär:

# In redis.conf:
requirepass <starkes-zufälliges-passwort>

# Für Redis 6+: ACL-basierte Authentifizierung bevorzugen
user default off
user appuser on >geheimespasswort ~* +@all

Bei containerisierten Deployments muss die Authentifizierung über Umgebungsvariablen oder Secrets-Management (Kubernetes Secrets, HashiCorp Vault) übergeben werden – niemals im Container-Image hardcoded.

Schritt 3: Patch einspielen

Redis hat Patches für die betroffenen Versionen veröffentlicht. Spielen Sie das Sicherheitsupdate umgehend ein. Prüfen Sie für Drittanbieter-Software die Update-Hinweise der jeweiligen Hersteller, da diese möglicherweise eigene Redis-Builds mitliefern. Bei managed Redis-Diensten (AWS ElastiCache, Azure Cache for Redis) prüfen Sie, ob der Cloud-Anbieter automatische Patches eingespielt hat oder ob manuelle Aktion erforderlich ist.

Schritt 4: Netzwerkzugriff beschränken

Unabhängig vom Patch-Status sollte Redis niemals direkt aus dem Internet erreichbar sein. Konfigurieren Sie:

Firewall-Regeln: Erlauben Sie Verbindungen auf Port 6379 ausschließlich von den IP-Adressen der legitimen Client-Anwendungen
Bind-Direktive: bind 127.0.0.1 oder die spezifische interne IP, nicht 0.0.0.0
TLS: Für Redis 6+ TLS-Verschlüsselung aktivieren, insbesondere bei Verbindungen über Segmentgrenzen

# redis.conf Härtung:
bind 127.0.0.1 10.10.5.20
protected-mode yes

Schritt 5: Lua-Scripting einschränken

Sofern Ihre Anwendung keine Lua-Skripte verwendet, deaktivieren Sie die entsprechende Funktionalität:

# EVAL und SCRIPT-Befehle deaktivieren:
rename-command EVAL ""
rename-command EVALSHA ""
rename-command SCRIPT ""

Hinweis: Prüfen Sie vor dem Deaktivieren, ob Ihre Anwendungslogik oder eingesetzte Redis-Clients diese Befehle intern verwenden – dies ist nicht selten bei ORM-Abstraktionen und Caching-Bibliotheken.

Compliance-Einordnung für KRITIS-Krankenhäuser

Für Krankenhäuser, die als KRITIS-Betreiber eingestuft sind oder unter §391 SGB V fallen, ergeben sich aus diesem Vorfall konkrete Compliance-Implikationen.

Patch-Management als Pflichtmaßnahme

Sowohl der B3S Krankenhaus (Branchenspezifischer Sicherheitsstandard, gültige Fassung) als auch der BSI IT-Grundschutz (insbesondere Baustein SYS.1.6 für containerisierte Systeme und OPS.1.1.3 Patch- und Änderungsmanagement) fordern ein dokumentiertes, risikobasiertes Patch-Management. Eine kritische Schwachstelle mit CVSS 10,0 muss in Ihrem Patch-Management-Prozess als P1/Notfall-Patch klassifiziert und mit entsprechender Frist (in der Regel ≤72 Stunden für aktiv ausnutzbare kritische CVEs) behandelt werden.

Meldepflichten im Blick behalten

Sollte es vor oder während der Patchphase zu einem aktiven Angriff oder einer bestätigten Kompromittierung kommen, gelten:

§32 BSIG: Meldung erheblicher Störungen an das BSI (für NIS2-pflichtige Einrichtungen nach NIS2UmsuCG, in Kraft seit 2025)
§391 SGB V: Meldung von IT-Sicherheitsvorfällen durch Krankenhäuser an das BSI
Art. 33 DSGVO: Meldung von Datenschutzverletzungen an die zuständige Landesdatenschutzbehörde innerhalb von 72 Stunden

Für die rechtliche Einordnung Ihrer konkreten Meldepflichten wenden Sie sich an einen auf IT-Recht spezialisierten Anwalt.

Dokumentationspflicht

Dokumentieren Sie Ihre Reaktion auf diese Schwachstelle lückenlos: Inventarisierungsergebnis, getroffene Maßnahmen mit Datum und Verantwortlichem, Patch-Status je System. Diese Dokumentation ist im Rahmen von BSI-Nachweispflichten und internen Audits nach ISO 27001 (Annex A.8.8 Management of technical vulnerabilities) unmittelbar relevant.

Checkliste: Redis CVE-2025-49844 im Krankenhaus

Maßnahme	Priorität	Status
Redis-Instanzen im Netzwerk inventarisiert (inkl. Container, Drittanbieter-Software)	Kritisch / sofort	☐
Authentifizierung auf allen Instanzen aktiviert	Kritisch / sofort	☐
Sicherheitspatch eingespielt (oder Hersteller-Update abgewartet)	Kritisch / ≤72h	☐
Firewall-Regeln: Kein direkter Internetzugriff auf Port 6379	Kritisch / sofort	☐
Bind-Direktive auf spezifische IP gesetzt	Hoch / ≤24h	☐
Lua-Scripting deaktiviert (soweit anwendungskompatibel)	Hoch / ≤48h	☐
TLS für Redis-Verbindungen über Segmentgrenzen aktiviert	Mittel / ≤1 Woche	☐
SIEM-Monitoring auf Redis-Port-Anomalien konfiguriert	Mittel / ≤1 Woche	☐
Drittanbieter-Software auf Redis-Komponenten abgefragt	Hoch / ≤48h	☐
Vorfall dokumentiert (Inventar, Maßnahmen, Verantwortliche)	Hoch / laufend	☐
Keine Kompromittierung feststellbar (oder: Meldepflichten geprüft)	Kritisch / sofort	☐

Fazit

Die Redis Sicherheitslücke CVE-2025-49844 ist ein Musterbeispiel für ein unterschätztes Risiko in klinischen IT-Umgebungen: eine technisch tief eingebettete, schlecht sichtbare Infrastrukturkomponente mit maximaler CVSS-Bewertung und aktivierbarer Remote-Code-Execution. Die Kombination aus Default-Konfiguration ohne Authentifizierung, weit ver

Kostenlose NIS2-Bestandsaufnahme starten →