Redis CVE-2026-66373とは？影響バージョン・Docker検証・更新方法

初回確認: 2026年7月31日 / 最終確認: 2026年8月1日
対象: Redis server / CVE-2026-66373
公開状況: CVE Record の CISA-ADP 評価は Exploitation: poc / Automatable: no
修正版: 6.2.23 / 7.2.15 / 7.4.10 / 8.2.8 / 8.4.5 / 8.6.5 / 8.8.0 以降
この記事では、個別環境の接続先・認証情報・内部構成は公開せず、誰でも再利用できる確認観点だけをまとめます。

Redis CVE-2026-66373とは？影響バージョン・Docker検証・安全な更新方法

初回確認：2026年7月31日／最終確認：2026年8月1日

• 対象製品：Redis Open Source

• CVE：CVE-2026-66373

• 脆弱性分類：CWE-415（Double Free）

• 深刻度：CVSS 3.1 7.5 High

• 攻撃条件：認証済みで、細工したデータのRESTOREとStreamsの管理操作などを実行できること

• CISA-ADP評価：Exploitation: poc／Automatable: no／Technical Impact: total

• 主な修正版：6.2.23、7.2.15、7.4.10、8.2.8、8.4.5、8.6.5、8.8.0以降

この記事では、個別環境の接続先、認証情報、ACL設定値、内部ネットワーク構成は公開せず、Redisを利用する環境で再利用できる確認方法と更新手順をまとめます。

結論：対象系列を利用している場合は修正版へ更新する

Redis 7.4系を利用している場合は、7.4.10以降へ更新してください。

CVE-2026-66373は、細工されたRedis StreamsのデータをRESTOREで読み込ませ、複数のコンシューマーが同じ内部データを参照する不正な状態を作る脆弱性です。その後、対象コンシューマーを削除すると、use-after-freeやdouble freeが発生し、条件次第ではリモートコード実行につながる可能性があります。

攻撃者には、Redisへ到達できるだけでなく、認証を通過し、少なくとも細工したデータをRESTOREできる権限が必要です。公開PoCでは、EVAL、RESTORE、XGROUPの各コマンドが利用されています。認証が設定されていても、アプリ用ユーザーへ広いコマンド権限を与えている場合は安全とは限りません。

Redisをインターネットへ直接公開していない場合でも、次の経路から到達される可能性があります。

• 同じDockerネットワーク内の侵害されたコンテナ

• SSRFや任意コード実行を受けたWebアプリ

• 内部ネットワークへ侵入した攻撃者

• 認証情報が漏えいした運用端末

• 誤設定された管理ツールやバックアップ処理

ポート非公開と認証は重要ですが、修正版への更新の代わりにはなりません。

この記事で分かること

この記事では、次の内容を確認できます。

• CVE-2026-66373で何が起きるのか

• 自分のRedisが影響を受けるか

• CVEレコードと系列別修正版の見方

• Docker Compose環境で実行版を確認する方法

• ACLで危険なコマンド権限を確認する方法

• Redisを安全に更新する手順

• 更新後に確認すべきアプリ機能

• 再発防止のための運用方法

対象読者・前提環境

主な対象読者は次のとおりです。

• RedisをDockerまたはDocker Composeで運用している人

• Django Channels、Celery、セッション、キャッシュでRedisを使っている人

• Redis Streamsやコンシューマーグループを使っている人

• Ubuntu、Debian、RHEL系OSでRedisを運用している人

• マネージドRedisやRedis互換サービスを利用している人

コマンド例では、Docker Compose上のサービス名をredisとしています。実際のサービス名が異なる場合は読み替えてください。

CVE-2026-66373は何が問題なのか

Redis Streamsには、メッセージを処理する複数のコンシューマーをグループとして管理する仕組みがあります。

処理が完了していないメッセージは、PEL（Pending Entries List）と呼ばれる一覧で管理されます。

簡単に例えると、PELは「担当者へ渡したものの、まだ完了報告が届いていない仕事の一覧」です。

