Redis脆弱性CVE-2026-66373｜AIが発見した0dayを自分のRedisで確認する実行コマンド

CVE-2026-66373 は、Redis の stream に見つかった二重解放の脆弱性である。2026年7月23日、Redisはこの Redis 脆弱性を含む7本のセキュリティリリース（6.2.23 / 7.2.15 / 7.4.10 / 8.2.8 / 8.4.5 / 8.6.5 / 8.8.1）を、2時間足らずのあいだに立て続けに公開した。中身は stream の RESTORE ペイロードによる use-after-free と、RedisBloom/TDigest の境界外書き込みの2つである。前者には2日後の7月25日に CVSS v3.1 7.5 HIGH / CWE-415 が割り当てられたが、リリース当日のノートにはCVE番号もCVSSスコアも書かれていなかった。

きっかけは、Moonshot AIの Kimi K3 を使ったエージェント群がRedisの0dayを自動で見つけ、エクスプロイトまで書いたという研究者の投稿だった。ただしその「19件・90分」という数字は自己申告で、第三者検証はされていない。本記事は検証できる事実（Redis公式リリース、修正コミットの実際の差分、NVDの登録内容）と未検証の主張（発見件数・所要時間・自律性）を分けて整理し、最後に自分のRedisを確認する実行コマンドまで持っていく。

サプライチェーン全体での依存関係の追い方と、CVE公開前後の対応フローの整理は サプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリスト にまとめている。

何が起きたのか — CVE-2026-66373 公表までの時系列

まず、確認できる日時だけを並べる。以下はすべてGitHub APIとNVD APIから取得した実測値で、表記はUTCである（日本時間は+9時間）。

この並びで目を引くのは2点ある。

ひとつは7月23日のリリース密度だ。6.2.23 の公開が17:52、最後の 8.8.1 が19:30。1時間38分のあいだに7本のRedis本体リリースと3本のRedisBloomリリースが出ている。Redisが5月に5件のCVEをまとめて出したときは事前に調整されたアドバイザリブログが伴っていたが、今回はリリースノートのみで、公式ブログでの解説記事は確認できていない。

もうひとつはCVE番号が後から来たことだ。7月23日のリリースノートには、CVE-IDもCVSSスコアも書かれていない。7.4.10のリリースノートは全文でこれだけである。

Update urgency: SECURITY: There is a security fix in the release.
Security fixes
A crafted stream RESTORE payload can make two consumers share the same NACK, leading to a use-after-free that may result in Remote Code Execution

CVE-2026-66373がNVDに登録されたのは、その約2日後の7月25日01:16 UTCだ。しかもNVD上のステータスは執筆時点で Received（受領済み・NVDによる解析待ち）で、CVSSスコアも一次評価元のNVDではなく [email protected] がSecondaryとして付けたものである。

これは今回に限った話ではない。OSSの脆弱性対応では、ベンダーのリリースノートが常にCVEデータベースより先に出る。CVEを起点にするのではなく、使っているミドルウェアのリリースフィードを直接監視することが、この2日間を埋める唯一の手段になる。

「AIが0dayを発見した」の主張と、一次ソースで確認できる事実

ここが本件でいちばん混乱しやすい部分なので、切り分けを明示する。

主張の側（第三者検証なし）

研究者 Chaofan Shou 氏がX上で公表した内容として、The Hacker News と heise online が共通して伝えているのは次の2点である。

・Kimi K3 のエージェント群が、Redis 8.8.0 に対して19件の0dayを約90分で発見したとされる
・別の実行では、Redis 8.8.0 のエクスプロイトを27分で生成したとされる

The Hacker News はこの数字について「件数、所要時間、そして主張されている自律性の度合いは、いずれも自己申告のままである」と明記している。heise online も、重大度評価とCVEエントリが当時まだ存在しないことを指摘している。

なお、エージェントの体数など、これより踏み込んだ具体的な数字も一部で流通している。ただし本記事が確認した範囲（The Hacker News、heise online、CyberSecurityNews）では裏付けが取れなかったため、扱わない。

事実の側（一次ソースで確認済み）

一方で、次はすべてAPI経由で直接確認できた。

