MENU

CVE-2026-42769とは？Azure Linux 3.0のOpenSSL更新手順と影響確認

Linux

Azure Linux 3.0で azl3 openssl 3.3.7-3 を利用している場合は、OpenSSL関連パッケージを3.3.7-4以上へ更新してください。更新後は、OpenSSLの共有ライブラリを読み込んでいるサービスを再起動し、コンテナ環境ではイメージの再ビルドと再デプロイも必要です。Microsoftのリポジトリでは、openssl、openssl-libs、openssl-devel、openssl-perl、openssl-static の3.3.7-4が公開されています。(Microsoft Security Response Center)

CVE-2026-42769は、一般的なHTTPS通信を無条件に破る脆弱性ではありません。OpenSSLのCMP機能を使ったルートCA鍵更新で、攻撃者が用意したルートCA証明書を新しい信頼アンカーとして受け入れさせる可能性がある問題です。攻撃には有効なRA相当の認証情報が必要ですが、CMPを使って社内PKIや証明書ライフサイクルを管理している環境では、優先度を上げて対応する必要があります。([OpenSSL Library][2])

目次

CVE-2026-42769とは

CVE-2026-42769は、OpenSSLのCMPに実装された rootCaKeyUpdate 処理の証明書検証に関する脆弱性です。

CMPはCertificate Management Protocolの略で、証明書の発行、更新、失効などを自動化するためのプロトコルです。今回問題になったのは、ルートCAの鍵を更新するときに利用される id-it-rootCaKeyUpdate という処理です。

項目内容
脆弱性番号CVE-2026-42769
対象機能OpenSSL CMPの rootCaKeyUpdate
Azure Linux 3.0の対象azl3 openssl 3.3.7-3
Azure Linux 3.0の修正版azl3 openssl 3.3.7-4以上
想定される影響不正なルートCA証明書を新しい信頼アンカーとして受け入れる可能性
攻撃に必要な条件CMPメッセージ保護の検証を通過できるRA相当の認証情報
OpenSSLによる深刻度Low
MSRCの個別回避策掲載なし
基本対応修正版パッケージへの更新

OpenSSLは本脆弱性の深刻度をLowとしています。ただし、これは攻撃成立までに有効なRAレベルの資格情報が必要であることなど、攻撃条件の厳しさを反映した評価です。成立した場合の影響は、CMPクライアントが信頼するルートCAの置換であるため、PKI環境では「Lowだから後回し」と単純に判断すべきではありません。([OpenSSL Library][2])

CMPの信頼アンカー置換が起きる仕組み

正常なルートCA鍵更新

ルートCAの鍵を安全に更新する場合、CMPクライアントは、おおむね次の流れで新しいルートCAを信頼します。

  1. クライアントは現在のルートCA証明書を信頼している
  2. 新しいルートCA証明書が、現在のルートCAの秘密鍵で署名される
  3. クライアントが署名を検証する
  4. 検証に成功した新しいルートCA証明書を信頼アンカーとして採用する

OpenSSLの説明では、現在のルートCAを oldRoot、古いルートCA鍵で署名された新しいルートCA証明書を newWithOld と表現しています。

この処理では、newWithOld が本当に oldRoot の鍵で署名されているかを確認することが重要です。ここを正しく検証できなければ、新旧ルートCA間の信頼を安全に引き継げません。

certとissuerの取り違えで検証が機能しなかった

脆弱な実装では、証明書チェーンを構築するときに、発行者として使用すべき oldRoot ではなく、検証対象である newWithOld がチェーンに追加されていました。

その結果、古いルートCA鍵による署名を確認するはずの処理が有効に機能せず、別の場所で確認される発行者名や署名アルゴリズムなどの条件だけで処理が進む可能性がありました。([OpenSSL Library][2])

攻撃者がCMPメッセージ保護を通過できるRA相当の認証情報を持っている場合、次のような攻撃が成立する可能性があります。

  1. 攻撃者が新しい鍵ペアを作成する
  2. その鍵を使って攻撃者管理下の自己署名ルートCA証明書を作成する
  3. 不正な rootCaKeyUpdate 応答をCMPクライアントへ送る
  4. 脆弱なクライアントが不正なルートCAを新しい信頼アンカーとして受け入れる

これは、OS全体のルート証明書ストアが無条件に書き換えられるという意味ではありません。影響するのは、該当するOpenSSL CMP処理を利用し、検証結果を信頼アンカーの更新に使用するアプリケーションです。

Azure Linux 3.0で確認すべきパッケージ

Azure Linux 3.0では、OpenSSL本体だけでなく、実際にアプリケーションから読み込まれる openssl-libs なども確認する必要があります。

