CVE-2026-66373対策：Azure Linux 3.0のValkey更新手順と8.0.9-1の注意点

CVE-2026-66373は、ValkeyのRESTORE処理に細工したデータを読み込ませることで二重解放を発生させ、条件次第でリモートコード実行につながる脆弱性です。Azure Linux 3.0でValkeyを運用している場合は、最初にrpm -q valkeyで導入済みパッケージを確認してください。

ただし、「azl3 valkey 8.0.9-1がFirstFixedであり、修正版である」という判断には注意が必要です。2026年8月2日時点のMSRC公式VEXでは、0:8.0.9-1.azl3はknown_affected、つまり既知の影響ありとして登録され、修正状況もnone_availableとなっています。8.0.9-1で更新を止めるべきではありません。(Microsoft Security Response Center)

一方、MicrosoftのAzure Linux 3.0向け公式リポジトリには、x86_64版とaarch64版のvalkey-8.0.10-1.azl3が公開されています。Valkey 8.0.10には、複数のコンシューマーが同じNACKを共有する問題への修正が含まれています。実務上は、8.0.10-1以降の最新パッケージへ更新し、サービスを再起動したうえで、MSRCのVEX更新を継続確認するのが安全な対応です。(Microsoft Packages)

CVE-2026-66373の概要

CVE-2026-66373は、ストリームのコンシューマーグループに関するデータをRESTOREで復元するときのメモリ管理に起因する脆弱性です。

項目	内容
CVE番号	CVE-2026-66373
影響	リモートコード実行、プロセス停止、データの機密性・完全性・可用性への影響
脆弱性分類	CWE-415：Double Free（二重解放）
CVSS 3.1	7.5、High
攻撃経路	ネットワーク
必要権限	低権限の認証済みユーザー
攻撃の複雑さ	高
ユーザー操作	不要
Azure Linuxで確認されているパッケージ	azl3 valkey 0:8.0.9-1.azl3
MSRC VEX上の状態	既知の影響あり、修正なし

CVSSベクターはCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:Hです。無認証の外部ユーザーが接続しただけで直ちに攻撃できる脆弱性ではありませんが、攻撃に成功した場合の機密性・完全性・可用性への影響はいずれも「High」と評価されています。(NVD)

二重解放が発生する仕組み

ValkeyやRedisのRESTOREコマンドは、シリアライズされたRDB形式のデータからキーと内部データ構造を復元します。

本脆弱性では、細工したペイロードによって、同じ保留中エントリであるNACKを複数のコンシューマーから参照させます。その後、XGROUP DELCONSUMERによって該当するコンシューマーを削除すると、同じメモリ領域が複数回解放される可能性があります。

正常な処理では、確保したメモリ領域は一度だけ解放されなければなりません。同じ領域を二度解放すると、ヒープの管理情報が破壊され、次のような結果につながります。

• Valkeyプロセスの異常終了
• サービス停止や再起動の繰り返し
• メモリ上のデータ破壊
• 攻撃者が制御するコードの実行

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

どの環境を優先して対応すべきか

次の条件に該当する環境は、優先度を上げて確認してください。

最優先で対応する環境

• アプリケーション用アカウントにRESTORE権限を付与している
• Valkeyへ複数のアプリケーションやテナントから接続できる
• CI/CD、データ移行ツール、バックアップ復元ツールからRESTOREを実行できる
• Valkeyのポートが広いネットワーク範囲から到達可能になっている
• 共通アカウントに+@allなどの過大なACLを付与している
• 外部委託先や第三者が利用する認証情報から接続できる

攻撃成立の可能性が比較的低い環境

• RESTOREを管理者専用アカウントに限定している
• アプリケーション用アカウントではRESTOREを明示的に拒否している
• Valkeyがlocalhostまたは限定されたプライベートネットワークからしか到達できない
• 接続元をNSG、ファイアウォール、コンテナーネットワークで厳格に制限している

後者でも脆弱性がなくなるわけではありません。ネットワーク制限やACLは、修正版を適用するまでの暫定的な防御策と考えてください。

「8.0.9-1がFirstFixed」という情報は再確認が必要

MSRC Security Update Guideの表示や二次情報で8.0.9-1がFirstFixedとして扱われている場合でも、パッケージ名だけを見て修正済みと判断してはいけません。

2026年7月27日更新のMSRC公式VEX Version 2では、次の状態になっています。

• 製品：Azure Linux 3.0
• パッケージ：azl3 valkey 0:8.0.9-1.azl3
• 製品状態：known_affected
• 修正情報：none_available

つまり、公式VEXを基準にすると、8.0.9-1は修正版ではなく、影響を受けるパッケージとして登録されています。(Microsoft Security Response Center)