・Redisが2026年7月23日に7本のセキュリティリリースを公開したこと（GitHub Releases API）
・各リリースノートの記述内容（前掲の引用は7.4.10の全文）
・7.4.9→7.4.10の差分で src/rdb.c が8行追加されたこと、および tests/integration/corrupt-dump.tcl に回帰テストが17行追加されたこと（GitHub Compare API）
・NVDにCVE-2026-66373が2026-07-25 01:16 UTCに登録され、CVSS 7.5 HIGH / CWE-415（Double Free）が付いていること
・PoCリポジトリ berabuddies/redis-poc が2026-07-22 22:26 UTCに作成され、執筆時点で397スターであること

CVE-2026-66373 の技術的な中身 — 共有NACKによる二重解放

NVDの記述を訳すと、脆弱性の成立条件はこうなる。

Redis 8.8.0 未満において、認証済みの攻撃者が RESTORE を実行できるという例外的なケースで、同一のNACK（保留エントリ）が複数のconsumerから参照される RESTORE ペイロードを介してリモートコード実行を許す。両方のconsumerを XGROUP DELCONSUMER で削除すると二重解放に至るためである。なお本件は CVE-2026-25243 の修正が不完全であったために存在する。

Redis Streams の consumer group は、まだACKされていないメッセージを PEL（Pending Entries List） で管理する。PELにはグローバルなものと、consumerごとのものがある。実体である streamNACK 構造体はグローバルPELが保持し、各consumerのPELは同じ構造体を指すポインタを持つ設計だ。つまり「1つのNACKは、ちょうど1つのconsumerに所有される」という不変条件がある。

RDBのロード処理は、この不変条件を信じていた。細工したRDBペイロードを RESTORE で流し込むと、consumerA と consumerB の両方のPELが同一の streamNACK を指す状態を作れてしまう。あとは両方のconsumerを消すだけでいい。

修正の中身は8行のガード

実際の修正は極めて短い。7.4.9→7.4.10の差分を取ると、変更されたのは10ファイル・7コミットで、そのうち脆弱性を直接塞いでいるのは src/rdb.c の8行の追加だけだった。

/* If the NACK already has a consumer assigned, the
 * payload is corrupt — each global PEL entry must be
 * claimed by exactly one consumer. */
if (nack->consumer != NULL) {
    rdbReportCorruptRDB("Stream consumer PEL entry already has a consumer assigned");
    decrRefCount(o);
    return NULL;
}

nack->consumer が既に埋まっていたらRDBを壊れているものとして拒否する、それだけである。あわせて tests/integration/corrupt-dump.tcl に、2つのconsumerが同じエントリを参照するstreamを作って RESTORE が失敗することを確かめる回帰テストが追加されている。

「不完全な修正」の系譜

ここで時系列に戻ると、興味深いことがわかる。このガードを追加したPR #15081は、2026年4月23日に unstable へマージされていた。7月に新しく書かれたコードではない。

NVDがCVE-2026-66373の参照として挙げているのは、このPR #15081 と、8.6.4...8.8.0 のコンペア画面である。そしてCVEの記述は「CVE-2026-25243 の修正が不完全だったために存在する」と述べている。CVE-2026-25243 は5月に公表された5件のうちのひとつで、同じく RESTORE 経由の脆弱性だった。

ただし、PR #15081そのものが「不完全な修正」だったのか、それとも「不完全な修正を完全にするもの」だったのかは、公開情報からは断定できない。NVDは参照として挙げているだけで、どちらとは書いていない。ここは推測を書かずに、確認できる事実（4月にマージ、7月に各安定版へ反映、CVEは不完全修正が原因と記述）だけを提示しておく。

CVE番号が付いていないもう一つの修正 — RedisBloom/TDigest

7月23日のリリースには、実はもう1件の脆弱性修正が含まれている。そしてこちらは執筆時点でCVE番号が存在しない。

8.8.1 のリリースノートに書かれているのは次の1行だけだ。

RedisBloom/RedisBloom#1044 Crafted RESTORE payloads in RedisBloom and TDigest may trigger out-of-bounds writes, potentially leading to remote code execution

参照されているRedisBloomのPR #1044 は「MOD-13409 Harden RDB loading（backport to 8.8）」というタイトルで、2026-07-23 17:54 UTC にマージされている。PR本文によれば、変更内容は次の3点である。

・Bloom と Cuckoo の RDB メタデータ、およびシリアライズされたバッファサイズを、確保・コピーの前に検証する
・TDigest の capacity とノードカウンタを、シリアライズされたノードを読む前に検証する
・壊れたRDBを狙った回帰テストを追加する

