CVE-2026-45447対策｜Azure Linux 3.0のOpenSSL・EDK2更新手順

Azure Linux 3.0でCVE-2026-45447に対応するには、OpenSSL系パッケージを3.3.7-4.azl3以上、EDK2系パッケージを20240524git3e722403cd16-18.azl3以上へ更新します。openssl versionで「OpenSSL 3.3.7」と表示されるだけでは修正済みか判断できないため、RPMのRelease番号まで確認しなければなりません。

CVE-2026-45447は、細工されたPKCS#7またはS/MIME署名データを検証した際に、プロセス停止やヒープ破損、条件次第ではリモートコード実行につながる可能性がある脆弱性です。MSRCは個別の回避策を示していないため、パッケージ更新と、更新後のサービス再起動・コンテナ再展開が基本対応になります。([openssl-library.org][1])

CVE-2026-45447対策：Azure LinuxのOpenSSLとEDK2をどのビルドへ更新する？

Azure Linux 3.0で確認すべき代表的な影響ビルドと修正版は、次のとおりです。

対象パッケージ	影響を受ける代表ビルド	修正版	確認時の注意点
`openssl`系	`3.3.7-3.azl3`	`3.3.7-4.azl3`以上	`openssl-libs`や`openssl-static`も確認する
`edk2`系	`20240524git3e722403cd16-17.azl3`	`20240524git3e722403cd16-18.azl3`以上	実際の名前は`edk2-ovmf`や`edk2-tools`などに分かれる

Microsoftの公開パッケージリポジトリでは、x86_64とaarch64の双方について、openssl、openssl-libs、openssl-devel、openssl-staticなどの3.3.7-4.azl3ビルドを確認できます。EDK2についても、複数のedk2-*サブパッケージでRelease番号18のビルドが公開されています。(Microsoft Packages)

重要なのは、OpenSSLの「3.3.7」というVersionだけではなく、その後ろに付くRPMのRelease番号です。

openssl-3.3.7-3.azl3：影響を受けるビルド
openssl-3.3.7-4.azl3：CVE-2026-45447の修正を含むビルド

つまり、次のコマンドだけでは判定できません。

openssl version

修正前も修正後も、出力上は「OpenSSL 3.3.7」と表示される可能性があります。必ずrpmコマンドで3.3.7-4.azl3まで確認してください。

CVE-2026-45447とは

CVE-2026-45447は、OpenSSLのPKCS7_verify()関数に存在するヒープuse-after-free、つまり解放済みメモリを再利用してしまう脆弱性です。OpenSSLは深刻度を「High」と評価しています。([openssl-library.org][1])

脆弱性が発生する流れ

攻撃者が、SignedData内のdigestAlgorithmsフィールドを空のASN.1 SETにしたPKCS#7またはS/MIME署名データを用意します。

このデータをPKCS7_verify()で検証すると、OpenSSLが呼び出し元の所有するBIOオブジェクトを誤って解放することがあります。しかし、呼び出し元のアプリケーションは、そのBIOがまだ使用可能だと認識しています。

その後にBIOを再利用したり、BIO_free()で改めて解放したりすると、すでに解放されたメモリへアクセスするuse-after-freeが発生します。

細工されたPKCS#7・S/MIMEデータ
        ↓
PKCS7_verify()で署名を検証
        ↓
OpenSSLが呼び出し元所有のBIOを誤って解放
        ↓
アプリケーションがBIOを再利用・再解放
        ↓
クラッシュ、ヒープ破損、コード実行の可能性

想定される影響は、アプリケーションの異常終了だけではありません。メモリアロケーターの動作やアプリケーション側のBIOの扱い方によっては、ヒープ破損やリモートコード実行へ発展する可能性があります。([openssl-library.org][1])

HTTPSを使っているだけで直ちに攻撃されるわけではない