また、VEXの製品ツリーにパッケージ名が表示されていること自体は、そのパッケージが修正版であることを意味しません。必ずproduct_statusとremediationsの両方を確認する必要があります。

8.0.10-1との関係

Valkey 8.0.10は2026年7月21日にセキュリティリリースとして公開されました。リリースノートには、複数のコンシューマーが同じNACKを共有する不正なストリームRDBを拒否する修正が、CVE-2026-63639として記載されています。破損したコンシューマーPELデータをRDBまたはRESTOREから読み込んだ際の二重解放修正も含まれます。(GitHub)

Microsoftの公式リポジトリには、2026年7月23日付で次のパッケージが掲載されています。

• valkey-8.0.10-1.azl3.x86_64.rpm
• valkey-8.0.10-1.azl3.aarch64.rpm

CVE-2026-66373とCVE-2026-63639は識別子が異なりますが、「複数コンシューマーで共有されたNACK」「RDBまたはRESTORE」「二重解放」という技術説明は密接に一致しています。ただし、両者を正式に同一CVEとして扱うMicrosoftの記録は、確認時点のVEXには反映されていません。

したがって、現時点では次のように判断するのが適切です。

パッケージ	判断	推奨対応
8.0.9-1以前	少なくとも8.0.9-1はMSRCで影響あり	直ちに最新版へ更新
8.0.10-1	Valkey側のshared NACK修正を含む	更新先として優先し、MSRCの修正済み判定を継続確認
8.0.10-1より新しい版	追加修正を含む可能性がある	原則としてリポジトリの最新版を使用
独自ビルド	バージョン番号だけでは判断不可	適用済みコミットやバックポートを確認

FirstFixedは、本来「その修正を初めて含んだ最小バージョン」を示す情報です。仮にFirstFixedが正しく示されている場合でも、古いFirstFixedへ固定するのではなく、互換性を確認したうえで最新のセキュリティ更新版を導入するのが基本です。

Azure Linux 3.0でValkeyの導入状況を確認する

OSの種類とバージョンを確認する

最初に、対象サーバーがAzure Linux 3.0であることを確認します。

cat /etc/os-release

VERSION_IDや製品名を確認し、Azure Linux 3.0の汎用VMなのか、AKSのノードOSなのかも整理してください。

インストール済みValkeyパッケージを確認する

RPMパッケージのバージョン、リリース番号、アーキテクチャを確認します。

rpm -q --qf '%{NAME} %{VERSION}-%{RELEASE} %{ARCH}\n' valkey

8.0.9-1が導入されている場合の表示例は次のとおりです。

valkey 8.0.9-1.azl3 x86_64

パッケージが入っていない場合は、次のようなメッセージが表示されます。

package valkey is not installed

ただし、ホストOSにRPMパッケージがなくても、コンテナー内でValkeyを実行している可能性があります。RPMが見つからないだけで調査を終了しないでください。

リポジトリで提供されている版を確認する

キャッシュされた古いメタデータを参照しないよう、リポジトリ情報を更新します。

sudo dnf --refresh makecache
dnf list --showduplicates valkey
dnf info valkey

一覧に8.0.10-1.azl3または、それより新しい版が表示されるかを確認してください。

Microsoftは、汎用Azure LinuxのCVE修正をパッケージ更新として配信し、dnf updateで適用する手順を案内しています。(Microsoft Learn)

実行ファイルのバージョンも確認する

valkey-server --version

RPMの表示とvalkey-server --versionの結果が異なる場合は、次の可能性があります。

• 独自にビルドしたValkeyを使用している
• /usr/local/binなど別の場所に古いバイナリが残っている
• パッケージ更新後にプロセスを再起動していない
• コンテナー内のValkeyを確認できていない

次のコマンドで、実際に呼び出されるバイナリのパスも確認できます。

command -v valkey-server
readlink -f "$(command -v valkey-server)"

Azure Linux 3.0でValkeyを更新する手順

更新前に復旧手段を確認する

本番環境では、更新前に次の項目を確認します。

• RDBやAOFのバックアップが取得できているか
• バックアップからの復元手順を検証済みか
• レプリカやフェイルオーバー構成が正常か
• 接続中のアプリケーションへの影響を把握しているか
• 更新前のパッケージ版と設定ファイルを記録したか
• 更新後にサービスを再起動できる時間帯か

RESTOREやRDBに関係する脆弱性だからといって、本番環境で無計画にバックアップ生成や復元テストを実行すると、I/O負荷やメモリ使用量が増えることがあります。既存の運用手順に従って実施してください。