正常な状態では、1つの内部pending entryには、対応するコンシューマーが正しく関連付けられます。

CVE-2026-66373では、細工された復元データによって、複数のコンシューマーが同じ内部オブジェクトを参照する不正な状態を作れます。

細工したStreamsデータ
        │
        ▼
RESTOREでRedisへ読み込ませる
        │
        ▼
consumer-A ─┐
             ├─ 同じpending entryを参照
consumer-B ─┘
        │
        ▼
XGROUP DELCONSUMERで削除
        │
        ▼
解放済みメモリを再び参照・解放
        │
        ▼
use-after-free／double free
        │
        ▼
クラッシュまたはコード実行の可能性

Redis公式の修正では、2番目のコンシューマーが、すでに別のコンシューマーへ関連付けられたNACKを参照しようとした時点で、データを破損形式として拒否する検査が追加されました。修正版ではRESTOREがBad data formatで失敗し、その後もRedisがPINGへ応答することが回帰テストで確認されています。

深刻度と攻撃成立条件

MITREによるCVSS 3.1評価は、7.5 Highです。

CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

各項目の意味は次のとおりです。

CVEレコードでは、認証済み攻撃者がRESTOREを実行できる特殊な条件で、XGROUP DELCONSUMERによるコンシューマー削除を通じてdouble freeへ至ると説明されています。CWEはCWE-415です。

公開PoCで必要とされているコマンドは次のとおりです。

• RESTORE

• XGROUP

• EVAL

これは、すべての攻撃手法で必ず同じコマンドが必要という意味ではありません。

少なくともRESTOREだけを確認して終わらせず、Streams管理コマンドとスクリプト実行権限も含めて棚卸しすることが重要です。

公開PoCがあることと実悪用は別

CISA-ADPのSSVC評価は、2026年7月27日時点で次のとおりです。

• Exploitation: poc

• Automatable: no

• Technical Impact: total

Exploitation: pocは、再現コードや概念実証が公開されていることを示します。

この値だけで、実環境に対する攻撃が確認されたと判断することはできません。一方で、PoCと修正差分が公開されているため、実悪用の報告を待ってから対応するのではなく、修正版への更新を優先する判断が妥当です。

CVE-2026-25243との関係

CVEレコードでは、この問題はCVE-2026-25243に対する修正が不完全だったことにより残った脆弱性と説明されています。

以前のRESTORE関連脆弱性へ対応済みでも、今回の修正版まで適用されているとは限りません。

「以前Redisを更新したから安全」と判断せず、現在実行中のバージョンを確認してください。

影響バージョンと修正版

Redis公式リリースで、この脆弱性に対する修正が明記されているバージョンは次のとおりです。

6.2.23、7.2.15、7.4.10、8.2.8、8.4.5、8.6.5の各リリースには、細工したStreamsのRESTOREペイロードによるuse-after-freeとRCE可能性の修正が明記されています。

Redis 8.8.0は、修正コミットを含むGA版として2026年5月25日に公開されました。8.8.1には別のRESTORE関連セキュリティ修正も含まれるため、8.8系を選ぶ場合は8.8.1以降を優先します。

Redis 8.10.0は、2026年7月29日にGA版として公開されています。新規導入で採用する場合は、利用中のクライアント、永続データ、モジュール、設定との互換性を検証してください。

CVEレコードの「8.8.0未満」に関する注意

CVEレコードのaffected欄は、単純には「8.8.0未満」と記載されています。

ただし、CVE公開後にRedis公式から旧系列向けの修正版がバックポートされています。

そのため、次のバージョンは8.8.0未満ですが、本脆弱性の修正を含みます。

• 6.2.23

• 7.2.15

• 7.4.10

• 8.2.8

• 8.4.5

• 8.6.5

系列別の判定では、CVEレコードの単純なバージョン範囲だけでなく、Redis公式リリースノートも照合してください。

30秒で確認する影響判定

次の順番で確認します。

1. 実行中のRedisバージョンを確認する

2. 修正版より古い場合は更新対象とする

