Kritische Redis-Schwachstelle könnte die meisten Cloud-Umgebungen kompromittieren

Eine neu entdeckte Schwachstelle in Redis – RediShell (CVE-2025-49844) genannt – stellt eines der schwerwiegendsten Cybersicherheitsrisiken des Jahres dar. 

Die Schwachstelle erhält einen CVSS-Score von 10,0 und ermöglicht es authentifizierten Angreifern, aus der Ferne beliebigen Code auf betroffenen Systemen auszuführen. 

Das Problem geht auf eine 13 Jahre alte Use-after-free-Schwachstelle (UAF) zur Beschädigung des Speichers zurück, die in allen Redis-Versionen bis einschließlich 8.2.1 vorhanden ist und potenziell bis zu 75 % der Cloud-Umgebungen betrifft.

„Diese Schwachstelle ermöglicht es einem Angreifer nach der Authentifizierung, ein speziell präpariertes bösartiges Lua-Skript zu senden, der Lua-Sandbox zu entkommen und beliebigen nativen Code auf dem Redis-Host auszuführen“, so die Sicherheitsforscher von Wiz.

Warum die Popularität von Redis die Technologie zu einem bevorzugten Ziel macht

Redis ist eine zentrale Technologie für Caching, Sitzungsverwaltung und Messaging in modernen Anwendungen. Die hohe Performance und einfache Bereitstellung haben Redis zur Standardwahl in Cloud-nativen Architekturen gemacht. Doch genau diese Allgegenwärtigkeit verstärkt die Gefahr durch RediShell. 

Wie die Forscher von Wiz anmerken, sind mehr als 330.000 Redis-Instanzen öffentlich aus dem Internet erreichbar, und bei 60.000 von ihnen fehlt jegliche Form der Authentifizierung – ideale Voraussetzungen für eine massenhafte Ausnutzung.

Die Schwere der Schwachstelle liegt nicht nur in ihrem technischen Potenzial für Remote-Code-Ausführung (RCE), sondern auch in den betrieblichen Praktiken von Unternehmen, die Redis-Container ohne angemessene Härtung oder Zugriffskontrollen bereitstellen.

Phasen eines RediShell-Angriffs

RediShell nutzt eine seit Langem bestehende Schwachstelle in der Speicherverwaltung von Redis’ Lua-Scripting-Engine aus. 

Durch das Übermitteln eines sorgfältig präparierten Lua-Skripts kann ein Angreifer die Use-after-free-Bedingung auslösen, wodurch er der Lua-Sandbox entkommen und beliebigen nativen Code auf dem Hostsystem ausführen kann. 

Nach erfolgreicher Ausnutzung können Angreifer Daten abziehen oder verschlüsseln, Zugangsdaten stehlen, Schadsoftware installieren oder kompromittierte Systeme für laterale Bewegungen nutzen.

Sicherheitsforscher bestätigten, dass diese RCE-Kette sowohl bei lokalen als auch bei in der Cloud gehosteten Redis-Bereitstellungen zur vollständigen Systemübernahme führen kann. Der Angriff läuft typischerweise in mehreren Phasen ab:

1. Erste Ausnutzung: Der Angreifer sendet ein bösartiges Lua-Skript, um den Fehler auszulösen.
2. Umgehung der Sandbox: Das Skript wird außerhalb der Interpreter-Einschränkungen von Redis ausgeführt.
3. Persistenz: Der Angreifer richtet eine Reverse Shell für dauerhaften Zugriff ein.
4. Systemübernahme: Es kommt zu Datendiebstahl, Kryptomining oder der Bereitstellung von Ransomware.
5. Laterale Bewegung: Gestohlene Zugangsdaten werden verwendet, um in weitere Systeme einzudringen.

Maßnahmen zur Verringerung des Ausnutzungsrisikos

Um sich gegen eine mögliche Ausnutzung von CVE-2025-49844 zu schützen und die allgemeine Sicherheit zu erhöhen, sollten Unternehmen die folgenden mehrschichtigen Maßnahmen umsetzen, die Patching, Konfiguration, Zugriffskontrolle und Laufzeitschutz abdecken.

• Den neuesten Redis-Patch anwenden und Redis sowie alle Module regelmäßig aktualisieren.
• Authentifizierung aktivieren und die Transport-Layer-Security-(TLS)-Verschlüsselung einsetzen, um Zugriff und Daten während der Übertragung zu sichern.
• Netzwerkzugriff beschränken: Redis an localhost oder vertrauenswürdige Schnittstellen binden, in isolierten virtuellen privaten Clouds (VPCs) und Subnetzen segmentieren und dann den Zugriff beschränken.
• Konfiguration härten durch Deaktivieren oder Umbenennen riskanter Befehle (z. B. EVAL, CONFIG, MODULE LOAD) sowie durch Einschränken oder Deaktivieren von Lua-Scripting, sofern dieses nicht benötigt wird.
• Redis-Aktivitäten überwachen und protokollieren auf verdächtige Befehle, ausgehende Verbindungen oder nicht autorisierte Skriptausführung; in ein Security Information and Event Management (SIEM) und Endpoint Detection and Response (EDR) zur Alarmierung integrieren.
• Redis mit minimalen Berechtigungen in einem Nicht-Root-Konto ausführen, Laufzeitsicherheitstools implementieren und getestete Backups für eine schnelle Wiederherstellung vorhalten.

Durch die Kombination dieser Maßnahmen können Unternehmen die Angriffsfläche von Redis verringern, Möglichkeiten für laterale Bewegungen einschränken und im Falle einer Kompromittierung eine schnellere Erkennung und Wiederherstellung sicherstellen.

Die über RediShell hinausgehenden Lehren

RediShell zeigt, wie veraltete Codebasen latente Schwachstellen bergen können, die über mehrere Generationen von Infrastrukturen hinweg bestehen bleiben. 

Dieser Vorfall unterstreicht die Notwendigkeit kontinuierlicher Codeprüfungen und sicherer Konfigurationspraktiken – insbesondere in Cloud-Umgebungen, in denen Geschwindigkeit häufig stärker gewichtet wird als Sorgfalt.

Diese Schwachstelle signalisiert zudem eine zunehmende Veränderung der Bedrohungslandschaft: Angreifer nehmen immer häufiger grundlegende Open-Source-Komponenten ins Visier, die groß angelegte Cloud-Operationen ermöglichen. Ein einziger Fehler in der Software-Lieferkette kann mehrere Unternehmen beeinträchtigen.

Schwachstellen wie die in Redis zeigen, dass echte Abwehr weiter oben ansetzen muss – mit strengeren Kontrollen und besserer Transparenz entlang der gesamten Software-Lieferkette.