CVE-2026-42770の影響と対策｜Azure Linux 3.0はOpenSSL 3.3.7-4へ更新

CVE-2026-42770についてAzure Linux 3.0の影響を確認する場合、最初に見るべきなのはopenssl versionの表示ではなく、RPMパッケージのRelease番号です。

Azure Linux 3.0でopenssl-3.3.7-3.azl3を使用している環境は影響を受けます。公式修正版は3.3.7-4.azl3です。MSRCに個別の回避策は掲載されていないため、opensslだけでなく、実際にアプリケーションが利用するopenssl-libsなどのインストール済みサブパッケージを修正版へ更新してください。更新後は、サービスの再起動またはOS・コンテナイメージの再展開まで行う必要があります。(Microsoft Security Response Center)

CVE-2026-42770の結論：3.3.7-4以上へ更新する

Azure Linux 3.0における判断基準は、次のとおりです。

確認項目	内容
対象OS	Azure Linux 3.0
影響が確認されているビルド	`3.3.7-3.azl3`
公式修正版	`3.3.7-4.azl3`
対象アーキテクチャ	x86_64、aarch64
主に確認するパッケージ	`openssl`、`openssl-libs`
インストール時に併せて確認するパッケージ	`openssl-devel`、`openssl-perl`、`openssl-static`
公式の個別回避策	掲載なし
推奨対応	修正版への更新、サービス再起動、コンテナや静的リンクアプリの再ビルド

Azure Linuxの公式リポジトリでは、OpenSSLパッケージのReleaseが3から4へ引き上げられ、CVE-2026-42770.patchが追加されています。変更履歴にも、3.3.7-4でCVE-2026-42770を修正したことが明記されています。x86_64とaarch64の両方で、主要なOpenSSLサブパッケージが3.3.7-4.azl3へ更新されています。(GitHub)

CVE-2026-42770とは

CVE-2026-42770は、OpenSSLのFFC-DH、つまり有限体暗号を利用したDiffie-Hellman鍵交換におけるピア検証の問題です。

OpenSSLでEVP_PKEY_derive_set_peer()にDHX、すなわちX9.42形式のピア鍵を渡した際、本来はローカル側が信頼しているqを使って部分群への所属を検証する必要があります。しかし、影響を受ける実装では、通信相手が指定したqを使って検証していました。

攻撃者は、被害側と同じpとgを使いつつ、小さな素因数を設定した偽のqと細工した公開値Yを提示できます。検証を通過させたうえで鍵交換を繰り返すことにより、秘密鍵に関する情報を段階的に取得し、最終的に秘密鍵を復元できる可能性があります。これは小部分群閉じ込め攻撃の一種です。(openssl-library.org)

影響を受けやすい利用形態

OpenSSLは、この脆弱性の現実的な攻撃対象は限定的であるとして、深刻度を「Low」と評価しています。

特に確認が必要なのは、次のような環境です。

長期間同じDHX秘密鍵を使用するCMPのRA・CAシステム
X9.42形式の静的DHX鍵を使用する独自アプリケーション
外部または信頼度の低いピアと、同じ秘密鍵で鍵交換を繰り返すシステム
企業・行政向けに独自実装された暗号通信プロトコル
EVP_PKEY_derive_set_peer()を直接使用するアプリケーション

一般的なHTTPSサーバーでOpenSSLを利用しているだけで、直ちに同じ攻撃条件が成立するとは限りません。ただし、サーバー上に対象パッケージが存在する場合は、アプリケーションの内部実装を完全に把握できていなくても、修正版へ更新するのが安全です。

FIPSモードでも影響を受ける

FIPSモードを使用していることは、この脆弱性の回避条件にはなりません。

OpenSSLの公式アドバイザリでは、OpenSSL 4.0、3.6、3.5、3.4、3.1.2、3.0のFIPSモジュールも影響対象とされています。「FIPS対応環境だから安全」と判断して更新を見送らないようにしてください。(openssl-library.org)