3. ホスト公開と内部ネットワークからの到達範囲を確認する

4. アプリ用ACLがRESTORE、XGROUP、EVALを許可しているか確認する

5. Redis Streamsやコンシューマーグループの利用箇所を確認する

6. Redisを使用するキャッシュ、WebSocket、キュー、セッションを洗い出す

Docker Composeで実行バージョンを確認する

目的

Composeファイルのタグではなく、現在稼働しているRedisバイナリのバージョンを確認します。

実行場所

Docker Composeを管理しているホスト上で実行します。

docker compose exec redis redis-server --version

正常例

Redis server v=7.4.10 sha=00000000:0 malloc=jemalloc-5.3.0 bits=64

更新が必要な例

Redis server v=7.4.8 sha=00000000:0 malloc=jemalloc-5.3.0 bits=64

異常例

service "redis" is not running

結果の判断

• 7.4.10以降：本脆弱性は修正済み

• 7.4.9以前：更新対象

• サービスが停止中：コンテナ名と稼働状態を確認

Composeファイルへredis:7.4.10-alpineと記載しても、コンテナを再作成するまでは旧版が動き続ける場合があります。

Docker公式イメージにはredis:7.4.10-alpineタグが公開されています。

6379番ポートの公開状態を確認する

目的

Redisがホストの外部インターフェースへ公開されていないかを確認します。

実行場所

Dockerホスト上で実行します。

docker compose ps redis

必要に応じて、OS側でも確認します。

ss -lntp | grep ':6379'

注意が必要な例

0.0.0.0:6379->6379/tcp

この表示は、ホストの全IPv4インターフェースで6379番ポートを待ち受ける設定を示します。

ポート非公開の例

6379/tcp

ホスト側ポートが表示されず、Dockerネットワーク内でのみ利用されている可能性があります。

結果の判断

ホストへ公開されていなくても、同じDockerネットワークに参加するコンテナからは到達できる場合があります。

「6379番ポートが外部公開されていない」という確認だけで、更新不要とは判断しないでください。

ACLでコマンド権限を確認する

RedisのACL DRYRUNは、指定したユーザーでコマンドを実行できるかを、副作用を発生させずに確認するコマンドです。

目的

アプリ用ユーザーが、攻撃に利用され得るコマンドを許可されていないか確認します。

実行場所

安全な管理経路からRedisへ接続して実行します。

実際のユーザー名をappuserへ置き換えてください。

ACL DRYRUN appuser RESTORE test-key 0 placeholder
ACL DRYRUN appuser XGROUP DELCONSUMER test-stream test-group test-consumer
ACL DRYRUN appuser EVAL "return 1" 0

権限が拒否されている例

User appuser has no permissions to run the 'restore' command

権限が許可されている例

OK

結果の判断

• 権限拒否：対象コマンドは実行不可

• OK：対象ユーザーに実行権限あり

• アプリが使用していないのにOK：ACL見直しを検討

RESTOREはRedis公式で@dangerousカテゴリーにも分類されています。

ACLの出力、ユーザー名、認証文字列を公開記事、チケット、チャット、ログへ貼り付けないでください。

OSパッケージで利用している場合

Ubuntu・Debian

dpkg-query -W redis-server
apt-cache policy redis-server

RHEL・Rocky Linux・AlmaLinux

rpm -q redis
dnf info redis

OSディストリビューションでは、上流のバージョン番号を大きく変えず、セキュリティ修正だけをバックポートする場合があります。

表示バージョンだけで脆弱と断定せず、次の情報を照合してください。

• パッケージのchangelog

• ディストリビューションのCVEトラッカー

• ベンダーのセキュリティアドバイザリ

• パッケージリリース番号

マネージドRedis・Redis互換サービスの場合

AWS、Azure、Google Cloudなどのマネージドサービスでは、利用者がコンテナを直接更新できない場合があります。

次の情報を確認します。

• エンジンバージョン

• メンテナンス通知

• セキュリティアドバイザリ

• 自動パッチの適用状況

