RedisのRCE脆弱性、PoC公開で危険度増す 修正済み脆弱性の“抜け穴”が判明：複数バージョンで全試行成功

Redisで見つかった任意コード実行（RCE）につながる脆弱性に対し、実際に攻撃を再現するPoCが公開された。公開資料では複数バージョンで全ての検証に成功したと報告されており、実用性の高さがうかがえる。修正の背景や影響範囲、攻撃が成立する条件、取るべき対策を整理する。

[＠IT]

　MITREが2026年7月25日に公開したCVE情報によると、データベース管理システム「Redis」の8.8.0未満には、特定の認証済みユーザーによって、遠隔から任意のコードを実行される恐れがある脆弱（ぜいじゃく）性「CVE-2026-66373」が存在すると分かった。

　同脆弱性は、Redisのストリーム機能でメッセージの未処理状態を管理する仕組みに存在する。同じ未処理メッセージ（NACK）が複数のコンシューマーから参照されている状態で、「XGROUP DELCONSUMER」コマンドによってコンシューマーを削除すると、本来は1回だけ解放されるべきメモリが2回解放されてしまう。この「二重解放」によってメモリ管理が破綻し、条件次第では任意コードの実行につながる恐れがある。

公開PoCは複数バージョンで全試行成功　RCEの実用性が明らかに

　同脆弱性のCVSS v3.1の基本値は7.5、深刻度は「重要」（High）と評価されている。ネットワーク経由で悪用可能だが、攻撃には認証済みであることに加え、「RESTORE」「EVAL」「XGROUP」などの実行権限が必要となる。ただ、悪用に成功すると機密性や完全性、可用性の全てに重大な影響を及ぼす可能性がある。

　影響を受けるのはRedis 8.8.0未満の全バージョンだ。MITREは、この問題が過去の脆弱性「CVE-2026-25243」への修正が不完全だったことに起因すると説明している。共有NACKを利用する今回の手法は従来の対策を回避できる亜種であり、この問題はRedis 8.8.0で修正された。

　同脆弱性を悪用してサービスを停止させることなく任意コードを実行するPoC（概念実証）コードが公開されている。公開資料によると、Redis 6.2.22や7.4.9、8.6.4を対象に検証した結果、それぞれ10回中10回、5回中5回、25回中25回と、全ての試行で任意コードの実行に成功したという。複数バージョンで極めて高い再現性が確認されており、PoCの実用性の高さがうかがえる。

　PoCには各バージョン向けのPython製実証コードに加え、実行に必要な補助ライブラリや各種スクリプトなども含まれている。動作にはPython 3.6以上とgccが必要だが、追加のPythonパッケージは不要とされる。

　攻撃を成立させるには、利用者に「RESTORE」「EVAL」「XGROUP」を実行する権限が付与されている必要がある。また、Redis 6.2.22ではビルド環境に応じたアドレス情報の調整が必要となる一方、Redis 7.4.9および8.6.4では公式の標準イメージを対象にデバッグ機能を有効化することなく実行できると説明されている。

Redis本体とは別　RedisBloom向けPoCも公開

　公開資料には、CVE-2026-66373とは別に、Redisの拡張モジュール「RedisBloom」の脆弱性を悪用するPoCも収録されている。RedisBloomは、Bloom Filterや統計処理、高頻度データの抽出といった機能を追加する拡張モジュールだ。

　PoCには、Redis 8.8.0で統計処理機能「TDigest」のヒープオーバーフローを悪用するものと、Redis 8.8.0および8.8.1で高頻度データを管理する機能「TopK」の不正解放を悪用するものが含まれている。後者は、既知の脆弱性「CVE-2026-25589」に対する修正を回避する手法とされる。

　これらはRedis本体の「CVE-2026-66373」とは別の脆弱性を悪用するものであり、影響を受けるのはRedisBloomモジュールを組み込んで利用している環境に限られる。

　これらのPoCはjemallocのメモリ配置に強く依存するため、新規インスタンスでの実行が推奨されている。公開資料では、Redis 8.8.0向けTDigestのPoCについて、新規コンテナ環境で5回中5回の成功を確認したとしている。

　PoCの実行後には、一部のメモリ領域やキーが意図的に残るため、公開資料では検証後に「FLUSHALL」や「SAVE」を実行しないよう注意を呼びかけている。また、失敗時には安全に中断し、再実行できるよう設計されているという。

　公開資料は、これらのPoCは認可された環境での検証のみを目的としていると明記している。

　対策としては、Redis本体を8.8.0以降へ更新するとともに、RedisBloomを利用している場合はモジュール側の脆弱性にも注意する必要がある。また、「RESTORE」「EVAL」「XGROUP」といった高権限コマンドを不要なユーザーへ付与していないかACL設定を見直し、管理者権限を最小限に抑えることも重要だ。