Microsoftのパッケージリポジトリでは、次のOpenSSL関連パッケージについて3.3.7-3と3.3.7-4が確認できます。(Microsoft Packages)

パッケージ主な用途対応
opensslOpenSSLのコマンドラインツール3.3.7-4以上へ更新
openssl-libslibssl、libcryptoの共有ライブラリ3.3.7-4以上へ更新
openssl-devel開発用ヘッダー、リンク用ファイルインストール済みなら更新
openssl-perlOpenSSL関連のPerlスクリプトインストール済みなら更新
openssl-static静的リンク用ライブラリ更新後に利用アプリを再ビルド

特に重要なのは openssl-libs です。openssl コマンドだけを更新しても、アプリケーションが古い libssl や libcrypto を読み込んでいれば、対策が完了したとは判断できません。

また、MSRCの影響製品情報では、Azure Linux 3.0の nodejs 24.14.1-3 や cloud-hypervisor 51.1.56-1 も確認対象に含まれます。ただし、パッケージが影響製品として列挙されていることと、各環境でCMP攻撃経路が実際に到達可能であることは同じではありません。固定版を推測して個別に置き換えるのではなく、Azure Linuxのリポジトリから提供される最新パッケージへ更新してください。(Microsoft Security Response Center)

OpenSSL公式のバージョン情報だけで判定してはいけない理由

OpenSSL公式では、複数の上流ブランチについて修正版が案内されています。一方、Azure Linux 3.0では、上流のバージョン番号とは異なる 3.3.7-3.azl3 が対象となり、3.3.7-4.azl3 で修正されています。([OpenSSL Library][2])

Linuxディストリビューションのパッケージには、上流版へ独自の修正やバックポートが加えられることがあります。そのため、次のような確認だけでは正しく判定できません。

openssl version

修正後も上流バージョン部分は OpenSSL 3.3.7 と表示される可能性があります。Azure Linuxでは、RPMのリリース番号を含む次の形式で確認することが重要です。

openssl-3.3.7-4.azl3
openssl-libs-3.3.7-4.azl3

脆弱性スキャナーが上流の 3.3.7 という数字だけを見て検出を続ける場合も、直ちに未修正と判断してはいけません。RPMの完全なバージョンとリリース番号、Microsoftのセキュリティ情報を照合したうえで判定します。

対応優先度の判断基準

CVE-2026-42769は、OpenSSLを利用するすべての通信から直ちに悪用できる脆弱性ではありません。環境ごとの優先度は、CMPの利用状況とRA資格情報の管理状況で判断します。

環境対応優先度判断理由
CMPでルートCA鍵更新を実施している最優先脆弱な処理を直接利用している
CMPクライアントを運用している高現在鍵更新の予定がなくても、機能が有効なら到達可能性がある
RA資格情報を外部システムや委託先で扱う高資格情報が侵害された場合の攻撃経路が増える
OpenSSLを通常のTLS通信だけに利用している通常の緊急パッチ対応本脆弱性の攻撃経路には直結しにくいが、共有ライブラリとして更新すべき
コンテナ内に3.3.7-3を含む別途対応が必要ホストOSの更新だけではコンテナイメージは変わらない
OpenSSLを静的リンクしている別途対応が必要RPM更新後も既存バイナリには古いコードが残る可能性がある

CMPを利用していないと確認できた場合でも、長期間放置する理由にはなりません。将来の構成変更や把握できていない依存関係を考慮し、通常のセキュリティ更新期間内に適用してください。

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

Azure Linux 3.0では、パッケージ管理に tdnf を使用します。(Microsoft Learn)

OSとインストール済みバージョンを確認する

最初に、対象ホストがAzure Linux 3.0であることを確認します。

cat /etc/os-release

続いて、インストール済みのOpenSSL関連RPMを確認します。

rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' \
  | grep '^openssl' \
  | sort

確認対象は、バージョン番号だけでなくリリース番号まで含めた文字列です。

openssl-3.3.7-3.azl3.x86_64
openssl-libs-3.3.7-3.azl3.x86_64

このように 3.3.7-3.azl3 が表示される場合は、更新対象です。

OpenSSLコマンドの情報も補助的に確認できます。

openssl version -a

ただし、この出力だけではAzure Linux固有の -3 と -4 を区別できない場合があります。最終判断には必ずRPM情報を使ってください。

リポジトリ情報を更新する

修正版が候補に表示されない場合に備え、メタデータを更新します。

sudo tdnf clean all
sudo tdnf makecache

利用可能なOpenSSLパッケージを確認します。

tdnf info openssl
tdnf info openssl-libs

候補バージョンが 3.3.7-4.azl3 以上であることを確認してください。