Azure Linux 3.0が影響を受けるか確認する方法

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

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

cat /etc/os-release

出力に次のような情報が含まれているか確認してください。

NAME="Azure Linux"
VERSION_ID="3.0"

Azure Linux 2.0や4.0、Ubuntu、RHELなどでは、パッケージ名や修正版の判断基準が異なります。今回の3.3.7-4.azl3という基準は、Azure Linux 3.0向けです。

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

次のコマンドで、主要なOpenSSLパッケージのVersion、Release、アーキテクチャを確認できます。

rpm -q --qf '%{NAME} %{VERSION}-%{RELEASE}.%{ARCH}\n' \
  openssl openssl-libs openssl-devel openssl-perl openssl-static 2>/dev/null

影響を受ける環境では、次のような結果が表示されます。

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

修正済みの環境では、Release番号が4になります。

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

aarch64環境では、末尾が次のようになります。

openssl 3.3.7-4.azl3.aarch64

openssl-libsだけが入っている環境も対象になる

opensslコマンドがインストールされていなくても、openssl-libsが入っていれば確認が必要です。

opensslパッケージは主にコマンドラインツールを提供します。一方、多くのサーバーアプリケーションが実際に読み込む暗号ライブラリはopenssl-libsに含まれます。

そのため、次の結果だけが表示された場合も更新対象です。

openssl-libs 3.3.7-3.azl3.x86_64

「opensslパッケージがないから影響を受けない」と判断してはいけません。

バージョンごとの判定基準

確認結果	判定
`3.3.7-3.azl3`	影響あり。更新が必要
`3.3.7-4.azl3`	CVE-2026-42770の修正を含む
`3.3.7-5.azl3`など後続ビルド	通常は修正を含む。ベンダー情報も併せて確認
`3.3.7-2.azl3`以前	修正前のため、安全とは判断せず更新する
`OpenSSL 3.3.7`とだけ表示	Release番号が不明なため判定不可
RPMパッケージが見つからない	コンテナ内、静的リンク、独自導入版を別途確認

openssl versionだけでは判定できない

次のコマンドは、OpenSSL本体のバージョン確認には役立ちます。

openssl version -a

しかし、CVE-2026-42770の修正確認には不十分です。

Azure Linux 3.0では、脆弱なパッケージと修正済みパッケージのどちらも、上流バージョンは3.3.7です。

脆弱なビルド：OpenSSL 3.3.7 / RPM Release 3
修正済み　　：OpenSSL 3.3.7 / RPM Release 4

Azure Linuxは、OpenSSLのバージョンを別の系列へ変更するのではなく、必要な修正を既存バージョンへバックポートしています。そのため、必ずrpm -qで3.3.7-4.azl3まで確認してください。

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

リポジトリ上のパッケージを確認する

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

tdnf list openssl
tdnf list openssl-libs

修正版がリポジトリへ反映されていれば、3.3.7-4.azl3以降が表示されます。

古い情報しか表示されない場合は、キャッシュを削除してから再確認します。

sudo tdnf clean all
tdnf list openssl
tdnf list openssl-libs

OpenSSL関連パッケージだけを更新する

変更範囲をOpenSSL関連に限定する場合は、次のように更新します。

sudo tdnf update openssl openssl-libs

openssl-devel、openssl-perl、openssl-staticもインストールされている場合は、インストール済みのパッケージ名を追加します。

sudo tdnf update \
  openssl \
  openssl-libs \
  openssl-devel \
  openssl-perl \
  openssl-static

Azure Linuxでは、パッケージ単位の更新にtdnf update <パッケージ名>を使用できます。(Microsoft Learn)

システム全体を更新する

通常のメンテナンスとして他のセキュリティ更新も適用できる場合は、システム全体をアップグレードします。

sudo tdnf upgrade

MicrosoftのAzure Linux向け資料でも、システムのアップグレードにtdnf upgradeが案内されています。(Microsoft Learn)

