32体のKimi K3エージェントが協調してRedisのメモリ脆弱性を発見、公式が複数のバージョンブランチを修正

Bera Buddiesの研究者Chaofan Shouは、Moonshot Kimi K3を用いた自動脆弱性研究の成果を公開した。32体の専門エージェントが並行してRedisのソースコードを複製し、fuzz harnessを構築してデバッグツールを組み込み、GDBでクラッシュの根本原因を追跡した。チームは約90分で未知の問題を19件発見し、そのうちRedis 8.8.0を対象とする完全なエクスプロイトチェーンは27分で構築されたと主張している。公開リポジトリには、Redis 6.2.22、7.4.9、8.6.4、8.8.xを対象とする複数の非破壊的なPoCも収録されている。

主な攻撃対象領域は、`RESTORE`による信頼できないシリアライズ済みデータの処理に集中している。研究者が説明した経路の一つはStreamsのconsumer groupに関係する。細工されたデータによって2つの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体のエージェントによる完全なオーケストレーションを再現することもできない。今後の評価では、ツール実行の全トレース、人間が与えたプロンプト、失敗した試行、推論コストの総額を記録し、これが再現可能なサイバーセキュリティ・ワークフローなのか、それとも選別された成功事例なのかを見極める必要がある。