推奨方法はシステム全体の更新

依存関係を含めて整合性を保つには、システム全体を更新する方法が確実です。

sudo tdnf update

本番環境では、表示される更新対象を確認してからトランザクションを承認します。

変更管理上、OpenSSL関連だけを更新する必要がある場合は、最低限次を同じトランザクションで更新します。

sudo tdnf update openssl openssl-libs

事前にインストール済みパッケージ名を確認し、openssl-devel、openssl-perl、openssl-static が入っている場合は、それらも更新対象へ加えます。

rpm -qa --qf '%{NAME}\n' \
  | grep '^openssl' \
  | sort -u

パッケージを個別のタイミングで更新すると、OpenSSL本体と共有ライブラリのリリース番号が一時的にずれる可能性があります。関連パッケージはできるだけ一括して更新してください。

修正版が適用されたことを確認する

更新後、再度RPM情報を確認します。

rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' \
  openssl openssl-libs

期待する結果は次の形式です。アーキテクチャ部分は環境によって異なります。

openssl-3.3.7-4.azl3.x86_64
openssl-libs-3.3.7-4.azl3.x86_64

古いリリースが残っていないことも確認します。

rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' \
  | grep '^openssl' \
  | grep '3\.3\.7-3'

何も表示されなければ、インストール済みのOpenSSL関連RPMから3.3.7-3は除かれています。

更新後はサービス再起動が必要

RPMを更新しても、すでに起動しているプロセスは、メモリ上に読み込んだ古い libssl や libcrypto を使い続けることがあります。

OpenSSLを利用するサービスを特定できる場合は、更新後に個別に再起動します。

sudo systemctl restart <service-name>

利用プロセスを漏れなく特定できない場合や、複数の基盤サービスがOpenSSLを利用している場合は、メンテナンス時間を確保してOSを再起動する方法が確実です。

sudo reboot

再起動が常に必須というわけではありませんが、パッケージ更新だけで対応完了と判断しないことが重要です。

コンテナと静的リンクは別途対応する

コンテナはイメージを再ビルドする

Azure Linuxホストを更新しても、その上で動くコンテナイメージ内のRPMは更新されません。

コンテナでAzure Linux 3.0をベースイメージとして使っている場合は、次の対応が必要です。

  1. ビルド時にリポジトリ情報を更新する
  2. OpenSSL関連パッケージを3.3.7-4以上へ更新する
  3. イメージを再ビルドする
  4. 脆弱な旧イメージを使うコンテナを再デプロイする
  5. すべてのレプリカが新しいイメージへ切り替わったことを確認する

実行中コンテナへ一時的にパッケージ更新を行っても、コンテナを作り直せば元の脆弱なイメージへ戻ります。修正はDockerfileやCI/CDパイプラインへ反映してください。

静的リンクしたアプリケーションは再ビルドする

openssl-static を使ってビルド済みの実行ファイルには、OpenSSLのコードがバイナリ内へ組み込まれている可能性があります。

動的リンクかどうかは、次のように確認できます。

ldd /path/to/application | grep -E 'libssl|libcrypto'

libssl.so や libcrypto.so が表示されれば、通常は共有ライブラリを利用しています。表示されず、アプリケーションがOpenSSL機能を内包している場合は、静的リンクや独自同梱の可能性を調査してください。

静的リンクされた既存バイナリは、OS側の openssl-static パッケージを更新しただけでは修正されません。修正版ライブラリを使ってアプリケーションを再ビルドし、再配置する必要があります。

FIPSモードでも更新は必要

OpenSSLは、今回の脆弱なコードがFIPSモジュールの境界外にあるため、FIPSモジュール自体は影響を受けないと説明しています。([OpenSSL Library][2])

ただし、これは「FIPSモードを有効にしているシステムは脆弱ではない」という意味ではありません。

CMPの処理はFIPSモジュール外のOpenSSLコードで実行されます。FIPS対応環境であっても、アプリケーションが該当するCMP処理を利用しているなら、OpenSSLパッケージの更新が必要です。

個別の回避策がない場合の暫定対策

MSRCでは、CVE-2026-42769に対する個別の回避策は示されていません。したがって、3.3.7-4以上への更新が正式な対策です。(Microsoft Security Response Center)

すぐに更新できない場合は、露出を減らすために次の対策を検討します。

  • CMPによるルートCA鍵更新を一時停止する
  • CMPエンドポイントへの接続元を管理ネットワークへ限定する
  • RA資格情報へアクセスできるシステムと担当者を最小限にする
  • 不要なRA資格情報を失効させる
  • ルートCA更新を自動承認せず、証明書フィンガープリントを帯域外で確認する
  • rootCaKeyUpdate に関する要求や応答を監視する
  • 新しく登録された信頼アンカーを既知の正しい値と照合する