• メンテナンスウィンドウ

• フェイルオーバーの有無

Redis互換サービスは、OSS Redisとは内部実装が異なる場合があります。

OSS Redisのバージョン表だけを当てはめず、サービス提供者がCVE-2026-66373の影響対象としているかを確認してください。

更新までの暫定的な緩和策

修正版を適用するまで、次の対策を行います。

1. Redisをインターネットへ直接公開しない

2. 接続元ネットワークを必要最小限に限定する

3. アプリ用ACLから不要なRESTORE権限を外す

4. 不要なEVAL、EVALSHAなどのスクリプト実行権限を外す

5. Streamsを使わないユーザーからXGROUP権限を外す

6. SSRFやアプリの任意コード実行対策を確認する

7. Redisの認証情報をローテーション可能な状態にする

8. 認証情報をソースコードや公開ログへ残さない

9. Redisへの異常な接続や管理コマンド実行を監視する

ACLの変更はアプリ停止につながる可能性があります。

変更前に現在の権限をバックアップし、検証環境またはメンテナンス時間帯で機能試験を行ってください。

暫定対策は更新の代わりではありません。恒久対策は修正版への更新です。

Docker Composeで安全に更新する

事前準備

更新前に次の項目を確認します。

• RDBまたはAOFを利用しているか

• 永続ボリュームのバックアップ方法

• 現在利用中のイメージタグとdigest

• Composeファイルのバックアップ

• 直前版へ戻す手順

• Redis停止時に影響するアプリ機能

• メンテナンス時間

• Redis再接続に失敗した場合の復旧手順

セッション、キュー、Streams、永続キャッシュをRedisへ保存している場合は、単純なキャッシュ専用Redisより影響が大きくなります。

Composeファイルを修正する

7.4系を継続する場合の例です。

services:
  redis:
    image: redis:7.4.10-alpine

redis:7-alpineのような浮動タグは、再取得した時点で参照先が変わります。

監査とロールバックを行いやすくするため、少なくともパッチ番号まで固定します。

さらに厳密に管理する場合は、検証済みのイメージdigestも記録してください。

更新コマンド

目的

Redisの新しいイメージを取得し、Redisコンテナだけを再作成します。

実行場所

ComposeファイルがあるDockerホスト上で実行します。

docker compose config --images
docker compose pull redis
docker compose up -d --force-recreate --no-deps redis
docker compose exec redis redis-server --version
docker compose ps redis
docker compose logs --since=10m redis

正常な状態

• redis-server --versionが修正版を表示する

• Redisコンテナがrunningまたはhealthy

• 再起動ループが発生していない

• RDBまたはAOFの読み込みエラーがない

• 権限エラーが急増していない

異常な状態

• 実行版が更新前のまま

• コンテナが繰り返し再起動する

• Bad file formatやAOF読込エラーが出る

• アプリから認証エラーが出る

• WebSocketやバックグラウンド処理が再接続しない

結果の判断

docker compose pullの成功だけでは更新完了ではありません。

実行中コンテナを再作成し、Redis自身が返すバージョンを確認した時点で更新完了と判断します。

PINGとINFOの認証に関する注意

認証を設定していない環境では、次のコマンドで応答確認ができます。

docker compose exec redis redis-cli PING
docker compose exec redis redis-cli INFO server

正常例は次のとおりです。

PONG

認証が設定されている場合は、次の応答になることがあります。

NOAUTH Authentication required.

NOAUTHは、Redisが停止していることを意味しません。認証なしのコマンドが拒否された状態です。

本番環境では、次のいずれかで確認してください。

• 既存の安全な管理接続

• Docker Secretsを利用した接続

• アプリと同じ認証経路

• 既存のヘルスチェック

• 監視システムのRedisチェック

パスワードをコマンドラインへ直接記載すると、シェル履歴やプロセス一覧へ残る可能性があります。

公開記事へ実際の認証コマンドを貼り付けないでください。

更新後の動作確認

Redis単体のPINGだけでは、アプリ全体の動作確認として不十分です。

