Azure Linux 3.0で libsolv-0.7.28-4.azl3 を使用している場合は、CVE-2026-48863の影響を受けます。対応は、修正済みの libsolv-0.7.28-5.azl3 へ更新することです。EdDSA形式のPGP署名を検証する処理に長さ変数の取り違えがあり、細工された署名によってスタックバッファオーバーフローが発生し、処理停止やサービス拒否（DoS）につながる可能性があります。MSRCでは個別の回避策が示されていないため、リポジトリへのアクセス制限だけで済ませず、修正版への更新まで完了させる必要があります。(Microsoft Security Response Center)
この記事では、CVE-2026-48863の仕組み、影響を受ける条件、Azure Linux 3.0での確認コマンド、更新手順、コンテナイメージでの注意点まで具体的に解説します。
CVE-2026-48863とは？Azure Linux 3.0の影響と修正版
CVE-2026-48863は、パッケージの依存関係を解決するライブラリ「libsolv」に存在する脆弱性です。Azure Linuxの修正プルリクエストでは重要度が「HIGH」とされ、Azure Linux 3.0向けに修正パッチが取り込まれています。(GitHub)
| 項目 | 内容 |
|---|---|
| 対象 | Azure Linux 3.0のlibsolv |
| 影響を受けるパッケージ | libsolv-0.7.28-4.azl3 |
| 修正済みパッケージ | libsolv-0.7.28-5.azl3 |
| 脆弱性の種類 | EdDSA PGP署名検証時のスタックバッファオーバーフロー |
| 主な影響 | プロセスの異常終了、パッケージ処理や自動処理の停止、DoS |
| Microsoft側の重要度 | HIGH |
| 個別の回避策 | MSRCには掲載なし |
| 基本対応 | 修正版への更新 |
MicrosoftのAzure Linuxリポジトリでは、x86_64とaarch64の両方について、0.7.28-4.azl3 から 0.7.28-5.azl3 への更新が行われています。そのため、CPUアーキテクチャにかかわらずパッケージバージョンの確認が必要です。(GitHub)
バッファオーバーフローが起きる仕組み
問題は、libsolvの solv_pgpvrfy 関数がEdDSA署名を処理する際に、署名要素の長さを誤って使用していたことです。
EdDSA署名には、概念的に r と s という2つの署名要素があります。脆弱なコードでは、s のデータをコピーするとき、本来使うべき slen ではなく、別の要素である r の長さを示す rlen が使用されていました。
修正内容は次の1行です。
- memcpy(sigdata + 64 - slen, s, rlen);
+ memcpy(sigdata + 64 - slen, s, slen);細工された署名によって rlen と slen に不整合が生じると、s の実際の長さとは異なるサイズで固定長の署名バッファへコピーされます。その結果、スタック上のバッファ境界を越えて書き込む可能性があります。修正版では、コピー元である s 自身の長さ slen を使うように変更されています。(GitHub)
これはEdDSA暗号方式そのものの欠陥ではありません。libsolvの署名検証実装における、コピーサイズの指定ミスです。
また、公開情報で明示されている主な影響はDoSです。「スタックバッファオーバーフロー」という言葉だけを根拠に、任意コード実行が確認済みであると断定するべきではありません。一方で、メモリ破壊を伴う脆弱性である以上、単なる署名検証エラーとして放置するのも適切ではありません。
影響を受ける条件
Azure Linux 3.0上に対象パッケージが存在するだけで、直ちに攻撃が成立するわけではありません。脆弱な処理へ細工されたEdDSA PGP署名が渡され、実際に署名検証が行われる必要があります。
実務上は、次のような環境で優先度が高くなります。
| 利用環境 | 対応優先度 | 理由 |
|---|---|---|
| 外部や第三者のリポジトリを利用するサーバー | 最優先 | 信頼境界外から署名やメタデータを取得する可能性がある |
| パッケージミラーやリポジトリ同期サーバー | 最優先 | 外部データを自動的かつ継続的に処理する |
| CI/CDやコンテナイメージの自動ビルド基盤 | 高い | 異常終了によりビルドやデプロイが停止する |
| Azure Linuxをベースにした多数のコンテナ | 高い | 同じ脆弱なレイヤーが複数環境へ展開される可能性がある |
| Microsoft公式リポジトリのみを手動利用する端末 | 更新が必要 | 攻撃経路は限定されても、脆弱なコード自体は残る |
| libsolvがインストールされていない環境 | 直接の影響なし | ただし別コンテナや別ノードも確認が必要 |
公式リポジトリだけを使用していることは、攻撃経路を減らす材料にはなります。しかし、修正版を適用しなくてよい理由にはなりません。将来の設定変更や一時的なリポジトリ追加、ビルド処理などによって、対象コードが使われる可能性があるためです。
Azure Linux 3.0で影響を確認する方法
OSのバージョンを確認する
最初に、対象環境がAzure Linux 3.0であることを確認します。
cat /etc/os-releaseVERSION_ID などに 3.0 が表示されるか確認してください。複数のLinuxディストリビューションを運用している場合、ホスト名やクラウド上のイメージ名だけで判断せず、実際のOS内で確認することが重要です。
libsolvのインストール状況とバージョンを確認する
次のコマンドで、インストール済みパッケージの名前、バージョン、リリース、アーキテクチャを表示します。
rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' libsolv出力例と判断は次のとおりです。
| 出力例 | 判断 |
|---|---|
libsolv-0.7.28-4.azl3.x86_64 | 影響対象。更新が必要 |
libsolv-0.7.28-4.azl3.aarch64 | 影響対象。更新が必要 |
libsolv-0.7.28-5.azl3.x86_64 | CVE-2026-48863の修正済み |
libsolv-0.7.28-5.azl3.aarch64 | CVE-2026-48863の修正済み |
package libsolv is not installed | そのOSには対象パッケージが存在しない |
| 上記以外のバージョン | MSRCまたはAzure Linuxのパッケージ情報と照合する |
関連するサブパッケージも含めて確認する場合は、次のコマンドを使用します。
rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' | grep '^libsolv'バージョン番号だけで判断しない
上流のlibsolvでは、CVE-2026-48863への修正がバージョン0.7.38の変更履歴に含まれています。一方、Azure Linux 3.0では同じ修正が0.7.28へバックポートされ、RPMのリリース番号を 4 から 5 へ上げる形で提供されています。(GitHub)
したがって、「0.7.28は0.7.38より古いから、0.7.28はすべて脆弱」と判断するのは誤りです。Azure Linuxでは、次の全体を確認してください。
0.7.28-5.azl3重要なのは上流バージョンの 0.7.28 だけではなく、修正パッチの適用状況を示すリリース番号 5 と、Azure Linux 3.0向けであることを示す .azl3 です。
libsolvを0.7.28-5へ更新する手順
Azure Linuxでは、パッケージ管理にTiny DNFの tdnf を使用します。Microsoftのドキュメントでも、パッケージ一覧の確認に tdnf list、更新に tdnf update、キャッシュ削除に tdnf clean all を使用する方法が示されています。(Microsoft Learn)
更新前のバージョンを記録する
変更管理や監査のため、更新前の状態を保存しておきます。
rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' libsolv複数台を管理している場合は、実行日時、ホスト名、出力結果を構成管理システムや作業記録へ残してください。
リポジトリで提供されるバージョンを確認する
tdnf list libsolv修正版が表示されない場合は、次の可能性を確認します。
- リポジトリメタデータが古い
- セキュリティ更新用リポジトリが無効になっている
- 社内ミラーへの同期が完了していない
- パッケージがバージョン固定されている
- プロキシやネットワーク制御でリポジトリへ接続できない
修正版が表示されない状態で、出所不明のRPMをインターネットから直接取得して導入するのは避けてください。正規のAzure Linuxリポジトリまたは組織で承認されたミラーから更新します。
パッケージを更新する
リポジトリ情報を整理したうえで、libsolvを更新します。
sudo tdnf clean all
sudo tdnf update -y libsolv組織のパッチ方針でOS全体を同時に更新する場合は、次のように実行します。
sudo tdnf update -y全体更新では、libsolv以外のパッケージも変更されます。本番環境では、検証環境での動作確認、変更対象一覧の確認、ロールバック方法の準備を行ってください。
更新後のバージョンを必ず確認する
コマンドが正常終了しただけでは、修正版へ更新された証明にはなりません。更新後にもう一度RPMのバージョンを確認します。
rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' libsolv次のように表示されることを確認します。
libsolv-0.7.28-5.azl3.x86_64または、ARM64環境では次のように表示されます。
libsolv-0.7.28-5.azl3.aarch640.7.28-4.azl3 のままであれば、更新は完了していません。リポジトリ設定、社内ミラー、バージョン固定、更新除外設定を調査してください。
プロセスの再起動を判断する
libsolvは、パッケージ管理ツールなどから読み込まれる共有ライブラリです。tdnf のように実行のたびに起動する処理であれば、次回実行時に更新済みライブラリが読み込まれます。
ただし、独自の常駐サービスや長時間稼働するパッケージ管理関連プロセスがlibsolvを読み込んでいる場合は、そのプロセスを再起動してください。OS再起動が常に必須とは限りませんが、影響範囲を特定できない場合や組織のセキュリティ更新基準で定められている場合は、計画的な再起動を行います。
コンテナイメージではホストと別に確認する
Azure Linuxホストを更新しても、その上で動いているコンテナイメージ内のlibsolvは更新されません。反対に、コンテナイメージを更新してもホストOS側のパッケージは修正されません。
次の4つを別々の対象として管理する必要があります。
- 仮想マシンや物理ホストのAzure Linux
- Kubernetesなどのワーカーノード
- コンテナイメージ
- CI/CDで使用するビルド用イメージ
Azure Linux 3.0のベースイメージを利用している場合は、Dockerfileなどで修正版を取り込み、イメージを再ビルドします。Microsoft Artifact Registryでは、Azure Linux 3.0のコアイメージが提供されています。(Microsoft Artifact Registry)
FROM mcr.microsoft.com/azurelinux/base/core:3.0
RUN tdnf update -y libsolv \
&& rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' libsolv \
&& tdnf clean allビルド後も、完成したイメージ内のバージョンを確認します。
docker run --rm your-image:patched \
rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' libsolv確認すべき出力は 0.7.28-5.azl3 です。
実行中のコンテナへ直接ログインしてパッケージを更新する方法は、恒久対策になりません。コンテナが再作成されると変更が失われるためです。Dockerfileやイメージ作成パイプラインを修正し、新しいイメージをレジストリへ登録してから、ワークロードを再デプロイしてください。
また、3.0 のようなタグ名だけで修正済みと判断しないことも重要です。ビルド後のRPM情報または脆弱性スキャン結果を、修正確認の証跡として残します。
回避策がない場合に行う暫定的なリスク低減策
MSRCには、CVE-2026-48863に対する個別の回避策が掲載されていません。そのため、正式な対応は修正版への更新です。(Microsoft Security Response Center)
すぐに更新できない場合は、更新までの暫定措置として次の対策を検討します。
- 不要な第三者リポジトリを無効化する
- 外部から提供されたリポジトリ情報やPGP署名の自動処理を停止する
- パッケージミラーが接続できる送信先を許可リストで制限する
- ビルドサーバーやリポジトリ同期サーバーを他の業務環境から分離する
tdnfやlibsolvを使用する処理の異常終了を監視する- 修正版が社内ミラーへ同期されるまで、新規イメージの公開を保留する
これらは攻撃経路や業務影響を小さくするための補完策であり、脆弱性そのものを修正するものではありません。「第三者リポジトリを無効化したため対応完了」とせず、必ず更新作業の期限と担当者を決めてください。
異常終了や攻撃の兆候を確認する
過去にlibsolvやパッケージ管理処理が異常終了していないか、システムログを確認します。
sudo journalctl --since "7 days ago" \
| grep -Ei 'libsolv|tdnf|segfault|core dumped'次のような記録が見つかった場合は、単なる更新失敗として処理せず、発生時刻と直前に使用したリポジトリを確認してください。
tdnfのセグメンテーションフォルト- libsolvを読み込む独自ツールの異常終了
- パッケージメタデータ更新直後のコアダンプ
- 特定の第三者リポジトリを追加した直後から繰り返すクラッシュ
- CI/CDの同一工程で再現する突然のビルド停止
疑わしい事象がある場合は、関連するリポジトリメタデータ、ログ、コアダンプ、実行コマンド、ネットワーク接続先を保全します。問題のリポジトリ処理を停止し、修正版へ更新したうえで影響範囲を調査してください。
なお、ログに異常が見つからないことは、脆弱性の影響を受けないことの証明にはなりません。パッケージバージョンによる判定を優先します。
対応時に起きやすい失敗
上流バージョンだけを見て誤判定する
Azure Linux 3.0では、上流の新しいバージョンへ単純に置き換えるのではなく、0.7.28へ修正パッチをバックポートしています。0.7.28 だけを見ず、0.7.28-5.azl3 まで確認してください。
ホストだけ更新してコンテナを残す
ホストOSの更新とコンテナイメージの更新は別作業です。SBOMやコンテナスキャンを使い、レジストリ内に 0.7.28-4.azl3 を含む古いイメージが残っていないか確認します。
tdnfの終了コードだけで更新済みと判断する
更新対象がリポジトリに存在しない場合や、バージョン固定が設定されている場合、期待した版へ上がらないことがあります。作業後は必ず rpm -q で実パッケージを確認してください。
非公式RPMを直接導入する
修正版の配信が見えないからといって、非公式サイトから取得したRPMを導入すると、依存関係の破損やサプライチェーンリスクにつながります。承認されたAzure Linuxリポジトリまたは社内ミラーを利用します。
クラッシュが発生していないため対応不要と判断する
CVE-2026-48863は、特定形式の署名を検証したときに発現する脆弱性です。これまでクラッシュしていなくても、脆弱なパッケージが安全であるとは限りません。
まとめ：0.7.28-4なら更新まで完了させる
CVE-2026-48863への対応では、次の順序で作業を進めます。
- Azure Linux 3.0のホスト、ノード、コンテナイメージを洗い出す
rpm -qでlibsolvの完全なバージョンとリリース番号を確認するlibsolv-0.7.28-4.azl3があれば、0.7.28-5.azl3へ更新する- コンテナはDockerfileを修正して再ビルドし、再デプロイする
- 更新後のRPM出力を証跡として保存する
- 暫定的に無効化したリポジトリや処理は、安全確認後に再開する
特に重要なのは、0.7.28 という上流バージョンだけで判断しないことです。Azure Linux 3.0では、CVE修正済みであることを示す 0.7.28-5.azl3 まで確認してください。MSRCに個別の回避策がない以上、アクセス制限や監視は暫定措置にとどめ、修正版の適用を最終的な完了条件とする必要があります。
コメント