Redis CVE-2026-23479ほか5件のRCE脆弱性｜全バージョン影響、即パッチ必須

2026年5月5日、Redis社は Chief Information Security Officer の Riaz Lakhani 名義で、Redis に対する5件のセキュリティアドバイザリを同時公開した。CVE-2026-23479・25243・25588・25589・23631 のいずれもリモートコード実行（RCE）に繋がる可能性があり、Redis OSS/CE の全リリース、Redis Software 8.0.6 以下、Redis Stack に同梱される RedisTimeSeries・RedisBloom モジュールが影響範囲となる。本記事では、Redis 公式アドバイザリ・Redis GitHub リリースノート・各 CVE 詳細をもとに、5件の脆弱性メカニズムと、自社環境で即実施すべきアップグレード・ACL 制限・ネットワーク隔離の3層対策を整理する。

AI/OSSサプライチェーン全体のセキュリティ強化と関連CVE対応の俯瞰は サプライチェーンセキュリティ完全ガイド2026｜攻撃手法・防御ツール・実践チェックリスト をご覧ください。

5件のCVE全体像 — 公式アドバイザリの整理

Redis社のアドバイザリ（タイトル: “Security advisory: [CVE-2026-23479] [CVE-2026-25243] [CVE-2026-25588] [CVE-2026-25589] [CVE-2026-23631]”）は2026年5月5日に公開され、5件のCVEを同時に扱う統合形式となった。これは2025年10月の RediShell（CVE-2025-49844）とは別系統の脆弱性群で、RediShell が13年もの未認証 EVAL 経由 RCE だったのに対し、今回はすべて認証済みユーザーが起点となる post-auth の脆弱性である。

5件のうち4件が CVSS 7.7（High）で、Lua UAF のみ 6.1（Medium）に格付けされている。Lua UAF が一段階低いのは、悪用にレプリカ側で replica-read-only no の設定が必要という条件が付くためで、デフォルト構成では発火しにくい。それでも RCE に繋がりうる以上、軽視はできない。

経路1: unblock client flow の use-after-free（CVE-2026-23479）

最初の経路は、BLPOP BRPOP BLMOVE のようなブロッキングコマンドで一旦待機状態に入ったクライアントが、別経路でアンブロックされた瞬間に再実行される処理に存在する。Redis サーバ内部で processCommandAndResetClient がエラー値を返したケースが想定されておらず、エラー処理を経由したあとに解放済みのオブジェクトを参照する古典的な use-after-free（UAF）が発生する。

影響条件

CVE-2026-23479 は redis-server 7.2.0 から 8.6.3（修正前）までが影響範囲となる。攻撃成立には以下が必要:

• 認証済みユーザーで Redis に接続できること
• ブロッキングコマンドを実行できる ACL 権限（デフォルトの default ユーザーや ~* &* +@all -@dangerous 程度の設定なら通る）
• ブロックされたクライアントが、サーバ側のメモリ圧迫等で再実行ループ中に追い出される条件を作れること

最後の条件が一見ハードルに見えるが、MEMORY USAGE CLIENT KILL CONFIG SET maxmemory 等の組合せで人為的に誘発可能であるため、内部攻撃者にとっては現実的なシナリオである。

検出のヒント

サーバログにスタックトレース付きの redis-server crashed signal 11 が連続して残っていれば、UAF 系の試行が走っている可能性がある。CrashLog に unblockClient processCommandAndResetClient を含むスタックフレームが現れる場合は当該脆弱性を疑う。

=== REDIS BUG REPORT START: Cut & paste starting from here ===
*** Redis CrashReport ***
... (中略) ...
0  redis-server  ... unblockClient + 0xab
1  redis-server  ... processCommandAndResetClient + 0x12c
2  redis-server  ... processInputBuffer + 0x80

このようなスタックフレームが定期的に発生していれば、攻撃試行のシグネチャになる。CrashLog は dir 設定で指定したディレクトリに redis_crash_*.log として保存される。

経路2: RESTORE コマンドのメモリ破壊系3件（CVE-2026-25243 / 25588 / 25589）

3件まとめて触れるのは、いずれも RESTORE コマンドが受け取るシリアライズ済みペイロード（DUMP で出力される独自フォーマット）の検証不備が原因だからである。RESTORE は本来バックアップ・移行用途で、DUMP で取り出したバイナリをそのまま投入するための内部コマンドだが、シリアライザがすべての型・全モジュールに対して防御的に書かれているわけではない点が今回の問題点。

