InfraAcademy Blog

1回の更新で470件を超えるCVEに対応したAzure Linux 3.0。バージョン番号が変わらない「バックポート」と、修正が入ったかの確かめ方

公開日: 2026-11-11 更新日: 2026-11-11 著者: ryu | #Linux #LPIC #セキュリティ

Linux・ネットワーク・AWSなど、学びたい分野の講座を探せます

こんにちは、インフラエンジニアのryuです。

2026年11月上旬に、Microsoftが開発しているLinuxディストリビューションのAzure Linux 3.0に、大きなセキュリティ更新が公開されました。

報道によると、1回の更新に470件を超えるCVEの参照が含まれていて、カーネルからOpenSSL、curl、コンテナ関連のソフトウェアまで幅広く修正されています。

数字の大きさに目が行きがちなニュースですが、Linuxを勉強している人にとっては、セキュリティ更新がどう配られ、どう確かめるのかを知るよい題材です。この記事では、ニュースの中身を整理したあと、修正が入ってもバージョン番号が変わらない仕組みと、自分のLinuxで修正が入ったかを確かめるコマンドを紹介します。

Azure Linux 3.0の更新で何が直った？¶

まずはニュースの中身を確認しておきましょう。

Azure Linuxは、Microsoftが自社のクラウドで使うために開発しているLinuxディストリビューションです。以前はCBL-Marinerという名前で、パッケージはRHEL系と同じRPM形式で配られています。

今回の更新について、報道で伝えられている主な内容は次のとおりです。

項目	報道されている内容
公開時期	2026年11月上旬（報道は11月9日前後）
CVEの件数	470件を超えるCVEの参照を含む
主な対象	Linuxカーネル、OpenSSL、curl、Kubernetes、Docker、QEMU、containerd など
カーネル	`6.6.161.1` に更新（Azure Linux 3.0は6.6系のLTSカーネルを使い続けている）
そのほか	eMudhraの証明書の問題を受けて、一部のルート証明書を削除・失効扱いにする変更

前回の大きな更新である8月の版でも、233件を超えるCVEの修正が含まれていたと報じられています。Azure Linux 3.0は、このように一定の間隔でまとめて更新を出す運用をしています。

なお、今回の版の名前（バージョン文字列）は記事によって書き方が違っています。この記事では版の名前を断定せず、11月上旬の更新として扱います。

「470件の脆弱性」ではない点に注意¶

ここで1つ注意したいのが、件数の読み方です。

報道でも触れられているとおり、470件を超える「CVEの参照」は、470個の別々の脆弱性があったという意味とは限りません。

CVE（Common Vulnerabilities and Exposures）は、公開された脆弱性に付けられる識別番号です。CVE-年-番号 の形で書かれ、同じ脆弱性はどのディストリビューションでも同じ番号で呼ばれます。

たとえば、OpenSSLとそれを組み込んだ別のパッケージの両方で同じCVEを直すと、更新の一覧には同じ番号が2回出てきます。カーネルのように修正の数がもともと多いパッケージもあるので、件数は「どれだけ広い範囲を更新したか」の目安として見るのがよいと思います。

版を上げずに直していることもある¶

もう1つ、報道で指摘されていたのが、Azure LinuxはOpenSSLの修正を取り込んでも、OpenSSL本体のバージョン番号を変えない場合があるという点です。

つまり、openssl version の表示だけを見て「古いから危ない」「新しいから安全」と判断すると、間違えることがあります。この考え方は、Azure Linuxだけでなく、RHEL系やUbuntuなど多くのディストリビューションに共通しています。次の章で詳しく見ていきましょう。

バージョン番号が変わらない「バックポート」とは？¶

ディストリビューションが、新しい版で入った修正だけを取り出して、今配っている古い版に当てることをバックポートと呼びます。

Red Hatは、自社の解説ページでこの考え方を説明しています。ソフトウェアの開発元（アップストリーム）が新しい版で脆弱性を直しても、その新しい版には機能の変更や設定の互換性が崩れる変更が一緒に入っていることがあります。そのまま版を上げると、利用者の環境が動かなくなるおそれがあるわけです。

そこで、版はそのままにして、脆弱性の修正だけを取り込みます。こうすると、安定して動いている環境を壊さずに、安全性だけを上げられます。

Red Hatが挙げている例¶

Red Hatの解説では、Apache HTTP Serverを例に説明されています。

Red Hatが 2.0.40 を配っていたとき、あとから見つかった脆弱性は、開発元の 2.0.43 で修正されました。ところが 2.0.43 には、モジュールとのつなぎ方が変わる変更も一緒に入っていて、そのまま版を上げると、使っているモジュールを作り直す必要がありました。

これでは、自動で更新を当てるような運用ができません。そのためRed Hatは、版は 2.0.40 のまま、脆弱性の修正だけを取り込んだパッケージを配りました。

利用者は、アプリケーションが特定の版で動くことを確認したうえで使っています。サポート期間の途中で版が変わると、その確認をやり直す必要が出てしまう、という点も理由として挙げられています。

パッケージのバージョンとリリース番号の違い¶

バックポートされたかどうかは、パッケージの名前に付いている番号を見ると分かります。

RPMのパッケージ名は、次のような形になっています。

部分	意味	バックポートのときの動き
名前	`openssl` などのパッケージ名	変わらない
バージョン	開発元（アップストリーム）の版	変わらないことが多い
リリース	ディストリビューションが独自に付ける番号	修正を入れるたびに上がる
アーキテクチャ	`x86_64` `aarch64` など	変わらない

