Redis Server で発見された脆弱性の悪用経路：Kimi K3 AI Agent が問題点を検出

New Kimi K3 AI Agent Uncovers 0-Day Exploits in Redis Server

2026/07/23 CyberSecurityNews — 世界で最も広くデプロイされているインメモリ・データストアの 1 つである Redis に、複数の認証済みリモートコード実行 (RCE) の経路が存在することが、Kimi K3 AI エージェントを用いた研究により明らかになった。研究者 alias Bera Buddies が共有した調査結果は、Redis 6.2.22／7.4.9／8.6.4／8.8.0／8.8.1 の標準ビルドを対象とするものである。この攻撃経路では、stream consumer-group の shared-NACK ダブル・フリーの問題と、同梱される RedisBloom TDigest モジュール別のヒープ・オーバーフローが組み合わされている。

Kimi K3 AI Agent がゼロデイを発見

研究者たちが説明しているのは、公式 Redis Docker イメージに対する非破壊的な RCE である。関係するバグ・クラスは 2 種類である。

  • Stream NACK double-free (CVE-2026-25589 incomplete-fix family)：バージョン 6.2.22／7.4.9／8.6.4 に影響する。stream consumer group の shared-NACK パスは、同じヒープ・チャンクをダブル・フリーするため、認証済みクライアントにコード実行のための信頼性の高いプリミティブが与えられる。
  • TDigest heap overflow／TopK wild free (RedisBloom に同梱)：Redis 8.8.0 では NACK 問題が対処されている (PR #15081)。しかし、RedisBloom に含まれる TDigest のヒープ・オーバーフローにより Redis 8.8.0 で認証済み RCE が可能となる。また、Redis 8.8.1 では、TopK wild free により認証済み RCE が可能となる。

いずれの経路も、内部デプロイメントにおいて有効な状態で放置されることが多いコマンドである、EVAL／RESTORE／XGROUP などが必要となる。バージョン 8.8.0／8.8.1 では、デフォルトで同梱される RedisBloom モジュールも必要になる。

Redis はパスワードを備えているが、コマンド・サーフェス全体が利用可能な状態で、アプリケーション層の背後に配置されることが多い。したがって、シークレット漏洩／SSRF／ミスコンフィグ・ネットワーク ACL を通じて認証情報を取得した攻撃者は、データストア・アクセスからホストレベルのシェルへの移行を可能にする。ただし、その過程において、攻撃に見える形でサービスがクラッシュするとは限らない。

この研究が強調するのは、shared-NACK double-free が、バージョン 8.8.0 でようやく修正されたことだ。したがって、このパッチが適用されていない環境では、依然として弱点が露出したままとなる。その一方で、バージョン 8.8.0／8.8.1 が完全に安全というわけではない。この情報が開示された時点で説明されているのは、同梱モジュール内に、Redis 8.8.0 では TDigest のヒープ・オーバーフロー、Redis 8.8.1 では TopK wild free が未修正で存在する状況である。

バージョン 8.8.0 の TDigest 経路および 8.8.1 の TopK wild free 経路は、決定論的な jemalloc レイアウトを構築する構造体 spraying に依存している。そのため、成功率が最も高いのは、並行トラフィックが最小限である新規のインスタンスとなる。この条件は、多くのラボ／CI／軽負荷の本番 pod と一致する。

影響を受けるバージョンの概要
Redis versionRoot causeNotes
6.2.22Stream NACK double-freeOfficial-image offsets; other builds need calibration
7.4.9Stream NACK double-freeStock image; no debug flag required
8.6.4Stream NACK double-freeStock image; no debug flag required
8.8.0TDigest heap overflow (RedisBloom)NACK fixed; module bug separate
8.8.1TopK wild free (RedisBloom)Bypass of CVE-2026-25589 fix

悪用後の痕跡として、無害化されたキーや破損した構造体が残る可能性がある。運用者に求められるのは、侵害された 8.8.0 ホスト上において残存状態を理解しない状態で、FLUSHALL/SAVE を不用意に実行しないことである。なお、8.8.1 の TopK wild free 経路についても、PoC では悪用後の残存データが生じる可能性があるため、同様の注意が求められる。

防御側への要点

ベンダーのパッチが、すべてのブランチと RedisBloom モジュールをカバーするまでの間は、以下の手順が求められる。

  1. 修正済み Redis ビルドが公開され次第、アップグレードする。RedisBloom の TDigest または TopK が依然として脆弱である場合には、8.8.0／8.8.1 が完全に安全だと想定してはならない。
  2. EVAL／RESTORE などの関連する管理プリミティブについて、rename-command で危険なコマンドを制限するか、Redis ACL を使用してアプリ・ユーザーに対して拒否する。
  3. ネットワークを分離する。Redis をプライベート・インターフェイスにバインドし、ポート 6379 をインターネットに露出させない。
  4. 強力な認証とシークレット衛生を徹底する。一意のパスワードを使用し、デフォルト認証情報を使わず、漏洩が疑われる場合にはローテーションを行う。
  5. モジュールを監査する。未使用の RedisBloom/TDigest を無効化またはアンロードする。
  6. 異常な XGROUP/RESTORE/EVAL の使用と、データ・ディレクトリ配下の予期しないキーを監視する。

Kimi K3 に関連する研究が浮き彫りにするのは、現状の厳しさである。AI 支援型の脆弱性発見は加速しており、Redis のような中核インフラは依然として高価値の標的となっている。不完全な修正や同梱モジュールを介した認証済み RCE が意味するのは、パスワードの設定だけでは完全なセキュリティ戦略にならないことである。

Redis 6.2〜8.8.1 を実行している組織は、バージョンをインベントリし、コマンド・サーフェスをロックダウンし、完全な修正に向けて公式 Redis および RedisBloom のアドバイザリを追跡すべきである。

訳者後書：インメモリ・データストアである Redis において、特定の処理や拡張機能の不具合によりメモリ構造が崩れ、認証を得た第三者に不正な指令を実行される脆弱性 CVE-2026-25589 が公表されました。この脆弱性の発見に貢献したのは、Kimi K3 AI エージェントです。権限を持つ利用者の情報が第三者に渡り、この脆弱性が悪用されると、端末の操作権を奪われる危険性が生じます。安全に利用するためにも、公式に提供される修正プログラムを追跡して迅速に導入し、不要なコマンドの利用制限やネットワークの適切な隔離などを実施する必要があります。