Redisに認証なしの乗っ取り欠陥、暗号化通信ありが対象 CVE-2026-81934

データを高速に読み書きするために広く使われているソフト「Redis」に、外部から乗っ取られる恐れのある欠陥「CVE-2026-81934」が登録されました。2026年8月27日にNVD（米国の脆弱性データベース）で公開され、深刻度は10点満点で9.8と評価されています。

Redisは、Webサイトのログイン状態やアクセス集計、順位表といった「すぐ取り出したいデータ」をメモリ上に置いておくためのソフトです。データベースの手前に置いて負荷を下げる用途で、国内でも多くのWebサービスやスマートフォンアプリの裏側で動いています。

ただし対象になるのは、Redisの通信を暗号化する設定を有効にしている場合だけです。Redisは初期状態でこの暗号化が切られており、社内ネットワークの中だけで使っている構成では有効にしていないことも珍しくありません。まず自分の環境がどちらなのかを確認するところから始めます。

修正自体は2026年8月17日に公開済みで、そこから10日遅れて番号が付いた形です。すでに8月中旬の更新を当てている環境は、この件の作業は終わっています。

何が起きるのか

CVE-2026-81934: 暗号化通信の待ち行列で、解放済みのメモリを使ってしまう

Redisの内部には、暗号化通信で受け取ったデータのうち、まだ処理していない分を並べておく待ち行列があります。この行列を扱う tlsProcessPendingData() という処理に問題がありました。

Redis公式のリリースノートは、この修正を「あるコマンドが、待ち行列に並んでいる別の接続を閉じたときに、解放済みのメモリを使ってしまう」と説明しています。接続を閉じて後片付けが済んだはずの領域を、行列側がまだ生きているものとして触りにいく形です。

この種の問題は、攻撃者が中身を仕込むことができれば、そのままプログラムの乗っ取りにつながります。NVDの記載では「認証を経ていない遠隔の攻撃者が、Redisサーバーの権限で任意のコマンドを実行できる可能性がある」とされています。

ここは注意が要ります。この評価はRedis社自身が出したものではなく、第三者の登録機関によるものです。Redisは自社のセキュリティ情報一覧にこの番号を掲載しておらず、リリースノートにも番号を振っていません。一方、Redisから分かれた互換ソフトのValkeyは、同じ性質の欠陥を7月にCVE-2026-56684として修正し、その際は「認証済みのクライアントが CLIENT KILL を使って引き起こせる」と説明しています。

つまり、実際に必要な条件が「認証なし」なのか「認証済みの接続が1本必要」なのかは、公開情報のあいだで食い違っています。ただし、どちらであっても対処は同じ更新です。パスワードを設定していないRedisをうっかり外に出している環境では、この区別に意味がなくなる点も変わりません。

影響するバージョンと、直ったバージョン

NVDの記載は8系列の修正版だけを挙げていますが、Redis公式のリリースノートを見ると、この修正は7系列と6系列にも同じ日に入っています。古い系列を使っている環境が見落とさないよう、公式の配布物にもとづいて全部並べます。

修正版はいずれも2026年8月17日に公開されました。6.2系にまで手当てが回っているのは、この欠陥が古くから残っていたことを示しています。

Redisは8系列から番号の付け方が変わり、8.2・8.4・8.6・8.8・8.10がそれぞれ独立した系列として並行して保守されています。8.10.1へ上げるのが最新版という意味ではなく、いま使っている系列の中で末尾の数字を上げるのが正しい手順です。

Redisから分かれた互換ソフトのValkeyを使っている場合は、別の番号での対応になります。Valkeyは同じ性質の欠陥をCVE-2026-56684として2026年7月21日に公開し、9.1.1・9.0.5・8.1.9・8.0.10で修正しました。こちらを使っている環境は、Redisの番号ではなくValkeyのリリースノートを基準に確認してください。

自分のRedisが対象かどうかを確認する

確認するのは2つです。バージョンと、暗号化通信を使っているかどうか。

まずバージョンです。

redis-server --version
redis-cli INFO server | grep redis_version

次に、暗号化通信の設定です。Redisでは tls-port という項目で暗号化通信の受け口を指定します。初期値は0で、これは無効という意味です。

redis-cli CONFIG GET tls-port

結果が 0 であれば、この欠陥の条件を満たしません。6379や6380といった番号が返ってきた場合は、暗号化通信が動いているので対象です。設定ファイル（多くは /etc/redis/redis.conf）で tls-port の行を直接見ても構いません。

そもそも暗号化通信を組み込まずにビルドされたRedisでは、この設定項目自体が存在せず、コマンドが空を返します。その場合も対象外です。

クラウド事業者が提供するRedis互換のサービス（Amazon ElastiCache、Google Cloud Memorystore、Azure Cache for Redisなど）を使っている場合、更新は事業者側の作業です。これらは暗号化通信を既定で有効にしている構成が多いため、各社の告知を確認してください。利用者側でできるのは、保守用の更新受け入れ時間帯（メンテナンスウィンドウ）を設定しているか、自動更新が有効かの確認までです。

社内のどこでRedisが動いているかを洗い出す

Redisは、担当者が意識して導入したものだけではありません。他の製品に部品として組み込まれていることが多く、資産管理表に「Redis」と書かれていない場所で動いているのが普通です。

