Forscher Chaofan Shou sagt, er habe einen von Moonshot’s Kimi K3 angetriebenen Agentenschwarm auf Redis gerichtet und nach etwa 90 Minuten 19 zero-days erhalten. Ein zweiter Durchlauf benötigte 27 Minuten, um einen funktionierenden Remote-Code-Execution-Exploit gegen Redis 8.8.0 zu erzeugen. Hier gibt es kein Produkt zu kaufen – es ist eine Sicherheits‑Demo, und das ist der Grund, warum die KI‑Community ausflippt.
Was die Agenten tatsächlich taten
Kimi K3 orchestrierte 32 spezialisierte Agenten: den Quellcode klonen, Fuzzer erzeugen, den Build instrumentieren, Abstürze in GDB debuggen und dann den Absturz zu einem Exploit verketten. Die wichtigsten Fehler sind ein Stream‑NACK‑Double‑Free (trefft 6.2.22, 7.4.9, 8.6.4), das einem authentifizierten Client stabile Code‑Ausführung ermöglicht, und ein TDigest‑Heap‑Overflow, das standardmäßig in 8.8.0 ausgeliefert wird – eine frische Instanz reicht aus, um zu eskalieren. Beide nutzen EVAL, RESTORE und XGROUP, Befehle, die in internen Netzwerken offen stehen.
Warum das wichtig ist
Autonomes Bug‑Hunting wird immer günstiger. Ein Open‑Weights‑Modell, das in weniger als einer halben Stunde von einem Crash‑zu‑RCE gelangt, stellt ein anderes Bedrohungsmodell dar als die Fuzzer vom letzten Jahr.
Ein Hinweis, den man im Auge behalten sollte: Die Zahlen, Zeitangaben und die Unabhängigkeit der Agenten sind alle selbst gemeldet. Die Juli‑23‑Fixes von Redis bestätigen, dass die Schwachstellen existieren; sie bestätigen nicht die Stoppuhr.