CVE-2026-25243 — Redisコア

Redis コアが提供する RESTORE の検証不備で、Emil Lerner が double-free を、Joseph Surin がベクトル型の整数オーバーフローおよび OOB read を発見した。攻撃の概要は以下のとおり。

# 攻撃者は事前に細工した DUMP 形式のバイナリを生成
# （実際のPoCは公開されていないため概念的な構造）
attacker$ redis-cli RESTORE evil 0 "$CRAFTED_PAYLOAD"

CRAFTED_PAYLOAD 内のサイズフィールドや型タグが本来想定されない値を含むことで、デシリアライズ中に同一ポインタが2度 free される、または配列範囲を超えて読み取りに行く、といった挙動が起きる。Redis プロセスは多くの環境でクラッシュするが、ヒープ内容を整地してからの RCE を狙う高度なエクスプロイトが将来的に出てくる可能性は否定できない。

CVE-2026-25588 — RedisTimeSeries

時系列データ用モジュール RedisTimeSeries が RESTORE で復元される際、TS 独自のシリアライズ構造に対するバリデーションが抜けていた。Team Skateboarding Dog（Joseph Surin / John Stephenson / Annie Nie）の連名で報告されている。攻撃には RedisTimeSeries モジュールがロードされていることと、攻撃者が TS 型キーを RESTORE できることが必要。

CVE-2026-25589 — RedisBloom

ブルームフィルタ・カウントミンスケッチを提供する RedisBloom 側にも同種の問題が存在し、Daniel Firer が UAF を、Joseph Surin が整数オーバーフロー / heap buffer overflow を報告した。RedisBloom モジュールがロードされている環境のみ影響。

共通の暫定緩和: ACL で RESTORE を制限する

Redis 6.0 以降の ACL を使えば、特定のユーザーから RESTORE コマンドを取り上げることができる。アプリケーション側で RESTORE を業務利用していないなら、即適用してよい。

# 既存ユーザーから RESTORE を剥奪
redis-cli ACL SETUSER appuser -RESTORE

# 新規ユーザーを RESTORE 不可で作成（読み書きのみ）
redis-cli ACL SETUSER worker on \
  ">$(openssl rand -hex 32)" \
  "~*" "&*" "+@all" "-@dangerous" "-RESTORE" "-DEBUG" "-EVAL" "-FUNCTION"

# 設定を確認
redis-cli ACL LIST
redis-cli ACL WHOAMI

-@dangerous カテゴリには CONFIG / DEBUG / FLUSHALL 等が含まれているが、RESTORE 自体は @write @slow @keyspace カテゴリ寄りで @dangerous には入らないため、明示的な -RESTORE の付与が必要になる。

経路3: Lua use-after-free と master-replica 同期（CVE-2026-23631）

5件目は最も発火条件が限定的だが、設定によっては実用的に悪用しうる Lua スクリプトの UAF。Yoni Sherez が報告した。Lua スクリプト（EVAL EVALSHA FUNCTION CALL）の実行中、master から replica への同期処理経路で Lua オブジェクトのライフサイクル管理に齟齬が発生し、解放済みオブジェクトを参照する状態が再現可能となる。

発火条件

• レプリカ側で replica-read-only no が明示設定されている
• レプリカ側でも認証済みユーザーが Lua スクリプトを実行できる
• master-replica 同期が active 状態である

デフォルトの replica-read-only yes のままなら発火しないが、書き込み可能なレプリカを意図的に運用しているケース（例: 読み書き分離の片方をレプリカに任せる構成）では危険性がある。

緩和: replica-read-only と Lua制限

# redis.conf — レプリカ側
replica-read-only yes
# Luaを業務で使っていなければカテゴリごと禁止
# (ACL側の設定例)
# ACL SETUSER default off
# ACL SETUSER appuser on >$(rand) ~* &* +@all -@scripting

Lua / FUNCTION を完全に止められない場合は、せめてレプリカ側の replica-read-only を yes に戻し、書き込み可能レプリカを使う必要があるなら専用の認証ユーザを作って書き込みレプリカへのアクセスを限定する。