CVE-2026-45447はOpenSSLの脆弱性ですが、通常のTLSハンドシェイクそのものが攻撃経路ではありません。主な対象は、OpenSSLのPKCS#7 APIを使ってPKCS#7またはS/MIME署名メッセージを処理するアプリケーションです。

OpenSSLの公式情報では、同じ署名データ処理でもCMS APIを使用するアプリケーションは、この脆弱性の影響を受けないと説明されています。([openssl-library.org][1])

ただし、サーバー管理者がPKCS#7 APIを直接使っている認識がなくても、ミドルウェアや組み込みライブラリが内部で利用している可能性があります。そのため、「自社コードでは使っていない」という理由だけで更新を見送るべきではありません。

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

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

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

cat /etc/os-release

VERSION_ID="3.0"など、Azure Linux 3.0を示す情報が表示されることを確認してください。

コンテナ環境では、ホストOSではなくコンテナ内で実行します。ホストが別のLinuxであっても、コンテナイメージがAzure Linux 3.0なら、そのコンテナ内のパッケージが確認対象です。

OpenSSL系とEDK2系のパッケージを一覧化する

次のコマンドは、インストールされているOpenSSL系とEDK2系パッケージを、Version、Release、アーキテクチャまで含めて表示します。

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

影響を受ける出力例は次のとおりです。

openssl-3.3.7-3.azl3.x86_64
openssl-libs-3.3.7-3.azl3.x86_64
edk2-ovmf-20240524git3e722403cd16-17.azl3.noarch

修正済みの出力例は次のとおりです。

openssl-3.3.7-4.azl3.x86_64
openssl-libs-3.3.7-4.azl3.x86_64
edk2-ovmf-20240524git3e722403cd16-18.azl3.noarch

aarch64環境では、末尾が.aarch64になるパッケージがあります。判定で重視するのは、OpenSSL系の3.3.7-4.azl3と、EDK2系のRelease番号18です。

`openssl`がなくても`openssl-libs`を確認する

最小構成のサーバーやコンテナでは、OpenSSLのコマンド本体であるopensslがインストールされていなくても、共有ライブラリを提供するopenssl-libsだけが入っていることがあります。

この場合、次のコマンドが失敗しても安全とは判断できません。

openssl version

実際にアプリケーションから呼び出される暗号処理はopenssl-libsに含まれるため、RPM一覧から確認する必要があります。

EDK2が表示されない場合

edk2-*パッケージが1つも表示されないホストでは、そのホスト上のEDK2パッケージを新たにインストールする必要はありません。

ただし、次の環境は別途確認してください。

EDK2やOVMFを使って仮想マシン用ファームウェアを生成するビルドサーバー
Azure Linux 3.0ベースのビルドコンテナ
CI/CDパイプライン内でEDK2をインストールしているジョブ
過去に作成したEDK2関連のイメージや成果物
SBOMにEDK2またはOpenSSLの同梱が記録されている製品

ホストにEDK2が入っていなくても、別のビルド環境やコンテナに影響ビルドが残っている可能性があります。

OpenSSLだけ更新してもEDK2の脆弱性は解消しない

今回の対応で特に間違えやすいのが、システムのopensslパッケージだけを更新して作業を終えることです。

Azure LinuxのEDK2パッケージには、OpenSSL 3.0.7のコードがバンドルされています。MicrosoftのAzure Linux向け修正では、この同梱版がCVE-2026-45447の影響範囲に入るとして、EDK2側にも修正が適用されています。(GitHub)

したがって、次の2つは別々に確認する必要があります。

確認対象	更新で修正される範囲
`openssl`、`openssl-libs`など	OSが提供するOpenSSL共有ライブラリやコマンド
`edk2-*`	EDK2にバンドルされたOpenSSLコード

システムのopenssl-libsを3.3.7-4.azl3へ更新しても、古いEDK2パッケージ内に同梱されたOpenSSLコードまでは置き換わりません。EDK2系がインストールされている場合は、Release番号18以上へ更新してください。

Azure Linux 3.0での更新手順