Valkeyパッケージを更新する

まず、更新候補を表示します。

sudo dnf --refresh makecache
dnf list --showduplicates valkey

内容を確認したうえで、Valkeyを更新します。

sudo dnf --refresh update valkey

依存パッケージを含むOS全体のセキュリティ更新も適用する場合は、次のコマンドを使用します。

sudo dnf --refresh update

Microsoftの公式手順でも、汎用Azure Linuxではdnfによるパッケージ更新が推奨されています。(Microsoft Learn)

Valkeyサービスを再起動する

パッケージの更新だけでは、起動中のValkeyプロセスが古い実行コードを保持したままになることがあります。

サービス名を確認します。

systemctl list-unit-files | grep -i valkey

標準のvalkey.serviceを利用している場合は、次のように再起動します。

sudo systemctl restart valkey
sudo systemctl status valkey --no-pager

独自のsystemdユニット、コンテナー、Kubernetes、プロセス管理ツールを使用している場合は、それぞれの管理方法で再起動してください。

更新後のパッケージ版を確認する

rpm -q --qf '%{NAME} %{VERSION}-%{RELEASE} %{ARCH}\n' valkey
valkey-server --version

期待する例は次のとおりです。

valkey 8.0.10-1.azl3 x86_64

その後、既存のTLS設定と認証方法を使って、次の項目を確認します。

• PINGに正常応答する
• 読み書きが正常に行える
• レプリケーションが同期している
• クラスターのスロット状態が正常である
• アプリケーションの接続エラーが増えていない
• Valkeyログにクラッシュやメモリエラーが出ていない

レプリカやクラスター構成での更新方法

複数ノード構成では、全ノードを同時に停止しないようにします。

一般的には、次の順序で段階的に更新します。

1. レプリカの健全性と同期状態を確認する
2. レプリカ側から1台ずつ更新する
3. 更新後に再同期を確認する
4. 必要に応じてフェイルオーバーする
5. 旧プライマリを更新する
6. クラスター全体の状態を確認する

実際の順序は、Sentinel、Cluster、ロードバランサー、独自のフェイルオーバー制御など、採用している構成によって異なります。

単に「サービスが起動した」だけで完了とせず、レプリケーション遅延、クラスター状態、アプリケーションエラー率まで確認してください。

コンテナーやAKSでは更新方法が異なる

ホストOSのValkeyパッケージと、コンテナーイメージ内のValkeyは別物です。

コンテナーで実行している場合は、使用中のイメージを確認します。

podman ps --format '{{.Names}}\t{{.Image}}'
docker ps --format '{{.Names}}\t{{.Image}}'

古いValkeyを含むコンテナーイメージを使用している場合、ホストOSでdnf updateを実行してもコンテナー内のValkeyは更新されません。修正版を含むイメージへ差し替え、再デプロイする必要があります。

また、Microsoftが案内する更新方法はデプロイ形態によって異なります。

環境	更新方法
汎用Azure Linux 3.0 VM	dnf updateでパッケージを更新
AKS用Azure Linux Container Host	更新されたノードイメージを適用
AKS用Azure Container Linux	不変OSのためNodeImageチャネルでノードイメージを更新
Valkeyを実行するワークロードコンテナー	Valkey修正版を含むコンテナーイメージへ更新

AKSノードOSを更新しても、Pod内のValkeyイメージが自動的に更新されるわけではありません。ノードOSとワークロードイメージの両方を別々に確認してください。(Microsoft Learn)

すぐ更新できない場合の暫定対策

アプリケーション用アカウントからRESTORE権限を外す

通常のWebアプリケーションや業務システムがRESTOREを使わない場合は、アプリケーション用ユーザーから権限を外します。

現在のACLを確認します。

ACL GETUSER appuser

RESTOREを拒否する設定例は次のとおりです。

ACL SETUSER appuser -restore

appuserは実際のユーザー名に置き換えてください。設定後は、アプリケーションの通常処理に影響がないかを確認し、ACLファイルや構成管理にも永続化します。

管理者を含むすべてのユーザーから無計画に権限を削除すると、バックアップ復元や移行作業ができなくなるため注意が必要です。

ネットワーク到達範囲を限定する

次の状態になっていないか確認してください。

• TCP 6379番ポートをインターネットへ直接公開している
• NSGの受信元が0.0.0.0/0になっている
• 不要なサブネットやコンテナーネットワークから接続できる
• 開発環境と本番環境で同じ認証情報を使用している
• 踏み台を経由せず管理ポートへ直接接続できる

Valkeyは、必要なアプリケーションと管理端末からだけ到達できる構成にします。

過大なACLを見直す