影響バージョンと修正バージョン — どこまで上げるべきか

ここが運用上もっとも重要なパートである。Redis OSS/CE は3系統（6.x / 7.x / 8.x）が同時にメンテナンスされており、各メジャーで個別の修正版が出ている。さらに Redis Software（旧 Redis Enterprise）と、別に出ている RedisTimeSeries / RedisBloom も別管理になっている。

Redis OSS / CE（オープンソース版）

公式の意向としては、8.x への移行が長期的に推奨される一方、6.2 系は LTS として最終的なセキュリティパッチを供給している。本番環境がまだ6.2を使っている場合は、いきなり8.xに上げるよりも 6.2.22 への適用が最短ルートになる。

Redis Software（旧 Redis Enterprise）

Redis Software は Redis Cloud と異なり、ユーザー側のオペレーションでアップグレードを進める必要がある。Redis Enterprise の管理コンソール（rladmin upgrade cluster 系コマンド）で段階的にローリングアップグレードする運用が公式推奨。

Redis モジュール

Redis Stack イメージ（Docker Hub の redis/redis-stack）を利用している環境は、コアと両モジュールが同梱されているため、Stack 全体のイメージ更新が必要になる。

Redis Cloud

公式アドバイザリは Redis Cloud（Pro / Essentials）について「すべてのデプロイは自動的に修正適用済みで、追加のアクションは不要」と明記している。SaaS 利用者は実質ノーオペで済む点が大きい。とはいえ自社のクライアント側コードがまだ古い Redis ライブラリで動いている場合、Cloud 側のパッチとは別軸でクライアントの更新が必要なケースがある。

バージョン確認の最短コマンド

redis-cli から1コマンドで確認できる。実運用環境で複数のレプリカが混在している場合、すべてのノードで個別に実行するのが安全。

# Redisコアバージョン
redis-cli INFO server | grep "^redis_version:"
# 出力例: redis_version:8.6.3

# モジュールバージョン
redis-cli INFO modules
# 出力例:
# module:name=timeseries,ver=11214,api=1,filters=0,...
# module:name=bf,ver=20820,api=1,filters=0,...

# 認証済みかつACLバージョン > 6.0 の場合
redis-cli ACL WHOAMI
redis-cli ACL LIST

# ロード済みモジュール一覧（INFOで出ない場合の代替）
redis-cli MODULE LIST

MODULE LIST の ver フィールドは整数表記（例: 11214 = 1.12.14）で返る点に注意。10進5〜6桁の上位2桁がメジャー、中央2-3桁がマイナー、末尾が patch という独自エンコードを採用している。

ネットワーク隔離 — 公開Redisが攻撃面の根本

CVE 5件のいずれも post-auth とはいえ、Redis をパブリックインターネットに直接さらしている構成では認証突破は時間の問題である。Shodan で port:6379 を検索すると、認証なしの Redis が依然として大量に観測される。RediShell（CVE-2025-49844）以降この数字は減ったが、ゼロにはなっていない。

推奨される最低ライン

特に protected-mode yes は誤って bind 0.0.0.0 と組み合わさった場合の最後のセーフティネットとして機能する。Redis 起動時に「外部から接続できる構成だが認証が無い」と判定すると、外部接続を自動で拒否する仕組みである。

Docker Compose での最小例

services:
  redis:
    image: redis:8.6.3-alpine
    command: >
      redis-server
      --requirepass ${REDIS_PASSWORD}
      --protected-mode yes
      --bind 0.0.0.0
      --rename-command FLUSHALL ""
      --rename-command CONFIG ""
      --rename-command DEBUG ""
      --rename-command RESTORE ""
    networks:
      - internal
    # ports: 公開しない！ アプリコンテナ間通信のみ
networks:
  internal:
    driver: bridge
    internal: true

ports で 6379 をホストに publish しないのが最大のポイントで、internal ネットワーク経由でアプリケーションコンテナとだけ通信させる。RESTORE は --rename-command RESTORE "" で完全に無効化してしまう手もある（バックアップ・移行運用がない前提）。

監視シグナル — 攻撃試行をどう拾うか

CVE 5件のうち、UAF 系（23479・23631）と RESTORE 系（25243・25588・25589）はクラッシュを伴う場合が多く、監視ベースで検知できる可能性がある。下表が監視対象として最低ライン。