これらは攻撃経路を狭めるための暫定措置であり、修正版への更新を置き換えるものではありません。

不正な信頼アンカーが登録されていないか確認する

CMPを使ってルートCAを更新した履歴がある環境では、パッチ適用だけでなく、現在の信頼アンカーが正しいかも確認します。

PEM形式のルートCA証明書であれば、次のコマンドでSHA-256フィンガープリントを確認できます。

openssl x509 \
  -in /path/to/root-ca.pem \
  -noout \
  -subject \
  -issuer \
  -fingerprint \
  -sha256

表示された値を、構成管理台帳、オフライン保管した証明書情報、CA運用手順書などに記録された既知のフィンガープリントと照合します。

あわせて、CMPクライアントとサーバーのログから次の点を確認してください。

  • 予定されていないルートCA鍵更新がないか
  • 通常とは異なるRA資格情報が使われていないか
  • 管理者が承認していない新しいルートCA証明書がないか
  • ルートCA更新の前後で証明書フィンガープリントが変わっていないか
  • CMPエンドポイントへの不審な接続がないか

不正な信頼アンカーが疑われる場合は、単なるパッケージ更新で完了とせず、CMP通信の停止、RA資格情報の失効・再発行、正規の経路による信頼アンカーの復旧、不正なCA配下で発行された証明書の調査を行います。

対応時に起きやすい失敗

openssl versionだけで修正済みと判断する

修正前後とも上流バージョン部分が 3.3.7 と表示される可能性があります。Azure Linuxでは、RPMのリリース番号が -3.azl3 か -4.azl3 かを確認してください。

opensslだけ更新してopenssl-libsを残す

アプリケーションが実際に利用するのは、主に openssl-libs に含まれる共有ライブラリです。関連パッケージは同じトランザクションで更新します。

更新後にサービスを再起動しない

長時間稼働しているプロセスは、更新前のライブラリをメモリ上で使い続ける可能性があります。サービス再起動またはOS再起動までを作業手順に含めてください。

ホストOSだけ更新してコンテナを放置する

ホストとコンテナのファイルシステムは別です。コンテナイメージを再ビルドし、実行中の全コンテナを新しいイメージへ切り替える必要があります。

FIPSモードだから安全だと判断する

FIPSモジュール自体が非影響でも、CMPを処理するOpenSSLコードまで非影響とは限りません。FIPS利用環境でもパッケージを更新してください。

スキャナーの検出結果だけで未修正と断定する

ディストリビューションのバックポートを認識しないスキャナーでは、修正後も 3.3.7 を理由に検出が残ることがあります。

例外登録する場合は、少なくとも次の証跡を残します。

  • rpm -q で確認した完全なパッケージバージョン
  • 3.3.7-4.azl3 以上であること
  • Microsoftのセキュリティ情報
  • 更新後のサービス再起動または再デプロイ記録
  • コンテナイメージのダイジェストやビルド番号

検出を無条件に除外するのではなく、ベンダー修正版が入っていることを確認してから抑制してください。

CVE-2026-42769への対応を完了するためのチェックリスト

対応は、次の順序で進めると漏れを減らせます。

  1. Azure Linux 3.0の対象ホストとコンテナを洗い出す
  2. openssl-3.3.7-3.azl3 と openssl-libs-3.3.7-3.azl3 の有無を確認する
  3. CMPクライアントと rootCaKeyUpdate の利用状況を確認する
  4. OpenSSL関連パッケージを3.3.7-4以上へ更新する
  5. Node.jsやcloud-hypervisorなど、MSRCの確認対象パッケージも最新化する
  6. OpenSSLを利用するサービスを再起動する
  7. コンテナイメージを再ビルドして再デプロイする
  8. 静的リンクや独自同梱のOpenSSLがないか確認する
  9. 現在のルートCA証明書のフィンガープリントを照合する
  10. 脆弱性スキャンを再実行し、RPMリリース番号を含めて結果を確認する

最初に行うべき作業は、rpm -qa で3.3.7-3の有無を確認することです。対象であれば3.3.7-4以上へ更新し、サービス再起動、コンテナ再デプロイ、信頼アンカーの確認まで実施してください。CMPを利用している環境では、パッチ適用と同時にRA資格情報や過去のルートCA更新履歴も点検することが重要です。
[2]: https://openssl-library.org/news/vulnerabilities/ “

    Vulnerabilities | OpenSSL Library

"
Linux
openssl 脆弱性対策 Azure Linux CVE-2026-42769 CMP

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次