Redisを利用している機能ごとに確認します。

更新後は、少なくとも次のログを確認します。

• Redisコンテナログ

• Webアプリログ

• Workerログ

• WebSocketログ

• 監視アラート

• 接続エラー数

• Redis再起動回数

隔離Docker検証で確認したこと

2026年8月1日、筆者環境において、Redis公式の回帰テストで使用されている破損Streamsデータを用い、Redis 7.4.8と7.4.10を比較しました。

検証用コンテナには、次の制限を設定しました。

• ホストポートを公開しない

• --network none

• 読み取り専用ファイルシステム

• 非rootユーザー

• Linux capabilityをすべて削除

• no-new-privileges

• CPUとメモリの制限

• 使い捨てコンテナ

結果は次のとおりです。

Redis 7.4.8が破損データを受理した時点で検証を停止しました。

コンシューマー削除、double free、クラッシュ、任意コード実行へ進む操作は行っていません。

今回確認した内容は次の範囲です。

• 旧版が当該の破損データを受理した

• 修正版がBad data formatとして拒否した

• 拒否後もRedisがPINGへ応答した

• Redis公式の回帰テストの期待結果と整合した

任意コード実行やdouble freeそのものを再現した検証ではありません。

Redis公式の修正PRでも、修正版は同じNACKを複数のコンシューマーが参照する破損データを拒否し、PINGへの応答を維持することが確認されています。

検証結果を第三者が再現できるようにする場合は、次の情報も記録します。

• Dockerイメージのdigest

• Redisの完全なバージョン文字列

• 回帰テストデータの取得元コミット

• 実行コマンド

• 実行日時

• 標準出力と標準エラー

• docker inspectで確認した隔離設定

当サイトでの対応方針

当サイトでも、次の項目を照合します。

• 実行中のRedisバージョン

• Dockerイメージのタグとdigest

• ホスト公開の有無

• Dockerネットワーク内の到達範囲

• アプリ用ACL

• Redis Streamsの利用状況

• WebSocket、キャッシュ、セッション、キューへの影響

• Redis再起動後の再接続

• Redisとアプリのエラーログ

Redisを外部へ直接公開していない場合でも、対象版は更新対象として扱います。

公開記事には、次の情報を掲載しません。

• 実際のRedis接続先

• 内部IPアドレス

• 認証情報

• ACLユーザー名

• Redisの内部ポート構成

• Dockerネットワーク名

• バックアップの保存場所

• 更新前の詳細な内部構成

再発防止

パッチ番号まで固定する

image: redis:7.4.10-alpine

浮動タグだけに依存せず、採用したバージョンを構成管理へ記録します。

実行版を定期的に棚卸しする

Composeファイルだけでなく、実行中バイナリを定期的に確認します。

docker compose exec redis redis-server --version

ACLを最小権限にする

アプリ用ユーザーへ+@allを与えず、必要なキーとコマンドだけを許可します。

特に次の権限を定期的に確認します。

• RESTORE

• MIGRATE

• EVAL

• EVALSHA

• FCALL

• FUNCTION

• MODULE

• CONFIG

• DEBUG

• XGROUP

• FLUSHALL

• FLUSHDB

Redisをアプリごとに分離する

セッション、WebSocket、ジョブキュー、一般キャッシュを1つのRedisへ集約すると、障害やACL変更の影響範囲が大きくなります。

重要度や用途に応じて、インスタンス、ACLユーザー、データベース、ネットワークを分離します。

更新後の確認を自動化する

CI/CDまたは運用スクリプトへ、次の確認を組み込みます。

1. 期待バージョンとの比較

2. コンテナの稼働確認

3. 認証付きヘルスチェック

4. アプリからの疎通確認

5. Redis依存機能のスモークテスト

6. ログ内のエラー検出

7. ロールバック判定

注意点・よくある誤解

6379番ポートを公開していなければ更新不要ですか？

いいえ。

外部から直接到達される危険は下がりますが、同じDockerネットワーク、内部サーバー、侵害されたWebアプリからRedisへ到達される可能性は残ります。