slowlog だけでは RESTORE のような短時間コマンドが拾えない場合があるため、本番環境では監査専用 ACL ユーザーを作って CLIENT NO-EVICT ON と組み合わせ、定期的に MONITOR ストリームをサンプリングする運用が現実解になる。

既知のRedis脆弱性史との位置づけ

過去5年で見ると、Redis のメジャーCVEはおおよそ以下のような流れである。

• 2018 — EVAL 経由のサンドボックス脱出（CVE-2018-11218 / 11219 系）
• 2022 — LPOP RPOP の整数オーバーフロー（CVE-2022-31144）
• 2023 — Lua スクリプトコンパイル時のヒープオーバーフロー（CVE-2023-41053 など）
• 2025年10月 — RediShell（CVE-2025-49844）13年もの未認証 EVAL RCE
• 2026年5月 — 本記事の5件（post-auth、複数経路）

RediShell が「未認証で発火する歴史的バグ」として扱われたのに対し、今回の5件は「post-authだが影響範囲が広く、修正版の段差が大きい」という性格を持つ。Lua とシリアライザという、Redis のパワフルさを支える2つの機能の周辺で立て続けにバグが見つかっている事実は、運用側で「Redis を多機能サーバとして使うこと自体のリスク」を再評価するきっかけになる。

似たパターンとして、git push のプッシュフックを起点としたRCE系統については GitHub RCE脆弱性CVE-2026-3854解説：git push一発でサーバー乗っ取り、Wizが発見 も参照。Linux カーネル側の RCE / コンテナエスケープ系については Copy Fail（CVE-2026-31431）解説：Linuxカーネル脆弱性とEC2/ECS/EKSへの影響 でまとめている。脆弱性管理を組織横断で進めるなら Faraday徹底解説：6.5kスターの脆弱性管理プラットフォームOSS、80+セキュリティツール統合 も合わせて読むと良い。

即実施すべき3層の対応

最後に、本記事のすべてを1ページの行動リストに落とし込む。

層1: バージョン確認とパッチ適用（最優先・24時間以内）

1. redis-cli INFO server で redis_version を全ノード確認
2. OSS/CE は 6.2.22 / 7.2.14 / 7.4.9 / 8.2.6 / 8.4.3 / 8.6.3 のいずれかに到達
3. Redis Software は 8.0.10-64 など系統別の修正版へローリングアップグレード
4. RedisTimeSeries / RedisBloom を使っている場合は MODULE LIST で確認し、それぞれ修正版に更新
5. Redis Cloud は対応不要（自動修復済み）

層2: ACLとコマンド制限（パッチ適用までの暫定）

# RESTORE / DEBUG / EVAL / FUNCTION を業務で使わないなら剥奪
redis-cli ACL SETUSER default -RESTORE -DEBUG -EVAL -EVALSHA -FUNCTION

# レプリカは read-only に固定
redis-cli CONFIG SET replica-read-only yes

層3: ネットワーク隔離と監視（恒久対策）

• bind をアプリケーションサーバ IP のみに限定
• protected-mode yes を確認
• 6379 / 6380 ポートをパブリックインターネットに出さない
• TLS 化（tls-port）と要クライアント証明書化
• crash log 監視と RESTORE 実行回数のメトリクス化

参照ソース

• [Security advisory: [CVE-2026-23479] [CVE-2026-25243] [CVE-2026-25588] [CVE-2026-25589] [CVE-2026-23631]

  Redis Blog](https://redis.io/blog/security-advisory-cve202623479-cve202625243-cve-2026-25588-cve202625589-cve-2026-23631/) — Redis社CISO Riaz Lakhani による公式アドバイザリ（2026-05-05公開）

• CVE-2026-23479 - Vulnerability-Lookup (CIRCL) — unblock client flow UAF の技術詳細とCVSSスコア
• CVE-2026-25243 Detail - NVD — RESTORE コマンドのメモリアクセス脆弱性詳細
• Releases · redis/redis (GitHub) — 修正バージョンのリリースノート
• Critical Redis Vulnerabilities Enable Remote Code Execution Attacks - CyberPress — 5件CVEのまとめと攻撃シナリオ解説
• Redis Security Flaws Expose Servers to RCE Risks - GBHackers — 業界視点での影響評価