KIberblick

19 Redis-Lücken per KI: was wirklich belegt ist

Ein Forscher fand mit Kimi K3 angeblich 19 Redis-Zero-Days in 90 Minuten. Redis hat gepatcht. Wir trennen Beleg von Behauptung.

Entwickler:inQA / Tester:inProduct Owner
26. Juli 20268 Min. Lesezeit

Die Schlagzeile klingt nach einem Wendepunkt: Ein Forscher will mit dem chinesischen Modell Kimi K3 in 90 Minuten 19 Zero-Days in Redis gefunden haben, ein zweiter Lauf habe in 27 Minuten einen funktionierenden Exploit produziert. Redis hat kurz darauf gepatcht. Das ist ein echter Vorgang mit echten Fixes, und trotzdem lohnt es sich, Beleg und Behauptung sauber auseinanderzuhalten. Wer bei KIberschutz mitliest, kennt den Grund: Der Unterschied zwischen "gefunden" und "verifiziert gemeldet" ist genau der Teil, der zählt.

Was passiert ist

Der Forscher Chaofan Shou (auf X als @Fried_rice) berichtete am 22. Juli, er habe Kimi K3 auf die Redis-Codebasis angesetzt. Nach seiner Darstellung koordinierte das Modell rund 32 spezialisierte Agenten, die den Quellcode klonten, Fuzzer generierten, die Software instrumentierten, Abstürze mit dem Debugger analysierten und am Ende einen funktionsfähigen Exploit bauten. Er veröffentlichte die Proof-of-Concept-Skripte in einem GitHub-Repository.

Redis reagierte schnell. Am 23. Juli erschien eine ganze Reihe von Sicherheitsreleases: 6.2.23, 7.2.15, 7.4.10, 8.2.8, 8.4.5, 8.6.5 und 8.8.1. Die Release-Notes benennen zwei Fehlerklassen. Die eine ist ein Use-after-free über eine präparierte Stream-RESTORE-Payload, bei der sich zwei Consumer denselben NACK teilen. Die andere sind Out-of-Bounds-Writes in den Modulen RedisBloom und TDigest, ebenfalls über manipulierte RESTORE-Payloads. Beide können im schlimmsten Fall zu Remote Code Execution führen.

Was belegt ist und was nicht

Hier beginnt die Sorgfalt. Belegt ist: Die Lücken existieren, und Redis hat sie gepatcht. Das steht in den offiziellen Release-Notes und lässt sich nachlesen.

Nicht belegt ist der Rest der Schlagzeile. Die Zahl 19, die Zeitangaben und der behauptete Grad an Autonomie sind selbstberichtet. Weder Redis noch Moonshot, die Firma hinter Kimi K3, haben sie unabhängig bestätigt. Das öffentliche PoC-Repository dokumentiert nicht 19 Lücken, sondern vier konkrete Exploits. Und zwei davon sind streng genommen keine neuen Lücken, sondern Umgehungen bereits gepatchter CVEs vom Mai 2026 (CVE-2026-25243 und CVE-2026-25589). Das ist nicht wertlos, im Gegenteil: Einen unvollständigen Fix zu durchbrechen, ist eine ernstzunehmende Leistung. Aber es ist etwas anderes als "19 frische Zero-Days".

Der wichtigste Kontext: es ist authentifiziert

Ein Punkt fehlt in den meisten Schlagzeilen und entscheidet über die reale Gefahr: Alle vier Exploits setzen einen authentifizierten Zugriff voraus. Die PoC-Skripte brauchen die Befehle EVAL, RESTORE und XGROUP, also einen bereits angemeldeten Client mit weitreichenden Rechten.

In der Hacker-News-Diskussion bringt es der meistbeachtete Kommentar auf den Punkt: Wer authentifizierten Admin-Zugriff auf Redis hat, kann ohnehin Schaden anrichten, denn Redis war nie als Sicherheitsgrenze zwischen authentifizierten Nutzern gedacht. Ein Redis-Server gehört nicht ins offene Internet, und wer ihn korrekt betreibt, gibt RESTORE- und EVAL-Rechte nicht an nicht vertrauenswürdige Clients.

