2026年5月、Redisのブロッキングクライアント処理コードで発生したUse-After-Free脆弱性CVE-2026-23479が修正されました。この脆弱性は、認証済みユーザーが特定条件下でRedisサーバーが稼働するホストシステム上において、リモートコード実行（RCE）を引き起こす可能性がある脆弱性です。
CVE-2026-23479は、Redis 7.2.0で導入されて以降、8.6.3のパッチが配布されるまで約2年間、安定版に残っていたとされており、自律型AIセキュリティツールの検証過程で発見された事例として知られています。認証不要の脆弱性ではありませんが、Redisが外部に公開されている場合や、アプリケーションアカウントに広範な権限が付与されている環境では、実際の攻撃対象領域につながる可能性があります。
本記事では、CVE-2026-23479の技術的原因を分析し、Criminal IPを通じてインターネットに露出したRedis資産と脆弱である可能性のあるインスタンスを確認する方法を考察します。
CVE-2026-23479 脆弱性の概要
| 項目 | 内容 |
|---|---|
| 脆弱性ID | CVE-2026-23479 |
| 影響製品 | Redis / redis-server |
| 影響バージョン | Redis 7.2.0以上8.6.3未満 |
| 脆弱性の種類 | Use-After-Free |
| 影響 | リモートコード実行（RCE）の可能性 |
| CVSS スコア | NVD CVSS 3.1基準 8.8 High／Redis CVSS 4.0基準 7.7 High |
| 修正バージョン | 7.2.14, 7.4.9, 8.2.6, 8.4.3, 8.6.3 |
CVE-2026-23479の影響範囲は、Redis 7.2.0以上8.6.3未満です。そのため、特定のバージョンだけを点検するのではなく、運用中のRedisブランチが推奨される修正バージョンに到達しているかを基準に確認する必要があります。
CVE-2026-23479の技術的原因: unblock client flowと Use-After-Free
Redisは一部のコマンドを処理する際、クライアントを一時的に待機状態にすることがあります。たとえば、list、stream、sorted setなどで特定のデータや条件が準備されるまでリクエストを保留し、条件が満たされるとblocked clientを再び実行フローに戻します。
CVE-2026-23479は、この再開過程でclientオブジェクトのライフサイクル管理に不整合が生じることで発生します。Redisのunblock client flowは、blocked clientを再処理する過程でprocessCommandAndResetClientを呼び出します。しかし、特定条件下ではclientオブジェクトが解放された後にも既存のポインターが再参照される可能性があり、その結果、Use-After-Free状態が発生する可能性があります。
Use-After-Freeは、解放済みのメモリ領域をプログラムが依然として有効なオブジェクトであるかのように使用する脆弱性です。この場合、攻撃者はRedisのblocking command処理フローを操作し、異常なメモリ再利用状態を作り出すことで、条件によってはRedisプロセスの権限でコード実行を試みることができます。
この脆弱性の核心は、blocked clientが解放され、再び処理される過程でオブジェクトの状態が正確に反映されない点です。そのため、脆弱なバージョンを使用しているかどうかだけでなく、Redisアカウントに付与されたコマンド権限やデータ書き込み権限も、実際のリスクに影響を与える可能性があります。
脆弱性が2年間隠れていた理由
公開分析によると、このバグは processCommandAndResetClient関数の戻り値が、通常は確認されなくても問題にならない文脈が多かったため、コードレビュー過程で検出されにくいものでした。特定のメモリ負荷条件（maxmemory-clients制限の超過）とブロッキングコマンドのタイミングが同時に成立する必要がある構造であり、一般的な機能テストやレビューでは再現が困難です。Xint Codeがこの脆弱性を発見したことは、自律型AIセキュリティツールが大規模コードベースにおける複雑な条件チェーンの分析に有効であることを示す事例と評価されています。
攻撃フロー：外部公開RedisからRCEにつながり得る経路
CVE-2026-23479は、認証済み攻撃者を前提としています。しかし、外部に露出したRedisインスタンスでは、弱い認証情報、共有アカウント、過剰なACL権限、古いバージョンが組み合わさることで、実際の攻撃条件が満たされる可能性があります。
攻撃フローは次のように整理できます。
- 攻撃者はインターネットスキャンを通じて、外部に露出したRedisインスタンスを識別
- バナー情報、ポート、バージョン、認証要求の有無を基準に、脆弱である可能性のある資産を選別
- 流出したアカウント、弱い認証情報、過剰な権限が付与されたアプリケーションアカウントを通じて、Redisセッションを取得
- XREAD BLOCKなどのブロッキングコマンドとMULTI/EXECを組み合わせてevictionのタイミングを操作し、unblockClientOnKey内でUse-After-Free条件を誘発
- Redisプロセスの権限でコード実行を試行
- その後、セッションデータ、キャッシュデータ、内部サービス情報、アプリケーション接続情報を収集したり、同一ホスト上の別サービスへの移動を試みる可能性
このフローで重要なのは、脆弱性そのものよりも、Redisが運用されている場所と権限構造です。Redisが内部サービスと密接に連携しており、同一IP上で複数の管理サービスやWebサービスが同時に露出している場合、侵害後の影響範囲が拡大する可能性があります。
Redis露出資産の分析
Criminal IP IT資産検索を活用すると、インターネットに露出したRedis資産を検索し、サービスポート、バナー情報、バージョン情報、脆弱性マッピングの有無を基準にリスクの高い資産を識別できます。
Criminal IP検索クエリ: product: Redis
Criminal IPでproductフィルターを使用してRedisを検索した結果、2026年6月時点で約74,000件のRedis関連資産が確認されました。これは、Redisが現在も大規模にインターネット上で識別可能な状態で運用されていることを示しています。国別分布では、日本が17,767件で全体の20％以上を占めていました。
Redisのデフォルトサービスポートは6379番です。Redisが6379番ポートで外部に開放されている場合、または同一IP上でSSH、Web管理ページ、データベース、モニタリングツールが同時に露出している場合は、単一の脆弱性にとどまらない複合的なリスクとして評価する必要があります。
CVE-2026-23479脆弱資産の検索
CVE-2026-23479にマッピングされたRedis資産を確認するには、次のクエリを使用できます。
Criminal IP 検索クエリ: cve_id: CVE-2026-23479
Criminal IP IT資産検索でcve_idフィルターを使用し、CVE-2026-23479の影響を受けるインスタンスを確認した結果、2026年6月時点で16,090件の脆弱な資産が確認されました。組織はこの検索結果を通じて、外部に露出したRedisインスタンスのうち、当該脆弱性の影響を受ける可能性がある資産を優先的に識別できます。
上位の国別分布を見ると、日本が4,772件、米国が2,970件、中国が1,886件、フランスが1,134件、ドイツが873件の順で確認されました。これは、脆弱である可能性のあるRedis資産が一部地域だけに集中しているのではなく、主要なクラウドおよびホスティングインフラ全体に分散していることを示唆しています。
CVEベースの検索結果は、バナー情報、バージョン識別の可否、脆弱性データベースとのマッピング状況によって変動する可能性があります。そのため、検索結果は「確認された脆弱である可能性のある資産」を優先分類する基準として活用し、内部資産リストとRedisの実際のバージョンを照合する手順が必要です。
Redisバージョン別の脆弱資産確認
CVE-2026-23479は、Redis 7.2.0以上8.6.3未満のバージョンに影響します。このうちRedis 8.6.2は、8.6.x系におけるパッチ適用直前のバージョンであるため、代表的な脆弱バージョンとして見ることができます。
Criminal IP 検索クエリ: redis_version:8.6.2
Criminal IPでは、redis_versionフィルターを活用して、特定のRedisバージョンとして識別された資産を検索できます。
検索結果では、2,166件の資産が確認されました。これらの資産はCVE-2026-23479の影響範囲に含まれるため、該当バージョンで運用中の資産が外部に露出している場合は、優先的に8.6.3以上、または各ブランチ別の修正バージョンへアップデートする必要があります。
ブランチ別の推奨修正バージョンは次のとおりです。
| Redis ブランチ | 影響バージョン | 推奨修正バージョン |
|---|---|---|
| 7.2.x | 7.2.0 ~ 7.2.13 | 7.2.14 以上 |
| 7.4.x | 7.4.0 ~ 7.4.8 | 7.4.9 以上 |
| 8.2.x | 8.2.0 ~ 8.2.5 | 8.2.6 以上 |
| 8.4.x | 8.4.0 ~ 8.4.2 | 8.4.3 以上 |
| 8.6.x | 8.6.0 ~ 8.6.2 | 8.6.3 以上 |
IP Reportで確認するRedis資産の複合リスク
Criminal IPのIP Reportでは、特定のRedis資産におけるオープンポート、サービスバナー、脆弱性、リスクレベル、ホスティング情報などを総合的に確認できます。
例示した資産では、InboundリスクがDangerous 80.0％と表示され、合計12件のオープンポートと18件の脆弱性が確認されました。Redisのデフォルトポートである6379番だけでなく、SSH、HTTP/HTTPS、3000番台、5000番台、8000番台、9000番台のサービスポートも同時に露出しており、単一のRedisサービスにとどまらない複合的な露出状態と見ることができます。
脆弱性一覧では、CVE-2026-23479だけでなく、2025年に公開されたRedis RCE脆弱性RediShell（CVE-2025-49844）もあわせて確認されました。これは、Redis資産が新規CVEひとつだけの問題ではなく、過去の脆弱性が累積した状態で外部に露出する可能性があることを示しています。
したがって、Redis資産の点検は「6379番ポートが開いているか」を確認する段階で終えてはなりません。同一IP上で同時に露出しているサービス、累積したCVE、ホスティング環境、リモートアクセス可能性をあわせて確認してこそ、実際の攻撃対象領域を評価できます。
対応推奨事項
- Redisパッチの適用
最も優先すべき対応は、Redisを修正バージョンへアップデートすることです。運用中のRedisブランチに応じて、7.2.14、7.4.9、8.2.6、8.4.3、8.6.3以上のバージョンが適用されているかを確認する必要があります。
Redis Cloudを利用している場合、管理型サービスの更新により、すでにパッチが適用されている可能性があるため、クラウド提供者に確認することが望ましいです。 - Redisの外部公開遮断
Redisは一般的に、外部インターネットへ直接公開する必要性が低いサービスです。ファイアウォール、セキュリティグループ、ネットワークACLを点検し、6379番ポートがグローバルIPからアクセス可能な状態になっていないか確認する必要があります。
外部アクセスが不要なRedisインスタンスは、内部ネットワーク、VPN、プライベートサブネットなど、制限された経路からのみアクセスできるように構成する必要があります。 - Redis ACLおよびコマンド権限の点検
CVE-2026-23479は認証済み攻撃者を前提としているため、アカウント権限の構成が重要です。XREAD BLOCK、BLPOP、BRPOP、CONFIG、EVALなどのコマンドと広範なread/write権限がアプリケーションアカウントに同時に付与されている場合、攻撃条件がより容易に満たされる可能性があります。 - 認証情報およびデフォルトアカウントの点検
Redisインスタンスが認証を要求している場合でも、弱いパスワードや長期間共有されたアカウントが使用されていれば、攻撃可能性は残ります。
デフォルトアカウントの使用有無、流出したパスワードの再利用有無、退職者または外部委託先アカウントの残存有無を点検し、必要に応じてRedisの認証情報を変更する必要があります。 - Criminal IPなどのソリューションを活用した継続的モニタリング
パッチ適用後も、Redis資産は運用変更、クラウドセキュリティグループの設定ミス、テストインスタンスの放置などにより、再び外部に露出する可能性があります。Criminal IP IT資産検索のproduct、cve_id、redis_versionなどのフィルターを活用することで、外部に露出したRedis資産、脆弱性マッピング済み資産、特定の脆弱バージョン資産を継続的に点検できます。
FAQ
Q1. CVE-2026-23479は認証不要のRCE脆弱性ですか？
いいえ。CVE-2026-23479は、認証済み攻撃者を前提とするRCE脆弱性です。ただし、外部に露出したRedisインスタンスにおいて、弱い認証情報、共有アカウント、過剰なACL権限が同時に存在する場合、実際の攻撃条件が満たされる可能性があります。
Q2. Redis 8.6.2だけが脆弱ですか？
いいえ。Redis 8.6.2は代表的な脆弱バージョンにすぎず、影響範囲はRedis 7.2.0以上8.6.3未満です。運用中のRedisブランチごとに、7.2.14、7.4.9、8.2.6、8.4.3、8.6.3以上が適用されているかを確認する必要があります。
Q3. Criminal IPでCVE検索結果が出なければ安全ですか？
いいえ。CVEベースの検索結果は、バナー情報、バージョン識別の可否、脆弱性マッピング状況によって変動する可能性があります。検索結果がない場合でも、内部のRedis資産が影響を受けるバージョンを使用している可能性があるため、Criminal IPの検索結果と内部資産リストをあわせて照合する必要があります。内部点検では、redis-cli INFO server | grep redis_versionコマンドで実際のバージョンを直接確認し、上記のパッチバージョン表と比較する手順が必要です。
結論
CVE-2026-23479は、Redisのblocked client処理フローで発生したUse-After-Free脆弱性です。コード上ではprocessCommandAndResetClient(c)の戻り値処理に関連する比較的小さな条件から始まったものですが、特定のメモリ負荷条件とブロッキングコマンドのタイミングが重なる必要がある構造であったため、一般的な機能テストやコードレビューだけでは発見が難しい脆弱性だったと考えられます。
脆弱性そのものよりも重要なのは、Redisが実際の運用環境でどこに配置され、どのような権限で使用されているかです。特にRedisがアプリケーションアカウント、セッションデータ、キャッシュ層、内部サービスの接続情報と密接に関係している場合、単一インスタンスの侵害がより広範な内部攻撃フローにつながる可能性があります。
パッチ適用とあわせて、外部から識別可能なRedis資産、過剰なACL権限、共有アカウント、同時に露出している管理ポートの点検を並行して実施する必要があります。特にクラウド環境では、設定変更やテストインスタンスの放置によってRedisが再び露出する可能性があるため、継続的な外部資産モニタリングを通じて、露出状態を定期的に確認することが必要です。
なお、関連して RediShell RCE 脆弱性警報：Redis8,000件超、ただちにアップデート推奨 の記事も参考にできます。
Criminal IP（criminalip.io/ja/register) に登録すると、すぐに脆弱資産の検知を開始できます。さらに、下記ボタンからデモをご依頼いただくことで、エンタープライズ環境において外部に露出した資産を対象としたCriminal IP の脅威インテリジェンス（TI）分析を直接ご確認いただけます。
本レポートは、サイバー脅威インテリジェンス検索エンジン Criminal IP のデータを基に作成されています。
今すぐCriminal IP の無料アカウントを作成すれば、本レポートで引用された検索結果を直接確認したり、さらに膨大な脅威インテリジェンスを自由に検索することができます。
データソース: Criminal IP(https://www.criminalip.io/ja), The Hacker News(https://thehackernews.com/2026/06/autonomous-ai-tool-finds-2-year-old-rce.html)