アプリケーション用ユーザーに+@allや管理系コマンドを一括で付与している場合は、必要なコマンドだけを許可する最小権限のACLへ変更します。

特に、データ移行や運用ツールで使用する管理者アカウントを、通常のアプリケーション接続に流用しないことが重要です。

クラッシュや不審な再起動を確認する

標準のsystemdユニットを使用している場合は、ログとコアダンプを確認します。

sudo journalctl -u valkey --since "2026-07-24"
sudo coredumpctl list valkey

次の兆候がないかを調べてください。

• segmentation fault
• double freeやheap corruptionに関するメッセージ
• 原因不明のValkey再起動
• 短時間に繰り返される接続切断
• 身に覚えのないRESTORE実行
• 不審な認証元や通常と異なる接続元

ログに異常がないことだけで、安全だったと断定することはできません。コマンド監査を有効にしていない環境では、過去のRESTORE実行を追跡できない場合があります。

更新時に失敗しやすいポイント

8.0.9-1を修正版として固定する

確認時点のMSRC公式VEXでは、8.0.9-1は影響ありです。パッケージ名がアドバイザリに掲載されているだけで、修正版と判断してはいけません。

Redisの8.8.0とValkeyの8.0.10を単純比較する

CVEの元レコードではRedis 8.8.0未満が影響対象とされていますが、このバージョン境界をValkeyへそのまま適用することはできません。

RedisとValkeyは別のリリース系列です。ディストリビューション側でバックポートされる場合もあるため、次の情報を組み合わせて判断します。

• MSRCのAzure Linux向けVEX
• Azure LinuxのRPMパッケージ版
• Valkey公式リリースノート
• RPMの変更履歴や適用済みパッチ
• 更新後の脆弱性スキャン結果

パッケージ更新後に再起動しない

RPMが8.0.10-1へ更新されても、起動中のプロセスが更新前のコードを使用し続ける可能性があります。更新後は、計画的にValkeyプロセスを再起動してください。

ホストOSだけ更新する

Valkeyをコンテナーで実行している場合、ホストOSのRPM更新はコンテナー内へ反映されません。コンテナーイメージのタグだけでなく、可能であればダイジェストと内部パッケージ版も確認します。

脆弱性スキャナーの表示だけで判断する

スキャナー側のCVEデータやVEX取り込みが遅れることがあります。更新直後に検出が残っている場合は、次を確認してください。

• スキャナーの脆弱性データベースが最新か
• 対象がホストかコンテナーか
• 実際に読み込まれているバイナリはどれか
• MSRCの最新VEXが反映されているか
• CVE-2026-66373とCVE-2026-63639のどちらで検出されているか

侵害が疑われる場合は更新だけで終わらせない

リモートコード実行が成立した可能性がある場合、修正版への更新は再攻撃を防ぐ対策にはなりますが、すでに侵入した攻撃者や設置された不正ファイルを除去するものではありません。

次の対応を検討してください。

• 対象ホストをネットワークから隔離する
• ログ、メモリ、コアダンプ、ディスクイメージを保全する
• Valkeyとアプリケーションの認証情報を変更する
• 同じ認証情報を使用している別システムも調査する
• 不審なプロセス、systemdユニット、cron、SSH鍵を確認する
• 信頼できるイメージからホストやコンテナーを再構築する
• Valkey内の重要データが改変されていないか検証する
• 組織のインシデント対応手順に沿って報告する

CVE-2026-66373は、攻撃成功時の機密性・完全性・可用性への影響がすべてHighです。サービスが稼働しているだけでは、侵害されていないことの証明にはなりません。(NVD)

まとめ

Azure Linux 3.0でValkeyを使用している場合は、次の順序で対応してください。

1. rpm -q valkeyで導入済みパッケージを確認する
2. 8.0.9-1を修正版と判断せず、影響ありとして扱う
3. dnf list --showduplicates valkeyで最新の提供版を確認する
4. 原則として8.0.10-1以降の最新パッケージへ更新する
5. Valkeyプロセスを再起動し、実行版と動作を確認する
6. RESTORE権限とネットワーク到達範囲を最小化する
7. MSRC VEXでCVE-2026-66373の修正済みパッケージが明示されるまで継続監視する
8. コンテナーやAKSでは、ホストとは別にイメージとノードOSを更新する

最も重要なのは、アドバイザリに表示されたパッケージ名を、そのまま修正版と解釈しないことです。2026年8月2日時点では、MSRC公式VEXは8.0.9-1を影響ありとしています。リポジトリの最新パッケージへ更新し、ACLとネットワーク制限を併用しながら、Microsoftによる最終的な修正済み判定を確認してください。