Azure Linux 3.0では、パッケージ管理にtdnfを使用します。Azure Linux 4.0ではdnf5へ変更されていますが、3.0の手順ではtdnfを使用してください。(Microsoft Learn)

更新前の状態を記録する

更新前のパッケージ一覧を保存しておくと、変更管理や障害発生時の調査に利用できます。

rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' \
  | sort \
  > /var/tmp/packages-before-cve-2026-45447.txt

本番環境では、次の準備も行います。

スナップショットや復旧手順を確認する
先に検証環境または1台のノードで適用する
メール署名検証やファームウェア関連処理のテスト項目を用意する
ロードバランサー配下では、1台ずつ切り離して更新する
内部ミラーを利用している場合は同期状況を確認する

システム全体を更新する場合

依存関係を含めてセキュリティ更新を適用する場合は、最初に-yを付けず、更新対象を確認します。

sudo tdnf update

トランザクションの内容を確認し、検証環境で問題がなければ実行します。

sudo tdnf update -y

システム全体の更新では、OpenSSL以外のパッケージも更新される可能性があります。変更範囲を限定する必要がある環境では、次の対象限定手順を使用します。

インストール済みのOpenSSL・EDK2だけを更新する場合

次のBashスクリプトは、インストール済みのopenssl系とedk2系パッケージ名を取得し、そのパッケージだけをtdnf updateへ渡します。

mapfile -t target_pkgs < <(
  rpm -qa --qf '%{NAME}\n' \
    | grep -E '^(openssl|edk2)(-|$)' \
    | sort -u
)