Red Hatも、パッケージのバージョン番号だけを見ても脆弱性があるかどうかは分からない、と説明しています。版の番号だけで判断する脆弱性スキャナーが、すでに直っているのに「危険」と誤って出す（誤検知する）ことがあるのも、このためです。

初めて知ると少し分かりにくいですが、見るべきなのはバージョンではなく、リリース番号と更新履歴だと覚えておけば大丈夫です。

自分のLinuxに修正が入ったか確かめる方法¶

ここからは、実際のコマンドで確認していきます。

手元に練習用のLinuxがある人は、ぜひ一緒に打ってみてください。RHEL系（AlmaLinux、Rocky Linux、Fedoraなど）とUbuntuに分けて紹介します。Azure LinuxもRPM形式なので、rpm コマンドの考え方は同じです。

RHEL系で確認する（rpm・dnf）¶

まずは、入っているパッケージの版を確認します。

# 入っているパッケージの「名前-バージョン-リリース.アーキテクチャ」を表示する
rpm -q openssl

# パッケージの更新履歴から、CVE番号が書かれた行だけを取り出す
rpm -q --changelog openssl | grep -i cve | head

# 特定のCVEが直っているかを調べる（番号は確かめたいものに置き換える）
rpm -q --changelog openssl | grep CVE-2026-

rpm -q --changelog は、ディストリビューションがパッケージに残した更新履歴を表示するオプションです。バックポートで修正を入れたときは、ここにCVE番号が書かれていることが多いので、版の番号が古くても修正済みかどうかを確かめられます。

次に、まだ当てていないセキュリティ更新があるかを確認します。

# まだ適用していないセキュリティ更新の一覧
dnf updateinfo list --security

# セキュリティ更新だけを適用する
sudo dnf upgrade --security

# 更新後に再起動が必要かを確認する（dnf-utils / dnf-plugins-core が必要）
sudo dnf needs-restarting -r

dnf updateinfo は、ディストリビューションが出した更新情報（アドバイザリ）を表示するコマンドです。どのパッケージにどんな重要度の修正が来ているかが分かります。

Ubuntuで確認する（apt）¶

Ubuntuでも考え方は同じです。

# 更新できるパッケージの一覧
sudo apt update
apt list --upgradable

# パッケージの更新履歴を見る（CVE番号で絞り込む）
apt changelog openssl | grep -i cve | head

# 更新後に再起動が必要かを確認する（ファイルがあれば再起動が必要）
cat /var/run/reboot-required

Ubuntuのパッケージも、版の後ろに ubuntu を含む独自の番号が付いていて、修正を入れるとそこが上がります。apt の基本的な使い方は、apt-getコマンドの使い方で解説しています。

カーネルは再起動するまで切り替わらない¶

カーネルの更新だけは、少し注意が必要です。

今回のAzure Linuxの更新のように、カーネルの新しいパッケージを入れても、動いているカーネルは再起動するまで古いままです。いま動いているカーネルの版は、次のコマンドで確認できます。

# いま動いているカーネルの版
uname -r

# インストールされているカーネルのパッケージ（RHEL系）
rpm -q kernel

uname -r の結果と、rpm -q kernel で出てくる一番新しい版がずれていたら、再起動がまだという意味です。uname コマンドの使い方は、unameコマンドの解説やカーネルのバージョンを確認する方法を読んでみてください。

カーネルの版の付け方（mainline・stable・longtermの違い）は、以前書いたLinux 7.3の公開とカーネルの種類の記事で整理しています。Azure Linux 3.0が6.6系を使い続けているのも、この longterm（LTS）の考え方によるものです。

確認するときに間違えやすいポイント¶

ここまでのコマンドを使うときに、つまずきやすいところを表にまとめておきます。

よくある間違い	正しい考え方
`openssl version` の版だけで安全かどうかを判断する	リリース番号と `--changelog` のCVE番号を確認する
更新を入れたので、カーネルも新しくなったと思う	`uname -r` で、動いているカーネルを確認する
更新したのに、サービスの動きが変わらない	ライブラリを読み込み直すため、サービスの再起動が必要なことがある
CVEの件数が多いほど危険な更新だと考える	件数は範囲の目安。重要度はアドバイザリで確認する
スキャナーの「危険」をそのまま信じる	バックポートで直っていないか、ディストリビューションの情報と照らし合わせる

特に3つめのサービスの再起動は見落としがちです。OpenSSLのようなライブラリを更新しても、すでに動いているプロセスは古いライブラリを使い続けることがあります。dnf needs-restarting は、再起動が必要なプロセスを調べるときにも使えます。

Linuxを学習中の人・LPIC受験者に関係はある？¶

Azure Linuxを直接触る機会は、学習中の人にはあまりないと思います。主にAzureのサービスの中で使われているディストリビューションだからです。

ただ、今回のニュースで出てきた考え方は、どのLinuxを使うときにも必要になります。

ニュースで出てきた話題	学習とのつながり
RPMパッケージの版とリリース番号	LPIC-1の101試験で出題されるRPMとYUM（dnf）のパッケージ管理
`apt` での更新	同じく101試験のDebianパッケージ管理
カーネルの版と再起動	`uname` などの基本コマンド。カーネルの種類の理解
CVEとアドバイザリ	実務で、脆弱性のニュースを読んで自分の環境に当てはまるかを判断する力