本番環境では、いきなり全台へ適用せず、検証環境または一部ノードで次の点を確認してから展開します。

アプリケーションが正常に起動すること
TLS通信や証明書処理が正常であること
CMPや独自暗号通信を利用している場合、その通信が成功すること
パッケージの依存関係エラーが発生していないこと
監視エージェントやプロキシが正常に動作すること

更新後のビルドを確認する

更新後、同じRPM確認コマンドを実行します。

rpm -q --qf '%{NAME} %{VERSION}-%{RELEASE}.%{ARCH}\n' \
  openssl openssl-libs openssl-devel openssl-perl openssl-static 2>/dev/null

最低限、実行時ライブラリのopenssl-libsが次の状態になっていることを確認してください。

openssl-libs 3.3.7-4.azl3.x86_64

または、aarch64環境であれば次の状態です。

openssl-libs 3.3.7-4.azl3.aarch64

パッケージの変更履歴から修正を確認する方法もあります。

rpm -q --changelog openssl | grep -A2 -B1 'CVE-2026-42770'

出力にCVE-2026-42770の修正が表示されれば、脆弱性管理ツールで検知が残った場合の確認資料としても利用できます。

パッケージ更新後はサービスを再起動する

openssl-libsを更新しても、すでに起動しているプロセスは、更新前のライブラリをメモリ上で使い続ける場合があります。

そのため、パッケージ更新だけで作業を完了せず、OpenSSLを利用しているサービスを再起動してください。

対象になり得るものには、次のようなサービスがあります。

Webサーバー
リバースプロキシ
APIサーバー
認証・証明書管理サービス
メールサーバー
データベース
独自の常駐アプリケーション
CMPクライアントまたはサーバー

更新前のライブラリを使用中のプロセスが残っていないか、lsofが利用できる環境では次のコマンドで補助的に確認できます。

sudo lsof +L1 | grep -E 'lib(ssl|crypto).*deleted'

対象サービスを特定できない場合や、多数のサービスがOpenSSLを利用している場合は、メンテナンス時間内にOSを再起動する方法が確実です。

コンテナ環境ではホストだけ更新しても不十分

Azure Linux 3.0をコンテナのベースイメージとして使用している場合、ホストOSのOpenSSLを更新しても、コンテナ内のパッケージは更新されません。

コンテナでは次の流れで対応します。

Dockerfileやビルド定義で利用しているベースイメージを更新する
イメージをキャッシュなしで再ビルドする
完成したイメージ内でRPMビルドを確認する
新しいイメージをレジストリへ登録する
ワークロードを再展開する
古いイメージを使用するPodやコンテナが残っていないことを確認する

完成したコンテナイメージは、次のように確認できます。

docker run --rm <image-name> \
  rpm -q --qf '%{NAME} %{VERSION}-%{RELEASE}.%{ARCH}\n' \
  openssl openssl-libs

実行中のコンテナ内で一時的にtdnf updateを行うだけでは、コンテナが再作成された際に元の脆弱な状態へ戻ります。必ずイメージのビルド工程へ修正を反映してください。

静的リンクされたアプリケーションは再ビルドが必要

openssl-staticを利用して作成された実行ファイルには、OpenSSLのコードがアプリケーション本体へ組み込まれています。

そのため、OS上のopenssl-staticパッケージを更新しても、すでにビルド済みの実行ファイルは自動的に修正されません。

静的リンクを使用している場合は、次の対応が必要です。

ビルド環境のopenssl-staticを3.3.7-4.azl3以上へ更新する
アプリケーションを再ビルドする
新しいバイナリを再配布する
古いバイナリが残っていないことを確認する

Go、C、C++などで独自バイナリを作成している環境では、OSのRPM確認だけでなく、ビルドパイプラインと成果物の確認も行ってください。

OpenSSL公式修正版と3.3.7-4が異なる理由

OpenSSLの公式アドバイザリでは、上流の修正版として次のバージョンが案内されています。