ポート非公開は重要な防御ですが、修正版への更新の代わりにはなりません。

Redis Streamsを使っていなければ安全ですか？

通常のアプリ機能でStreamsを使っていなければ、攻撃対象となる機能への露出は小さくなります。

ただし、攻撃者がRESTOREで細工したStreamsデータを新しく作れる権限を持っている場合は、通常利用していないことだけで対象外とは判断できません。

バージョンとACLを確認してください。

認証を設定していれば更新不要ですか？

いいえ。

このCVEは、認証済みで必要なコマンドを実行できる攻撃者を前提としています。

認証、ACL、ネットワーク制限、修正版への更新を組み合わせてください。

RESTOREを禁止すれば更新不要ですか？

不要なユーザーからRESTOREを外すことは有効な緩和策です。

ただし、設定ミス、別ユーザーの認証情報漏えい、権限変更、将来の運用変更を考えると、恒久対策にはなりません。

修正版へ更新してください。

redis:7-alpineなら自動的に最新版へ変わりますか？

実行中のコンテナは自動では変わりません。

同じタグの参照先が更新されても、イメージを取得し直し、コンテナを再作成する必要があります。

docker compose pull redis
docker compose up -d --force-recreate --no-deps redis

更新後は、必ず実行中のバージョンを確認してください。

7.4.8から7.4.10は同一パッチ系列ですか？

正確には、同一マイナー系列内のパッチ更新です。

RedisはMAJOR.MINOR.PATCH形式を採用しています。

7.4.10
│ │ └─ PATCH
│ └─── MINOR
└───── MAJOR

Redis公式も、7から8をメジャー更新、8.2から8.4をマイナー更新、8.6.1から8.6.2をパッチ更新として説明しています。

対応チェックリスト

• 実行中のRedisでredis-server --versionを確認した

• Composeファイルのタグだけで判断していない

• 利用系列に対応する修正版を確認した

• CVEレコードとRedis公式リリースを照合した

• ホストの6379番ポート公開状態を確認した

• Dockerネットワーク内の到達元を確認した

• アプリ用ユーザーのRESTORE権限を確認した

• XGROUPとスクリプト実行権限を確認した

• Redis Streamsの利用箇所を確認した

• RDBまたはAOFのバックアップを確認した

• 更新前イメージとロールバック方法を記録した

• Redisコンテナだけを再作成した

• 更新後の実行バージョンを確認した

• 認証付きの疎通確認を行った

• キャッシュの動作を確認した

• セッションの動作を確認した

• WebSocketの再接続を確認した

• ジョブキューの動作を確認した

• Redis Streamsの動作を確認した

• Redisとアプリのログを確認した

• 再起動ループや接続エラーが増えていないことを確認した

まとめ

CVE-2026-66373は、細工されたRedis Streamsの復元データにより、複数のコンシューマーが同じ内部pending entryを参照する状態を作り、コンシューマー削除時のdouble freeからリモートコード実行へつながる可能性がある脆弱性です。

攻撃には、Redisへ認証済みで接続し、RESTOREやStreams管理操作などを実行できる権限が必要です。

ただし、RedisはWebアプリの内部基盤として使われることが多く、アプリ侵害後の横展開先になり得ます。

次の3点をセットで実施してください。

1. 修正版への更新

2. ACLの最小権限化

3. 更新後のRedis依存機能の動作確認

Redis 7.4系を利用している場合は、7.4.10以降への更新を優先します。

参考情報

• CVE Program／CVE-2026-66373

• NVD／CVE-2026-66373

• Redis修正PR #15081

• Redis 6.2.23、7.2.15、7.4.10リリース

• Redis 8.2.8、8.4.5、8.6.5リリース

• Redis 8.8.0、8.8.1、8.10.0リリース

• Redis Open Sourceバージョン管理

• Redis ACL DRYRUN公式ドキュメント

• Redis RESTORE公式ドキュメント

• Docker Official Image for Redis