AI security research
32 個 Kimi K3 代理協作挖掘 Redis 記憶體漏洞，官方修補多條版本分支
研究者宣稱以 32 個 Kimi K3 代理自動產生 fuzz harness、分析崩潰並建立 Redis 遠端執行程式碼 PoC，最快一條攻擊鏈在 27 分鐘內完成。Redis 已修補相關 `RESTORE` 記憶體問題，但攻擊需要有效憑證與特定命令權限，代理自主程度及「19 個零日」仍主要來自研究者自述。
Bera Buddies 研究者 Chaofan Shou 公布一項以 Moonshot Kimi K3 執行的自動化漏洞研究：32 個專門化代理同時複製 Redis 原始碼、建立 fuzz harness、插入偵錯工具，並以 GDB 追查崩潰根因。團隊宣稱約 90 分鐘內找出 19 個先前未知問題，其中針對 Redis 8.8.0 的完整利用鏈在 27 分鐘內形成；公開儲存庫則提供數個非破壞性 PoC，涵蓋 Redis 6.2.22、7.4.9、8.6.4及8.8.x。
主要攻擊面集中在 `RESTORE` 對不可信序列化資料的處理。研究者描述的其中一條路徑涉及 Streams consumer group：特製資料可能令兩個 consumer 共用 pending-entry 結構，釋放其中一方後留下懸空指標，形成 double-free 或 use-after-free。另一條位於隨 Redis 發布的 RedisBloom 元件，惡意 TDigest 資料在還原期間可能觸發 heap buffer overflow。Redis 官方文件也列出 CVE-2026-25588 與 CVE-2026-25589，確認經特製 `RESTORE` 輸入可造成無效記憶體存取，並可能進一步導致遠端執行程式碼。
這不是無需登入、可直接掃描網際網路的蠕蟲型漏洞。攻擊者必須先取得 Redis 身分驗證，並獲准使用 `RESTORE`；部分 Streams 路徑還需要 `EVAL` 和 `XGROUP`。然而，低權限憑證若能升級為原生程式碼執行，仍會改變威脅模型。Redis 已在 7 月 23 日發布 6.2.23、7.2.15、7.4.10、8.2.8、8.4.5、8.6.5及8.8.1等修補版本，營運者應升級並收緊危險命令的 ACL。
更值得觀察的是方法本身：代理已能串起產生測試、編譯、除錯與 PoC 驗證，而非只做靜態程式碼問答。不過「19 個零日」、耗時與人類介入程度尚未獲 Redis 或 Moonshot 獨立確認；公開成果也不足以重建完整 32 代理編排。後續評估應記錄每次工具軌跡、人工提示、失敗嘗試與總推論成本，才能判斷這是可重現的資安工作流，還是經挑選的成功案例。