Redis: Ungepatchte Schwachstelle ermöglicht Denial-of-Service und Informationsabfluss — was Administratoren jetzt tun sollten

„Redis“ klingt nach internem Infrastruktur-Detail — etwas, das Entwickler kennen und das nach außen keine Rolle spielt. Das greift zu kurz. Eine aktuell ungepatchte Schwachstelle erlaubt Angreifern, die sich auf demselben Netzwerksegment befinden — etwa im gleichen Büronetz, VLAN oder Rechenzentrumsbereich — Redis-Instanzen per Denial-of-Service zum Absturz zu bringen und dabei Informationen offenzulegen. „Angrenzendes Netzwerk“ klingt einschränkend; es bedeutet konkret: Jeder, der bereits im internen Netz Fuß gefasst hat, ist ein potenzieller Angreifer. Einen Patch gibt es derzeit nicht.

Warum der Angriffsvektor mehr bedeutet, als er klingt

Der Begriff „Adjacent Network“ entspricht dem CVSS-Angriffsvektor AV:A: Der Angreifer muss auf demselben physischen oder logischen Netzwerksegment wie das Zielsystem sein. Das schließt den anonymen Angreifer aus dem offenen Internet aus — nicht aber jemanden, der über ein kompromittiertes Gerät, eine Phishing-Mail oder einen ungeschützten WLAN-Zugang bereits im internen Netz Fuß gefasst hat.

Redis läuft in vielen Umgebungen auf einem internen Server und ist dort für Teilnehmer desselben Segments erreichbar — häufig ohne zusätzliche Authentifizierung oder Zugangsbeschränkung auf der Netzwerkebene. Genau das ist der Einstiegspunkt.

Was die Schwachstelle im Einzelnen ermöglicht

Die Schwachstelle verbindet zwei Angriffsmöglichkeiten.

Ein Angreifer kann die Redis-Instanz gezielt zum Absturz bringen oder so überlasten, dass sie keine Anfragen mehr beantwortet. Alle Dienste, die Redis als Cache, Session-Store oder Message-Broker verwenden — Web-Applikationen, APIs, Queue-Systeme — fallen damit aus oder werden stark verlangsamt. Das ist der Denial-of-Service-Teil.

Parallel dazu besteht nach aktuellem Kenntnisstand die Möglichkeit, Informationen aus dem Speicher der Instanz abzugreifen. Je nach Einsatz können das Session-Tokens, temporäre Zugangsdaten oder applikationsinterne Zustandsdaten sein. Das ist der Informationsabfluss-Teil.

Die Kombination ist das eigentlich Relevante: Ein reiner DoS wäre betrieblich unangenehm. Ein Angriff, der gleichzeitig Daten abgreift, kann weitergehende Kompromittierungen vorbereiten — und bleibt dabei möglicherweise länger unbemerkt.

Kein Patch: Was das für den Umgang bedeutet

Die Schwachstelle ist nach aktuellem Kenntnisstand ungepatcht. Eine Software-Aktualisierung, die das Problem beseitigt, steht zum Zeitpunkt dieser Meldung nicht bereit. Das bedeutet nicht, dass nichts getan werden kann — es bedeutet, dass die Maßnahmen auf der Infrastruktur- und Konfigurationsebene liegen, nicht beim gewohnten Update-Einspiel-Prozess.

Was Sie jetzt prüfen sollten

Vier Maßnahmen lassen sich in vielen Umgebungen zügig umsetzen:

Netzwerkbindung einschränken. Wenn Redis nur von der Applikation auf demselben Host benötigt wird, sollte es ausschließlich auf Loopback binden (`bind 127.0.0.1`). Müssen andere Hosts zugreifen, explizit auf die autorisierten IP-Adressen beschränken — nicht auf `0.0.0.0`.

Firewall-Regeln verifizieren. Redis-Port 6379 (Standard) darf ausschließlich von definierten Quell-IPs aus erreichbar sein — nicht aus dem gesamten Segment oder dem gesamten internen Netz. Diese Regel sollte bereits existieren; jetzt ist der Moment, sie zu prüfen.

Authentifizierung aktivieren. Redis unterstützt Passwortauthentifizierung (`requirepass`) und feingranulare ACLs. Wer beides nicht nutzt, senkt die Zugangshürde für Angreifer erheblich.

Netzwerksegmentierung überprüfen. Befindet sich Redis in einem VLAN oder Segment, das von Büroarbeitsplätzen, Management-Netzen oder anderen weniger kontrollierten Bereichen nicht getrennt ist? Das ist der Angriffsvektor. Ein eigenes, restriktiv gesteuertes Segment für Cache- und Datenbankdienste reduziert die Angriffsfläche dauerhaft — unabhängig von diesem konkreten Fall.

Ein Patch wird erwartet, sobald er verfügbar ist. Bis dahin gilt: Wer Redis im Netz exponiert betreibt, handelt jetzt auf der Konfigurationsebene — oder wartet auf den nächsten Vorfall.

Quellen: CERT-Bund — „Redis: Schwachstelle ermöglicht Denial of Service und Offenlegung von Informationen“ (https://wid.cert-bund.de/portal/wid/securityadvisory?name=WID-SEC-2026-2745)