if ((${#target_pkgs[@]} == 0)); then
  echo "OpenSSL系またはEDK2系の対象パッケージは見つかりませんでした"
else
  printf '更新対象: %s\n' "${target_pkgs[@]}"
  sudo tdnf update "${target_pkgs[@]}"
fi

最初は-yを付けず、表示された更新内容を確認します。自動化する場合は、検証後に次のように変更します。

sudo tdnf update -y "${target_pkgs[@]}"

この方法なら、インストールされていないEDK2パッケージを誤って追加することなく、現在導入されているサブパッケージを更新できます。

修正版が取得できない場合

リポジトリに接続できているのに3.3.7-4.azl3またはEDK2のRelease番号18が候補に出ない場合は、次の項目を確認します。

社内ミラーがMicrosoftの公開リポジトリと同期されているか
リポジトリのメタデータが古いまま残っていないか
特定バージョンへの固定や除外設定がないか
x86_64とaarch64のリポジトリを取り違えていないか
コンテナビルドで古いキャッシュを再利用していないか
ベースイメージがダイジェスト固定され、更新前の状態に留まっていないか

異なるリポジトリからopensslとopenssl-libsを個別に取得し、Release番号の異なるパッケージを混在させる方法は避けてください。依存関係と署名を維持したまま、正規のAzure Linuxリポジトリまたは承認済みの内部ミラーから更新します。

更新後に修正版を確認する

更新完了後、もう一度RPMのVersionとReleaseを確認します。

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

確認基準は次のとおりです。

OpenSSL系：3.3.7-4.azl3以上
EDK2系：20240524git3e722403cd16-18.azl3以上
openssl-libsだけ古いReleaseで残っていない
openssl-staticやopenssl-develも必要に応じて同じ修正ビルドになっている
複数のEDK2サブパッケージでRelease番号が混在していない

MicrosoftのAzure Linuxリポジトリでは、OpenSSL関連の3.3.7-4.azl3とEDK2関連のRelease番号18が公開されています。(Microsoft Packages)

パッケージ更新だけで作業を終えない

共有ライブラリを更新しても、すでに起動しているプロセスは、更新前のライブラリをメモリ上に読み込んだまま動作していることがあります。

更新後は、次の対応を行います。

OpenSSLを利用するWebサーバーやアプリケーションを再起動する
メールゲートウェイやS/MIME処理サービスを再起動する
対象プロセスを特定できない場合は、計画停止のうえでOSを再起動する
コンテナイメージを再ビルドし、新しいコンテナへ置き換える
Kubernetesでは更新済みイメージでPodを再作成する
openssl-staticで静的リンクしたプログラムを再ビルドする
EDK2を使って生成したファームウェアやイメージを必要に応じて再生成する

特にコンテナ環境では、ホスト側のOpenSSL更新だけではコンテナ内のファイルは変わりません。ベースイメージの再取得、イメージの再ビルド、ワークロードの再展開までを一連の対応として扱います。

どの環境を優先して更新すべきか

CVE-2026-45447はHighに分類されていますが、実際の攻撃可能性は、信頼できないPKCS#7やS/MIME署名データがPKCS7_verify()へ到達するかで変わります。([openssl-library.org][1])

優先度	環境の例	判断理由
最優先	インターネットからS/MIMEメールを受信・検証するシステム	攻撃者が署名データを送信できる
最優先	外部からPKCS#7署名ファイルをアップロードできるサービス	細工されたデータが検証処理へ到達しやすい
最優先	EDK2・OVMFを扱うビルド基盤	システムOpenSSLとは別に同梱版の確認が必要
高	OpenSSLを含む公開APIやネットワークサービス	内部依存関係が把握できていない可能性がある
高	Azure Linux 3.0ベースのコンテナ群	古いイメージが複数環境に残りやすい
通常の緊急更新	PKCS#7利用が確認できない内部サーバー	直接の攻撃経路が不明でも共有ライブラリとして利用され得る

アプリケーションのソースコードを管理している場合は、次のようにPKCS7_verifyの直接利用を検索できます。

grep -R --line-number \
  --include='*.c' \
  --include='*.cc' \
  --include='*.cpp' \
  'PKCS7_verify' \
  /path/to/source

ただし、検索結果が0件でも、リンクしている外部ライブラリやミドルウェアが内部で呼び出している可能性があります。コード調査は更新優先度の判断材料にはなりますが、修正版への更新を不要とする根拠にはしないでください。

MSRCに回避策がない場合の考え方

MSRCでは、CVE-2026-45447に対する個別の回避策は掲載されていません。そのため、正式な対処は修正版パッケージへの更新です。(Microsoft Security Response Center)

更新を直ちに実施できない場合は、組織側で次のような一時的な露出低減策を検討できます。

信頼できないPKCS#7ファイルの受け付けを一時停止する
S/MIME署名検証機能を業務上許容できる範囲で停止する
対象サービスへのアクセス元を制限する
ファイルアップロード経路を認証済みユーザーに限定する
該当処理をネットワーク分離された環境へ移す
プロセスの異常終了やメモリ破損の兆候を監視する

これらはMicrosoftやOpenSSLが示した正式な回避策ではなく、パッチ適用までの暫定対応です。実施しても脆弱性そのものは残るため、「対応完了」とは扱えません。

また、この脆弱性はPKCS7_verify()のメモリ管理に関する問題です。TLSの暗号スイート変更、TLS 1.2やTLS 1.3の無効化、サーバー証明書の交換だけでは修正になりません。

対応時に起こりやすい失敗

失敗例	問題点	正しい対応
`openssl version`だけ確認する	RPMのRelease番号が分からない	`rpm -qa`で`3.3.7-4.azl3`まで確認する
`openssl`だけ更新する	`openssl-libs`や静的ライブラリが残る可能性がある	OpenSSL関連パッケージ全体を確認する
EDK2を確認しない	EDK2には別のOpenSSLコードが同梱されている	インストール済みの`edk2-*`をRelease番号`18`以上にする
パッケージ更新後に再起動しない	プロセスが旧ライブラリを保持し続ける	対象サービスまたはOSを再起動する
ホストだけ更新する	コンテナ内のOpenSSLは更新されない	イメージを再ビルドして再展開する
`openssl-static`だけ更新する	既存の静的リンク済みバイナリは変わらない	アプリケーションを再ビルドする
upstreamの`3.0.21`だけを見る	Azure Linuxは`3.3.7`へ修正をバックポートしている	ディストリビューションの修正ビルドで判断する
PKCS#7を使っていないとして先送りする	間接依存や別プロセスの利用を見落とす	調査と並行して修正版を展開する

OpenSSLのupstream情報では、3.0系列の修正版として3.0.21などが示されています。一方、Azure Linux 3.0では修正を3.3.7へバックポートし、RPMのRelease番号を4へ更新しています。upstreamのバージョン番号だけではなく、Azure Linuxが公開するパッケージビルドを基準にしてください。([openssl-library.org][1])

更新対応の最終チェック

CVE-2026-45447への対応では、次の順番で作業すると確認漏れを防げます。

Azure Linux 3.0のホスト、コンテナ、ビルド環境を洗い出す
rpm -qaでOpenSSL系とEDK2系のVersion-Releaseを確認する
OpenSSL系を3.3.7-4.azl3以上へ更新する
インストール済みのEDK2系をRelease番号18以上へ更新する
OpenSSLを読み込むサービスを再起動する
コンテナと静的リンク済みアプリケーションを再ビルドする
更新後のRPM一覧を保存し、修正版であることを記録する
PKCS#7、S/MIME、EDK2関連の業務テストを実施する

最初に実行すべきコマンドは、次のパッケージ確認です。

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

ここでOpenSSLのRelease番号3や、EDK2のRelease番号17が見つかった場合は、修正版へ更新してください。MSRCに個別の回避策がない以上、入力制限や監視だけで終わらせず、パッケージ更新、再起動、コンテナ再展開まで完了させることが重要です。
[1]: https://openssl-library.org/news/vulnerabilities/ “

    Vulnerabilities | OpenSSL Library

"

この記事を書いた人

佐藤健司

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

CVE-2026-45447対策｜Azure Linux 3.0のOpenSSL・EDK2更新手順

CVE-2026-45447対策：Azure LinuxのOpenSSLとEDK2をどのビルドへ更新する？

CVE-2026-45447とは

脆弱性が発生する流れ

HTTPSを使っているだけで直ちに攻撃されるわけではない

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

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

OpenSSL系とEDK2系のパッケージを一覧化する

`openssl`がなくても`openssl-libs`を確認する

EDK2が表示されない場合

OpenSSLだけ更新してもEDK2の脆弱性は解消しない

Azure Linux 3.0での更新手順

更新前の状態を記録する

システム全体を更新する場合

インストール済みのOpenSSL・EDK2だけを更新する場合

修正版が取得できない場合

更新後に修正版を確認する

パッケージ更新だけで作業を終えない

どの環境を優先して更新すべきか

MSRCに回避策がない場合の考え方

対応時に起こりやすい失敗

更新対応の最終チェック

この記事を書いた人

コメント

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

CVE-2026-45447対策｜Azure Linux 3.0のOpenSSL・EDK2更新手順

CVE-2026-45447対策：Azure LinuxのOpenSSLとEDK2をどのビルドへ更新する？

CVE-2026-45447とは

脆弱性が発生する流れ

HTTPSを使っているだけで直ちに攻撃されるわけではない

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

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

OpenSSL系とEDK2系のパッケージを一覧化する

opensslがなくてもopenssl-libsを確認する

EDK2が表示されない場合

OpenSSLだけ更新してもEDK2の脆弱性は解消しない

Azure Linux 3.0での更新手順

更新前の状態を記録する

システム全体を更新する場合

インストール済みのOpenSSL・EDK2だけを更新する場合

修正版が取得できない場合

更新後に修正版を確認する

パッケージ更新だけで作業を終えない

どの環境を優先して更新すべきか

MSRCに回避策がない場合の考え方

対応時に起こりやすい失敗

更新対応の最終チェック

この記事を書いた人

関連記事

コメント

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

`openssl`がなくても`openssl-libs`を確認する

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