Das relativiert die Dringlichkeit erheblich, hebt sie aber nicht auf. Speicherfehler in einer authentifizierten Fläche sind trotzdem Fehler, und es gibt Szenarien, in denen sie zählen: mandantenfähige Umgebungen, in denen mehrere Parteien auf dieselbe Redis-Instanz zugreifen, oder eine Rechteausweitung, bei der ein Angreifer bereits eingeschränkten Zugriff hat und ihn zu Codeausführung ausbaut. Redis hat die Lücken zu Recht gepatcht. Die richtige Einordnung ist nur: dringender Handbrand ist es für die meisten Installationen nicht.

Ein Detail verdient noch Aufmerksamkeit. Das PoC-Repository behauptet, einer der Exploits umgehe auch den Fix in 8.8.1 und funktioniere weiter. Das ist die Behauptung des Forschers und zum jetzigen Zeitpunkt nicht unabhängig verifiziert; ein Redis-Release über 8.8.1 hinaus gibt es öffentlich noch nicht. Wer produktiv Redis mit den Modulen RedisBloom oder TDigest betreibt, sollte die Advisory-Kanäle von Redis im Auge behalten.

Was Teams jetzt konkret tun

Warum wir das so genau nehmen

Die Genauigkeit ist kein Selbstzweck. Bei KIberblick betreiben wir mit KIberschutz selbst KI-gestützte Schwachstellensuche in Open-Source-Projekten, und dabei lernt man schnell, wo der eigentliche Aufwand steckt. Nicht im Finden. Ein Modell auf eine Codebasis anzusetzen und eine Liste verdächtiger Stellen zu bekommen, ist der einfache Teil. Der schwere Teil kommt danach: Jeder Fund muss verifiziert werden, oft adversarial, also mit dem ausdrücklichen Versuch, ihn zu widerlegen. Viele plausibel klingende Funde halten dieser Prüfung nicht stand.

Genau deshalb sind uns die Zahlen dieses Falls wichtig. Aus "19 gefunden" werden bei genauem Hinsehen vier belegte PoCs, davon zwei Bypässe. Das ist kein Vorwurf an den Forscher, dessen Arbeit an den Patch-Bypässen technisch beachtlich ist. Es ist eine Illustration des Musters, das wir bei jedem eigenen Scan sehen: Die Bruttozahl der Kandidaten und die Nettozahl der bestätigten, sauber gemeldeten Lücken sind zwei verschiedene Dinge. Wir haben das breiter aufgeschrieben, als die Meldungen durch KI-Schwachstellensuche im Juni um das 3,5-Fache stiegen: Der Engpass ist nicht das Finden, sondern das verantwortungsvolle Verifizieren, Melden und Patchen.

Wie das im guten Fall aussieht, zeigt unser Fall bei Speakr, wo aus vier sauber gemeldeten Funden binnen Stunden vier Fixes wurden. Der Unterschied zum Redis-Fall liegt nicht in der Technik, sondern im Verfahren: erst verifizieren, dann verantwortungsvoll melden, statt eine Bruttozahl in die Timeline zu stellen.

Fazit

Kimi K3 hat, mit einem fähigen Forscher am Steuer, reale Speicherfehler in Redis aufgedeckt, und Redis hat sauber und schnell gepatcht. Das ist die gute Nachricht, und sie ist echt. Die Schlagzeile darüber ist trotzdem größer als der Beleg: vier belegte, authentifizierte PoCs statt 19 frischer Zero-Days, und zwei davon sind Umgehungen bekannter Lücken. Für Teams heißt das erstens: patchen, aber ohne Panik, sofern Redis nicht öffentlich hängt. Und zweitens: Dieselbe KI-Fähigkeit, die hier Lücken fand, lässt sich zum Absichern nutzen. Was den Unterschied macht, ist nicht das Modell, sondern die Sorgfalt dessen, der es bedient.

Quellen5