OpenSSL系列	上流の修正版
4.0系	4.0.1
3.6系	3.6.3
3.5系	3.5.7
3.4系	3.4.6
3.0系	3.0.21

OpenSSL 1.1.1と1.0.2は、この脆弱性の影響を受けないとされています。(openssl-library.org)

一方、Azure Linux 3.0はOpenSSL 3.3.7をベースにし、修正パッチをバックポートしています。その結果、Azure Linuxで確認すべき修正版はOpenSSL 3.0.21や3.4.6ではなく、RPMパッケージの3.3.7-4.azl3です。

上流のソースコードを手動でビルドして置き換えると、RPMの依存関係、更新管理、Microsoftのサポート範囲に影響する可能性があります。Azure Linuxでは、原則として公式リポジトリが提供する修正版を利用してください。

個別回避策がない場合の暫定的なリスク低減策

MSRCには、CVE-2026-42770専用の回避策は掲載されていません。したがって、次の対策は更新の代わりではなく、修正版を適用するまでの一時的なリスク低減策として扱います。(Microsoft Security Response Center)

CMPや独自DHXサービスへ接続できる通信元を限定する
信頼できないピアからの鍵交換要求を受け付けない
使用していないX9.42 DHX機能を、アプリケーションの仕様を確認したうえで停止する
長期間同じDHX秘密鍵を使用するシステムを優先して更新する
鍵交換を繰り返し実行できる外部公開サービスを優先的に調査する

攻撃を受けた可能性がある場合は、先に修正版を適用してから、秘密鍵の交換、証明書の再発行、関連ログの調査を検討します。秘密鍵のローテーションだけでは、脆弱な検証処理そのものは修正されません。

対応時によくある失敗

失敗例	問題点	正しい対応
`openssl version`だけを確認する	Release 3と4を区別できない	`rpm -q`でRelease番号まで確認する
`openssl`だけを更新する	実行時の`openssl-libs`が古い可能性がある	インストール済みサブパッケージを確認する
深刻度Lowなので放置する	長期DHX鍵を使う環境では秘密鍵回復につながり得る	利用形態を確認し、計画的に更新する
ホストOSだけを更新する	コンテナ内のOpenSSLは変わらない	コンテナイメージを再ビルド・再展開する
`openssl-static`だけを更新する	既存の静的リンクバイナリは修正されない	アプリケーションを再ビルドする
更新後にサービスを再起動しない	メモリ上で旧ライブラリが使われ続ける	サービス再起動またはOS再起動を行う
上流版を手動インストールする	RPM管理やベンダーサポートに影響する	Azure Linux公式パッケージを利用する

よくある質問

OpenSSL 3.3.7と表示されれば修正済みですか

修正済みとは判断できません。

脆弱な3.3.7-3.azl3と修正済みの3.3.7-4.azl3は、どちらもOpenSSL本体の表示上は3.3.7です。RPMのRelease番号まで確認してください。

3.3.7-4より新しいパッケージなら問題ありませんか

Azure Linux公式リポジトリから提供された後続ビルドであれば、通常はCVE-2026-42770の修正を引き継ぎます。

ただし、独自に作成したパッケージや、異なるリポジトリから導入したパッケージでは、単純に番号だけで判断できません。パッケージの配布元と変更履歴も確認してください。

openssl-libsだけが3.3.7-3の場合も更新が必要ですか

必要です。

アプリケーションがOpenSSLの共有ライブラリを利用する場合、重要なのはopenssl-libsです。OpenSSLのコマンドラインツールを使用していなくても、対象ライブラリを読み込むアプリケーションは影響を受ける可能性があります。

FIPS対応システムなら更新不要ですか

更新が必要です。

OpenSSL公式情報では、対象となる複数系列のFIPSモジュールも影響を受けるとされています。FIPSモードは、この問題の回避策ではありません。(openssl-library.org)

脆弱性スキャナーで更新後も検出される場合はどうしますか

まず、次の情報を証跡として取得します。

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

