Die jetzt ausgelieferten Korrekturen verteilen sich auf mehrere Versionszweige. Redis 6.2.23, 7.2.15 und 7.4.10 beheben den Streams-Fehler mit gemeinsam genutzten NACK-Einträgen und Use-after-free. Redis 8.2.8, 8.4.5 und 8.6.5 schließen sowohl dieses Streams-Problem als auch die Out-of-bounds-Schreibfehler in RedisBloom und TDigest. Redis 8.8.1 behebt die Loader in RedisBloom und TDigest; die Schutzmaßnahme für Streams war laut Redis in 8.8.0 bereits vorhanden.
Brisant ist dabei, dass zwei der in den PoCs angegriffenen Ziele, Redis 6.2.22 und 7.4.9, genau jene Sicherheitsupdates vom Mai waren, die Redis Nutzern zuvor zur Installation empfohlen hatte. Diese Releases enthielten jedoch nicht die Schutzprüfung gegen doppelte Eigentümerschaft bei den gemeinsam genutzten NACK-Einträgen.
Der erste Angriffsweg steckt in Redis Streams. Ein manipuliertes RDB-Objekt kann dazu führen, dass zwei Consumer auf denselben Pending-Entry-Datensatz zeigen, der intern als streamNACK repräsentiert wird. Wird der erste Consumer entfernt, wird das Objekt freigegeben, während der zweite einen hängenden Zeiger behält. Entfernen die Skripte anschließend auch den zweiten Consumer, wird derselbe Speicherbereich ein zweites Mal freigegeben. Der veröffentlichte Code soll die daraus resultierende Speicherbeschädigung in beliebigen Speicherzugriff und letztlich in einen Aufruf von system() umwandeln.
Für Redis 8.6.4 verweisen die Release Notes auf PR #15081. Eine Quellcodeprüfung durch The Hacker News ergab jedoch, dass der als 8.6.4 markierte Quelltext die mit dieser Änderung eingeführte Prüfung auf doppelte Eigentümerschaft nicht enthält. Diese Schutzmaßnahme taucht laut dem Bericht erst in Redis 8.6.5 auf, das am 23. Juli veröffentlicht wurde. Das veröffentlichte Skript für Redis 8.6.4 soll die Double-free-Situation in beliebigen Speicherzugriff verwandeln, dann eine Hash-Funktion der Datenbank manipulieren, sodass ein präpariertes GET system() aufruft. Anschließend stellt es den Zeiger wieder her und prüft, ob Redis weiter antwortet.
Der zweite Pfad liegt im TDigest-RDB-Loader von RedisBloom. Dort wurde Speicher für Centroid-Arrays anhand eines serialisierten Kompressionswerts reserviert, beim Einlesen aber einem separaten, vom Angreifer kontrollierten Kapazitätsfeld vertraut. Eine kleine tatsächliche Allokation zusammen mit aufgeblähter Metadaten-Kapazität führt so zu einem Out-of-bounds-Write. Redis’ Juli-Fix verlangt deshalb, dass die geladene TDigest-Kapazität zur aus dem Kompressionswert abgeleiteten Allokation passt, und begrenzt zusätzlich die Zähler für zusammengeführte und nicht zusammengeführte Knoten, bevor die Arrays gelesen werden.
Das Skript für Redis 8.8.0 soll diesen Schreibfehler in Lese- und Schreibprimitive umwandeln, Redis- und libc-Adressen offenlegen und anschließend ebenfalls eine Hash-Funktion der Datenbank so manipulieren, dass ein präpariertes GET system() aufruft. Ein separates Proof of Concept veröffentlichte laut Bericht dieselbe Grundursache und eine authentifizierte RCE-Kette gegen Redis 8.8.0.
Bei der Kennzeichnung der Schwachstellen gibt es Unschärfen. Das Repository bezeichnet das Streams-Problem als Teil einer „unvollständigen Fix-Familie“ zu CVE-2026-25589, Redis ordnet diese CVE jedoch der Speicherbeschädigung in RedisBloom bei RESTORE zu, nicht dem Streams-Fehler mit gemeinsam genutzten NACKs. In den Release Notes vom Juli nennt Redis weder eine CVE noch einen CVSS-Wert für die beiden neuen Fehlerklassen. Laut The Hacker News gab es bis zum 24. Juli auch keinen separaten NVD-Eintrag für die neuen Streams- oder TDigest-Befunde; im NVD waren weiterhin nur die Mai-Einträge zu CVE-2026-25243 und CVE-2026-25589 gelistet. Eine Suche im Katalog der Known Exploited Vulnerabilities von CISA ergab keinen Eintrag für einen der beiden Bezeichner.
Der Fall folgt auf eine weitere, im Mai gepatchte Redis-RCE-Schwachstelle, die laut Bericht ebenfalls von KI entdeckt wurde. Bera Buddies beschreibt sich selbst als „Forschung mit KI-Agenten“. Chaofan Shou schrieb auf X, Kimi-K3-Agenten hätten in rund 90 Minuten 19 Redis-Zero-Days gefunden; ein weiterer Durchlauf habe den Exploit für Redis 8.8.0 in 27 Minuten hervorgebracht. Diese Zahlen, Zeitangaben und der behauptete Autonomiegrad sind jedoch laut Bericht Selbstauskünfte. Bestätigt sind öffentlich nur die Schwachstellen und die bereitgestellten Korrekturen, nicht die behauptete Anzahl der Zero-Days oder wie unabhängig die Agenten dabei arbeiteten.