よくある場所を挙げると、Webアプリの土台となる枠組みが使うセッション保管、非同期処理の順番待ち行列、社内のチャットツールや課題管理ツールに同梱されているもの、監視やログ集約の製品が内部で持っているもの、コンテナ基盤の上で他のアプリと一緒に立ち上がっているものなどです。

洗い出しの取っかかりとしては、サーバー上で動いているプロセスと、待ち受けている通信の口を見るのが早道です。

# 動いているプロセスを探す
ps aux | grep redis-server

# 待ち受けている通信の口を見る（6379が既定、6380が暗号化通信の慣例）
ss -tlnp | grep -E '6379|6380'

コンテナ基盤で動かしている場合は、稼働中のコンテナのイメージ名にredisやvalkeyが含まれるものを拾います。イメージのタグに版が入っているので、そのまま今回の表と照合できます。

この機会に見ておきたいのが、Redisが外から届く場所にいないかです。ss の結果で待ち受け先が 0.0.0.0 や * になっているものは、機器のすべての通信口で待ち受けています。設定ファイルの bind を必要な範囲に絞り、パスワード（requirepass）を設定しているかも確認しておくと、今回の件に限らず効いてきます。

攻撃されているのか

2026年8月28日時点で、この欠陥が実際の攻撃に使われたという報告は確認されていません。CISAが公開している、悪用が確認された脆弱性のカタログにも収載されていません。

ただし、NVDの参照情報には第三者が公開した動作確認用のプログラム（PoC）の置き場所が載っています。手口の一部がすでに公開の場に出ている状態なので、時間が経つほど条件は不利になります。

Redisは過去にも、実際の攻撃で狙われた実績のあるソフトです。インターネットに直接さらされたRedisが探索されて中身を抜かれる事例は繰り返し起きており、今回の欠陥とは別に、外から届く場所にRedisを置いていないかは定期的に見ておく価値があります。

同じ更新で、ほかにも直っているもの

8月17日の更新は、この1件だけを直したものではありません。リリースノートには複数の修正が並んでおり、そのうちいくつかは暗号化通信を使っていない環境にも関係します。

まず、細工されたデータファイル（RDB）を読み込ませることでメモリを壊し、任意のコード実行につながる問題が2件挙がっています。ひとつはCVE-2026-62356として番号が付いており、確率的なデータ構造の読み込み時に確保サイズを誤るというもの。もうひとつは、クラスタ構成の情報に範囲外の値が入っているとメモリが壊れるというものです。他所から受け取ったバックアップファイルを復元する運用がある環境では、こちらの方が現実的な入口になり得ます。

加えて、コマンドごとに触れるデータを制限する機能（ACL）の抜けが2件あります。SORT、GEORADIUS、XREAD などで、制限の判定に使うデータ名と実際に触るデータ名がずれるため、本来は読めないはずのデータに手が届く場合があります。複数の利用者やアプリでひとつのRedisを共有し、ACLで区切っている環境では効いてきます。

つまり、暗号化通信を使っていないから今回の件は関係ない、という判断で更新を先送りにすると、別の穴が残ります。8月17日以降の版へ上げること自体は、どの構成でも意味があります。

何をすればいいか

対処は、いま使っている系列の最新版へ上げることに尽きます。回避策として公式が示しているものはなく、暗号化通信を切るという選択は、通信内容が平文で流れることを受け入れる話になるため、対策としては勧められません。

優先順位を付けるなら、暗号化通信を有効にしていて、かつRedisに届く経路が社内に閉じていないものが最初です。次に、暗号化通信は使っていないが、外部から受け取ったバックアップファイルを読み込む運用があるもの。最後に、社内のみで完結していてACLも使っていないものという順になります。

更新の当て方は導入方法によって変わります。配布元のパッケージを使っているならパッケージ管理の更新、コンテナで動かしているならイメージのタグを上げて入れ替え、自前でビルドしているなら該当バージョンのソースから入れ直します。レプリケーション（複製）を組んでいる場合は、複製側から順に上げて、最後に主となるサーバーを切り替える手順が一般的です。

更新に時間がかかる環境では、その間にRedisへ届く経路を狭めておきます。ファイアウォールでアプリケーションサーバーからの通信だけを通す、待ち受け先を内部のアドレスに限定する、といった措置です。これは今回の欠陥を塞ぐものではありませんが、攻撃者が接続そのものを張れなければ、条件は成立しません。

すでに攻撃を受けていないかを確かめたい場合、Redisは既定ではコマンドの実行履歴を残しません。redis-cli CLIENT LIST で現在つながっている接続元を見る、サーバーのログに異常終了の記録がないかを見る、といった間接的な確認になります。心当たりのない接続元や、繰り返し落ちている記録があれば、そこを起点に調べます。

更新後は、redis-cli INFO server で版が変わっていることと、アプリケーション側の接続が復帰していることを確認します。Redisはメモリ上のデータを扱うため、再起動でキャッシュが消えます。再構築の負荷がデータベース側に一気に向かうことがあるので、利用の少ない時間帯を選ぶのが無難です。

参照元

• ▸ NVD - CVE-2026-81934（2026年8月27日公開）
• ▸ Redis - リリースノート 8.10.1（2026年8月17日）
• ▸ Redis - リリースノート 6.2.24（2026年8月17日）
• ▸ Redis - 修正コミット
• ▸ Valkey - リリースノート 9.1.1（CVE-2026-56684）（2026年7月21日）
• ▸ Redis - セキュリティアドバイザリ一覧