rpm -q --changelog openssl | grep -A2 -B1 'CVE-2026-42770'

スキャナーがOpenSSL 3.3.7という上流バージョンだけで判定している場合、Azure Linuxのバックポート修正を認識できず、検出が残ることがあります。スキャナーの定義を更新し、Azure Linux向けの修正済みReleaseを評価できているか確認してください。

対応を完了するためのチェックポイント

CVE-2026-42770への対応は、次の状態まで確認して完了です。

Azure Linux 3.0の対象ホスト、イメージ、コンテナを洗い出した
opensslだけでなくopenssl-libsも確認した
3.3.7-3.azl3またはそれ以前のビルドを更新した
更新後に3.3.7-4.azl3以上であることをRPMで確認した
OpenSSLを利用するサービスを再起動した
コンテナイメージを再ビルドして再展開した
静的リンクアプリケーションを再ビルドした
更新結果とコマンド出力を脆弱性対応の証跡として保存した

最も重要なのは、OpenSSL 3.3.7という表示だけで判断せず、Azure LinuxのRPM Releaseが3.3.7-4.azl3以上になっていることを確認する点です。MSRCに個別回避策がないため、修正版への更新、プロセスの再起動、コンテナや静的リンク成果物の再作成までを一連の対応として実施してください。

この記事を書いた人

佐藤健司

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

CVE-2026-42770の影響と対策｜Azure Linux 3.0はOpenSSL 3.3.7-4へ更新

CVE-2026-42770の結論：3.3.7-4以上へ更新する

CVE-2026-42770とは

影響を受けやすい利用形態

FIPSモードでも影響を受ける

Azure Linux 3.0が影響を受けるか確認する方法

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

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

openssl-libsだけが入っている環境も対象になる

バージョンごとの判定基準

openssl versionだけでは判定できない

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

リポジトリ上のパッケージを確認する

OpenSSL関連パッケージだけを更新する

システム全体を更新する

更新後のビルドを確認する

パッケージ更新後はサービスを再起動する

コンテナ環境ではホストだけ更新しても不十分

静的リンクされたアプリケーションは再ビルドが必要

OpenSSL公式修正版と3.3.7-4が異なる理由

個別回避策がない場合の暫定的なリスク低減策

対応時によくある失敗

よくある質問

OpenSSL 3.3.7と表示されれば修正済みですか

3.3.7-4より新しいパッケージなら問題ありませんか

openssl-libsだけが3.3.7-3の場合も更新が必要ですか

FIPS対応システムなら更新不要ですか

脆弱性スキャナーで更新後も検出される場合はどうしますか

対応を完了するためのチェックポイント

この記事を書いた人

コメント

コメントするコメントをキャンセル

CVE-2026-42770の影響と対策｜Azure Linux 3.0はOpenSSL 3.3.7-4へ更新

CVE-2026-42770の結論：3.3.7-4以上へ更新する

CVE-2026-42770とは

影響を受けやすい利用形態

FIPSモードでも影響を受ける

Azure Linux 3.0が影響を受けるか確認する方法

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

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

openssl-libsだけが入っている環境も対象になる

バージョンごとの判定基準

openssl versionだけでは判定できない

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

リポジトリ上のパッケージを確認する

OpenSSL関連パッケージだけを更新する

システム全体を更新する

更新後のビルドを確認する

パッケージ更新後はサービスを再起動する

コンテナ環境ではホストだけ更新しても不十分

静的リンクされたアプリケーションは再ビルドが必要

OpenSSL公式修正版と3.3.7-4が異なる理由

個別回避策がない場合の暫定的なリスク低減策

対応時によくある失敗

よくある質問

OpenSSL 3.3.7と表示されれば修正済みですか

3.3.7-4より新しいパッケージなら問題ありませんか

openssl-libsだけが3.3.7-3の場合も更新が必要ですか

FIPS対応システムなら更新不要ですか

脆弱性スキャナーで更新後も検出される場合はどうしますか

対応を完了するためのチェックポイント

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル