Die Sicherheitsverantwortlichen von Redis haben Updates fuer die kritische Schwachstelle CVE-2025-49844 veroeffentlicht. Die Luecke erreicht eine CVSS-Bewertung von 10,0 und geht auf einen seit rund 13 Jahren bestehenden Fehler zurueck. Ausgeloest wird sie durch eine use-after-free-Bedingung im Zusammenhang mit dem standardmaessig aktivierten Lua-Scripting, was im schlimmsten Fall zu Remote Code Execution (RCE) auf dem Host fuehren kann.
Technische Einordnung: Use-after-free und Sandbox-Escape ueber Lua
Angreifer mit gueltigen Anmeldedaten koennen einen speziell gestalteten Lua-Skriptaufruf gegen einen Redis-Server richten. Dadurch laesst sich die Sandbox des Scripting-Engines umgehen und ein use-after-free triggern. Das Ergebnis: Code-Ausfuehrung jenseits des isolierten Skriptkontexts – bis hin zu einem Reverse Shell auf dem Host.
Forschende von Wiz haben die Schwachstelle als “RediShell” bezeichnet und die Ausnutzung bei Pwn2Own Berlin 2025 demonstriert. Nach ihrer Analyse liegt die Ursache im zugrunde liegenden Lua-Interpreter, wodurch alle unterstuetzten Redis-Versionen betroffen sind, sofern Lua-Scripting aktiviert ist.
Angriffsoberflaeche: Internet-Exposition und fehlende Authentifizierung
Obwohl grundsaetzlich Authentifizierung erforderlich ist, zeigt eine Internetstudie von Wiz rund 330.000 oeffentlich erreichbare Redis-Instanzen, davon mindestens 60.000 ohne jegliche Zugangskontrolle. In diesen Konfigurationen faellt die Eintrittsbarriere faktisch weg. Fehlende Netzsegmentierung und schwache Standardkonfigurationen verstaerken die Exposition weiter.
Auswirkungen auf Unternehmen und Cloud-Umgebungen
Ein erfolgreicher Exploit von CVE-2025-49844 ermoeglicht das Abgreifen von Zugangsdaten, das Nachladen von Malware, die Exfiltration sensibler Daten aus Redis-Speicher und -Cache sowie Lateral Movement im Netzwerk. In Cloud- und Container-Umgebungen steigt das Risiko, Berechtigungen bis auf Container- und Orchestrierungs-Ebene auszuweiten, insbesondere dort, wo Redis als Cache, Message-Broker oder Session-Store in kritischen Workloads dient.
Sofortmassnahmen und Härtung: Was jetzt zu tun ist
Patch-Management mit Prioritaet
Updates umgehend einspielen – zuerst auf Internet-exponierten Knoten und Systemen mit hohem Schutzbedarf. Schliessen Sie Produktions-, Test- und CI/CD-Umgebungen ein, um Ausweichvektoren zu verhindern. Orientierung bieten Herstellerhinweise und der CVE-Eintrag; halten Sie Versionsstaende dokumentiert und automatisieren Sie, wo moeglich, die Verteilung.
Konfiguration absichern
Authentifizierung und ACLs aktivieren und schwache/fehlende Passwoerter vermeiden. Auf exponierten Systemen nach Moeglichkeit Lua-Scripting deaktivieren und nicht benoetigte Kommandos einschränken. Redis als Dienst mit geringsten Rechten betreiben (nicht als root), umfassendes Logging und Audit einschalten.
Netzwerk und Monitoring staerken
Zugriff nur aus vertrauenswuerdigen Segmenten erlauben: Firewalls, Zugriffskontrolllisten, VPC-Isolation. Redis vorzugsweise an interne Interfaces binden und direkten Internetzugang vermeiden. Erkennungsregeln fuer Auffaelligkeiten definieren: ungewoehnliche Lua-Aktivitaet, neue oder unerwartete ausgehende Verbindungen (Indikator fuer Reverse Shell), atypische Befehlsfolgen oder Speicheroperationen.
Kontext und Quellenlage
Die Bezeichnung RediShell sowie die erfolgreiche Vorfuehrung bei Pwn2Own Berlin 2025 stammen von Wiz. Die Redis-Maintainer haben Sicherheitsupdates bereitgestellt und verweisen in ihren Advisories auf die Tragweite des Fehlers. Als Referenzen gelten der CVE-Eintrag, die Redis Security Advisories sowie die oeffentlich kommunizierten Forschungsergebnisse von Wiz. In der Praxis decken sich die Empfehlungen mit gaengigen Vorgaben aus NIST-orientierten Kontrollkatalogen (Least Privilege, Netzwerksegmentierung, kontinuierliches Monitoring).
Organisationen sollten jetzt eine Bestandsaufnahme aller Redis-Instanzen vornehmen, Patches priorisiert einspielen, oeffentliche Erreichbarkeit abschalten, wo nicht erforderlich, und Lua auf exponierten Systemen deaktivieren. Konsequente Härtung, sauberes Patch-Management und engmaschiges Monitoring reduzieren die Wahrscheinlichkeit einer Kompromittierung und begrenzen im Ernstfall die Auswirkungen von Lateral Movement deutlich.