要するに、ヘッダに書かれた「これだけのサイズがあります」という自己申告を信じてメモリを確保していたところに、実データとの整合性チェックが入った形だ。攻撃者が capacity フィールドだけを大きく書き換えれば、確保した領域を超えて書き込める。これが境界外書き込みになる。

NVDに対して “RedisBloom” をキーワードに2026年6月1日以降を検索しても、該当するCVEは0件だった（2026年7月26日時点）。つまりこの脆弱性は、CVE番号を持たないまま修正だけが出荷されている状態にある。

なお、6.2.23 / 7.2.15 / 7.4.10 のリリースノートにはRedisBloomの記述が無い。これらの系列ではRedisBloomは本体に同梱されない独立モジュールであり、RedisBloom 2.4.26 / 2.6.31 / 2.8.23 として別途リリースされているためだ。本体を更新してもモジュールは更新されない点に注意がいる。

自分のRedisが影響を受けるか確認する

ここからは手を動かす部分になる。確認は「バージョン」「モジュール」「攻撃前提の成立可否」の3段構えで見る。

1. バージョンを確認する

# バイナリから直接
redis-server --version

# 稼働中のインスタンスに問い合わせる（推奨・実際に動いているものが分かる）
redis-cli INFO server | grep -E 'redis_version|redis_mode|os'

# Docker で動かしている場合
docker exec <container_name> redis-server --version

# Kubernetes の場合
kubectl exec <pod> -- redis-cli INFO server | grep redis_version

redis-server --version はディスク上のバイナリを見るだけなので、パッケージを更新したがプロセスを再起動していない環境では、実際に動いているバージョンと食い違う。redis-cli INFO server で稼働中の値を確認するほうが確実である。

2. 影響範囲マトリクス

得られたバージョンを次の表に当てる。

8.8系だけ挙動が違う点に注意がいる。CVE-2026-66373の記述が「Redis before 8.8.0」であるとおり、stream側は 8.8.0 で既に修正済みだ。だから 8.8.1 のリリースノートにはRedisBloomの修正しか載っていない。逆に言えば 8.8.0 を使っている環境は、stream側は安全だがRedisBloom側は影響を受ける。

3. モジュールと攻撃前提を確認する

# ロードされているモジュールとバージョンを一覧（bf = RedisBloom）
redis-cli MODULE LIST

# 認証が掛かっているか（空なら誰でも接続できる）
redis-cli CONFIG GET requirepass

# default ユーザーが RESTORE を実行できるか
redis-cli ACL GETUSER default

# 全ユーザーの権限を俯瞰する
redis-cli ACL LIST

# 外部から到達可能になっていないか
redis-cli CONFIG GET bind
redis-cli CONFIG GET protected-mode

MODULE LIST の出力に bf という名前のモジュールがあれば、それがRedisBloomである。Redis 8.x では確率的データ構造が本体に統合されているため、明示的にロードしていなくても機能が有効になっている場合がある。

ACL GETUSER default の結果に +@all や +restore が含まれていれば、認証を通った相手は RESTORE を実行できる。ここが今回の脆弱性の入口になる。

対策 — 更新先バージョンとACLによる暫定緩和

恒久対策：該当バージョンへ更新する

最優先は前掲マトリクスの「上げるべき版」への更新である。Docker で運用している場合、公式イメージのタグ選択に注意がいる。

# 現在のイメージのバージョンを確認
docker exec <container> redis-server --version

# 更新（タグを固定している場合は、その系列の最新版が出ているか確認する）
docker pull redis:8.8.1
docker pull redis:7.4.10

# 更新後、稼働中のプロセスが新版になったか必ず再確認する
docker exec <container> redis-cli INFO server | grep redis_version

マイナーバージョンで固定しているタグ（redis:8.6 など）を使っている場合、そのタグが修正版を指すように更新されているかを確認してから pull する。系列そのものがサポート外なら、更新しても修正は入らない。

RedisBloom を独立モジュールとして使っている6.2/7.2/7.4系では、本体とモジュールを別々に更新する必要がある。本体を 7.4.10 にしても、モジュールが RedisBloom 2.8.20 のままなら境界外書き込みは残る。

暫定緩和：RESTORE をACLで塞ぐ

すぐに更新できない場合、攻撃の入口である RESTORE を落とすことで時間を稼げる。

