Die Entwickler der In-Memory-Datenbank Redis haben eine Sicherheitslücke darin geschlossen. Sie ermöglicht Angreifern, beliebigen Schadcode auszuführen.
Im Github-Repository von Redis findet sich ein Schwachstelleneintrag, der die Sicherheitslücke erörtert. Demnach können Nutzerinnen und Nutzer den Befehl XACKDEL mit mehreren IDs aufrufen und dadurch einen Stack-basierten Pufferüberlauf auslösen. Das wiederum kann zur Ausführung von zuvor eingeschleustem Code führen (CVE-2025-62507, CVSS zwischen 7.7 und 9.8, Risiko "hoch" bis "kritisch"). Das Problem liegt darin, dass der Redis-Code den Fall nicht abfängt, wenn die Anzahl an IDs über die STREAMID_STATIC_VECTOR_LEN hinausgeht. Dadurch überspringt er eine Reallokation, die schließlich in den Stack-basierten Pufferüberlauf mündet.
Die Redis-Entwickler rechnen einen CVSS4-Wert von 7.7 aus, was einem hohen Risiko entspricht. Die SUSE-Maintainer kommen hingegen auf CVSS4 9.3 respektive CVSS3.1 9.8, beides der Risikostufe "kritisch" entsprechend.
Das Problem tritt ab Redis 8.2 auf. Die Version 8.2.3 und neuere enthalten den Fehler hingegen nicht mehr. Admins, die Redis einsetzen, sollten auf diese oder neuere Fassungen der Datenbank aktualisieren. Wer das Update noch nicht durchführen kann, sollte temporäre Gegenmaßnahmen einleiten. Die Redis-Programmierer erklären, dass Nutzerinnen und Nutzer von der Ausführung des anfälligen Befehls XACKDEL ausgeschlossen werden können. Dazu lässt sich der Zugriff auf den Befehl mittels ACL (Access Control List) beschränken.
Vor rund vier Wochen haben die Programmierer bereits eine als kritisches Risiko eingestufte Sicherheitslücke in Redis geschlossen. Mit sorgsam präparierten LUA-Skripten war es möglich, eine Use-after-free-Situation zu provozieren und dabei eingeschleusten Programmcode auszuführen. Das hat die Vorversion 8.2.2 von Redis korrigiert.
(
Sie haben heise+ bereits abonniert? Hier anmelden.
Oder benötigen Sie mehr Informationen zum heise+ Abo
Kommentare