# default ユーザーから RESTORE を剥奪する
redis-cli ACL SETUSER default -restore

# stream の consumer 操作もあわせて制限する場合
redis-cli ACL SETUSER default -restore -xgroup

# 設定を永続化する（redis.conf 側にも反映が必要）
redis-cli ACL SAVE

ただしこれは応急処置であることを明確にしておきたい。RESTORE はレプリケーションやマイグレーション（MIGRATE コマンド）で内部的に使われるため、運用機能を壊す可能性がある。クラスタ構成でスロット移行を行っている環境では、事前に影響を確認してから適用する必要がある。

ネットワーク層での防御

Redisはそもそもインターネットに直接晒す設計ではない。今回を機に次を確認しておきたい。

・bind を必要なインターフェースに限定し、protected-mode yes を維持する
・requirepass または ACL による認証を必ず設定する
・セキュリティグループ／ファイアウォールで 6379 番の到達範囲をアプリケーションサーバに限定する
・管理用に別ユーザーを作り、アプリケーション用ユーザーからは RESTORE を含む危険なコマンドを剥奪しておく

AIエージェントが脆弱性探索の側に回ることの意味は ClaudeがFreeBSDのカーネルRCE脆弱性CVE-2026-4747を完全自動生成 でも扱っている。自動化された探索を前提にした基準づくりについては OWASP APTS｜AIエージェント時代の自律型ペネトレーションテスト基準を読む が参考になる。

5月のRedis CVE 5件との関係と、この事件が残したもの

5月に公表された5件（Redis RCE脆弱性5件まとめ CVE-2026-23479ほか｜全バージョン影響・即パッチ必須 で詳述している）のうち3件は RESTORE 経由だった。今回の2件も、stream側・RedisBloom側ともに入口は RESTORE である。

同じコマンドの、同じデシリアライズ経路が2か月で2度破られている。RESTORE はシリアライズされたバイト列を受け取ってメモリ上のデータ構造を復元する処理であり、攻撃者が構造体のレイアウトを直接指定できるという点で本質的に危険な面を持つ。5月の修正でも7月の修正でも、入っているのは「ヘッダの自己申告を信じる前に実データと突き合わせる」という同種のガードだ。

この事件から実務的に持ち帰れるのは、AIの能力評価の話よりも、次の3点だと考えている。

1. CVE番号は遅れて来る。 ベンダーのリリースが先、CVEが後。今回は2日、RedisBloom側は執筆時点でまだ来ていない。CVE照合型のスキャナだけに依存すると、この期間は空白になる。使っているミドルウェアのリリースフィードを直接購読する運用が要る。

2. 攻撃コストの下がり方が変わった。 「AIが19件を90分で」という主張の真偽はさておき、PoCが事件から1日で公開され400近いスターを集めるという速度は事実である。防御側の「パッチ適用までの猶予」は縮む方向にしか動かない。

3. 同じ攻撃面は繰り返し狙われる。 一度脆弱性が出た経路は、修正が不完全なら必ず再訪される。今回はNVD自身が「不完全な修正が原因」と明記した。自組織のインシデント対応でも、修正後に同じ経路を再テストする工程を入れる価値がある。

参照ソース

・redis/redis — Release 7.4.10（公式リリースノート） — stream共有NACK修正の記述全文、公開日時（2026-07-23 18:01 UTC）
・redis/redis — Release 8.8.1（公式リリースノート） — RedisBloom/TDigest の境界外書き込み修正、8.8系だけ内容が異なる根拠
・NVD — CVE-2026-66373 — CVSS v3.1 7.5 HIGH（AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H）、CWE-415、登録日時、CVE-2026-25243の不完全修正である旨
・redis/redis PR #15081 — Reject corrupt stream RDB with shared NACK across consumers — rdbLoadObject に入ったガードの実装と回帰テスト、2026-04-23 マージ
・RedisBloom PR #1044 — MOD-13409 Harden RDB loading — Bloom/Cuckoo/TDigest のRDB検証追加、backport の経緯
・Kimi K3 Agents Found Redis Zero-Days and Built RCE Exploit, Researchers Say（The Hacker News） — 研究者の主張と「自己申告のまま」という但し書き、悪用未報告の記述
・Kimi K3: Chinese AI finds several zero-day vulnerabilities in redis database（heise online） — 報道時点でCVE・重大度評価が未整備だった旨