Azure Linux 3.0でbusybox 1.36.1-24を使用している場合、CVE-2026-38754への基本対策は修正版の1.36.1-25以降へ更新することです。MSRCでは個別の回避策が示されていないため、設定変更だけで対応済みと判断せず、パッケージ更新を優先してください。更新後は、BusyBoxのashを使用するサービスの再起動や、コンテナイメージの再ビルド・再デプロイまで行う必要があります。(Microsoft Security Response Center)
特に注意したいのは、busybox --helpなどで表示される「1.36.1」だけでは、脆弱な1.36.1-24と修正版の1.36.1-25を区別できない点です。Azure Linuxでは、RPMのリリース番号を含む完全なパッケージバージョンを確認してください。
CVE-2026-38754の概要と対応方針
CVE-2026-38754は、BusyBoxに含まれるシェルashのifsbreakup()におけるメモリ境界処理の不備です。細工された入力を処理すると、メモリ領域外へのアクセスが発生し、ashプロセスが異常終了する可能性があります。結果として、シェルを利用するジョブやサービスの停止、コンテナの再起動ループなど、可用性への影響が生じます。(NVD)
| 項目 | 内容 |
|---|---|
| CVE | CVE-2026-38754 |
| 対象サービス | Azure Linux 3.0／BusyBox |
| Azure Linuxの対象パッケージ | busybox 1.36.1-24 |
| 修正版 | busybox 1.36.1-25以降 |
| 影響 | ashの異常終了によるDoS |
| 問題箇所 | shell/ash.cのifsbreakup() |
| 恒久対策 | 修正版パッケージへの更新 |
| 個別の回避策 | MSRCでは掲載なし |
Azure Linuxの公式リポジトリでは、CVE-2026-38754とCVE-2026-38755に対応するパッチを追加し、BusyBoxのパッケージリリースを1.36.1-24から1.36.1-25へ更新しています。(GitHub)
BusyBoxのifsbreakup()で何が起きるのか
ashとIFSの役割
BusyBoxは、組み込み機器、最小構成のLinux、コンテナなどで利用される軽量なコマンド群です。ashはBusyBoxに含まれるシェルで、環境によっては/bin/shとして使われます。
IFSは「Internal Field Separator」の略で、シェルが文字列を空白、タブ、改行などで分割する際に使用する区切り文字です。ifsbreakup()は、展開後の文字列をIFSに基づいて分割する処理を担当します。
今回の問題では、内部制御文字であるCTLESCを読み飛ばした直後の境界確認が不十分でした。CTLESCが記録領域の末尾に置かれていると、走査位置が領域の終端まで進み、その先の1バイトを参照する可能性がありました。また、エラー処理から復帰した後に、記録されていた領域情報が現在のスタック領域と一致しなくなるケースも考慮されていませんでした。修正パッチでは、走査範囲を現在のスタックブロック内に制限し、終端到達後に参照を続けないよう境界検査が追加されています。(lists.busybox.net)
「ヒープオーバーフロー」と「境界外読み取り」の表現差
CVE情報では本脆弱性が「heap overflow」として要約されています。一方、BusyBoxの上流パッチでは、具体的な問題を「out-of-bounds read」と表現しています。(NVD)
対応担当者が重視すべきなのは呼称の違いではなく、次の事実です。
ifsbreakup()の境界処理にメモリ安全性の問題がある- 細工された入力によって
ashが異常終了する可能性がある - Azure Linux向け修正は
1.36.1-25へ取り込まれている - 修正版への更新が恒久対策である
公開情報からは、任意コード実行や情報窃取まで可能であるとは確認できません。影響を説明する際は、根拠なく「システム乗っ取りにつながる」と拡大解釈せず、まずDoSによる可用性低下として扱うのが適切です。
影響を受ける環境の判断基準
Azure Linux 3.0を利用しているだけで、すべての環境が同じ危険度になるわけではありません。少なくとも、次の条件を分けて確認します。
- 対象のBusyBoxパッケージがインストールされているか
- インストール済みリリースが
1.36.1-24か - アプリケーションやジョブがBusyBoxの
ashを使用しているか - 外部または信頼できない入力がシェル処理へ到達するか
パッケージ状態ごとの判定
| 確認結果 | 判定 | 必要な対応 |
|---|---|---|
1.36.1-24 | Azure Linux 3.0の影響対象 | 1.36.1-25以降へ更新 |
1.36.1-25以降 | Azure Linux向け修正を含む | 再起動・再デプロイと動作確認 |
| BusyBox未インストール | ホスト上のRPMは対象外 | コンテナや組み込みイメージを別途確認 |
| 他ディストリビューションのBusyBox | バージョン番号だけでは判定不可 | 各ベンダーのアドバイザリを確認 |
| 独自ビルドのBusyBox | パッケージ修正状況が不明 | 上流パッチの取り込み状況を確認 |
NVDなどの上流情報に記載されるBusyBoxのバージョンと、Azure LinuxのRPMバージョンは一致しない場合があります。Azure Linuxでは、上流バージョンを1.36.1のまま維持しながら、セキュリティ修正をディストリビューション側でバックポートしています。そのため、「上流情報には1.38.0と書かれているから、1.36.1は対象外」と判断してはいけません。(NVD)
Azure Linux 3.0でBusyBoxのバージョンを確認する手順
OSがAzure Linux 3.0か確認する
最初に、対象ホストのOS情報を確認します。
cat /etc/os-releaseNAME、VERSION、VERSION_IDなどを確認し、Azure Linux 3.0の環境であることを特定します。
複数台を管理している場合は、サーバー名、クラウドリソース名、用途、担当者も併せて記録してください。単にコマンドを実行するだけでなく、どのシステムを調査済みか追跡できる状態にすることが重要です。
RPMの完全なバージョンを確認する
次のコマンドで、バージョンとリリース番号を確認します。
rpm -q --qf '%{NAME} %{VERSION}-%{RELEASE}.%{ARCH}\n' busybox確認すべきなのは、1.36.1だけではなく、その後ろに付く-24または-25です。
脆弱な状態の例は次のようになります。
busybox 1.36.1-24...修正版が導入されている場合は、次のようになります。
busybox 1.36.1-25...ディストリビューション識別子やCPUアーキテクチャが付加されることがあるため、出力全体が完全一致するかではなく、VERSION-RELEASEが1.36.1-25以上かを確認してください。
次のように表示された場合、ホストOSのRPMとしてBusyBoxはインストールされていません。
package busybox is not installedただし、ホストにインストールされていなくても、稼働中のコンテナイメージ内にBusyBoxが含まれている可能性があります。
busyboxコマンドの表示だけで判定しない
次のような確認だけでは不十分です。
busybox | head -n 1この方法では上流バージョンの1.36.1までしか表示されず、Azure Linuxの修正前リリース-24と修正後リリース-25を区別できない場合があります。
脆弱性対応の証跡には、必ずrpm -qで取得した完全なパッケージ情報を使用してください。
BusyBoxを1.36.1-25以降へ更新する手順
Azure Linux 3.0では、RPMパッケージの管理にtdnfを使用します。MicrosoftのAzure Linuxドキュメントでも、パッケージ全体の更新にはtdnf upgrade、個別パッケージの更新にはtdnf update <パッケージ名>を使用する方法が案内されています。(Microsoft Learn)
更新前の状態を記録する
更新前に、現在のパッケージ情報を保存します。
rpm -q --qf '%{NAME} %{VERSION}-%{RELEASE}.%{ARCH}\n' busybox本番環境では、併せて次の点を確認します。
- BusyBoxや
ashを使用するサービス - 更新後に再起動できる時間帯
- コンテナやイメージの管理元
- ロールバック手順
- 独自リポジトリや社内ミラーの同期状況
BusyBoxを更新する
個別パッケージだけを更新する場合は、次のコマンドを実行します。
sudo tdnf update -y busybox更新候補を事前に確認したい場合は、先にパッケージ情報を表示します。
sudo tdnf info busybox1.36.1-25以降が表示されない場合は、リポジトリ情報が古い可能性があります。キャッシュを削除して再確認します。
sudo tdnf clean all
sudo tdnf --refresh info busyboxその後、改めて更新を実行します。
sudo tdnf update -y busybox社内ミラーやプロキシを使用している環境では、Microsoft側で修正版が公開されていても、内部リポジトリへの同期が完了していないことがあります。更新候補が表示されない場合は、端末側でコマンドを繰り返すだけでなく、ミラーサーバーの同期状況と有効なリポジトリ設定を確認してください。
更新後のバージョンを確認する
更新完了後、再度RPM情報を確認します。
rpm -q --qf '%{NAME} %{VERSION}-%{RELEASE}.%{ARCH}\n' busybox1.36.1-25以降になっていることを確認します。
Azure Linuxの修正コミットでは、CVE-2026-38754向けパッチをBusyBoxのRPM仕様へ追加し、リリース番号を24から25へ変更しています。(GitHub)
更新後にサービスの再起動が必要な理由
パッケージ更新によってディスク上のBusyBoxが置き換わっても、すでに起動中のプロセスが読み込んでいるコードまで自動的に差し替わるとは限りません。
更新後は、BusyBoxのashや/bin/shを利用する次のような処理を確認してください。
- 常駐サービスから起動されるシェル
- 定期実行中のジョブ
- CI/CDランナー
- エージェントや監視プログラム
- コンテナのエントリーポイント
- 長時間実行されているシェルセッション
影響するサービスが特定できる場合は、そのサービスを再起動します。特定が難しい場合は、保守手順に従ってノードやホストの再起動を検討します。
BusyBoxの更新だけを理由にOS再起動が常に必須になるわけではありません。ただし、更新前のプロセスを残したまま「RPMのバージョンだけ修正済み」とするのは避けてください。
コンテナ環境ではホスト更新だけでは不十分
BusyBoxは、軽量なコンテナイメージのシェルやユーティリティとして含まれることがあります。ホスト側のAzure Linuxを更新しても、既存のコンテナイメージ内にあるBusyBoxは更新されません。
コンテナ環境では、次の流れで対応します。
- 利用中のイメージとタグ、ダイジェストを一覧化する
- SBOMまたは脆弱性スキャナーでBusyBoxの有無を確認する
- Dockerfileやベースイメージを修正版へ更新する
- キャッシュに依存せずイメージを再ビルドする
- ビルド後のイメージを再スキャンする
- 新しいイメージを再デプロイする
- 古いPod、タスク、コンテナを終了する
稼働中のコンテナに入ってtdnf updateを実行するだけでは、コンテナを作り直した際に脆弱な状態へ戻ります。修正は必ずDockerfile、イメージビルド、デプロイ定義へ反映してください。
ベースイメージをダイジェストで固定している場合は、再現性が高い一方で、修正版が公開されても自動では切り替わりません。修正版を含む新しいダイジェストへ意図的に更新する必要があります。
外部から攻撃される可能性を判断するポイント
CVE-2026-38754が存在するからといって、すべてのAzure Linuxホストがインターネット経由で直接攻撃できるわけではありません。
実際の到達可能性は、細工された入力がashの文字列分割処理まで渡る経路があるかで判断します。
リスクが高くなりやすい例は次のとおりです。
- Web APIの入力値を使って
sh -cを実行している - CI/CDサービスが利用者からシェルスクリプトを受け取る
- 外部から受け取った設定値をシェル変数として展開する
- ジョブ実行基盤が利用者指定のコマンドを処理する
- 管理エージェントが遠隔配信されたフックやスクリプトを実行する
- コンテナの起動引数をシェル文字列として連結する
反対に、BusyBoxがインストールされていても、ashが使用されず、信頼できない入力がシェルへ到達しない環境では、直ちに外部から悪用される可能性は低くなります。
ただし、到達経路が見つからないことは、修正版への更新が不要という意味ではありません。後から構成変更や新しいジョブが追加される可能性があるため、対象パッケージは更新しておくべきです。
すぐに更新できない場合の一時的なリスク低減策
MSRCでは、本脆弱性に対する個別の回避策が掲載されていません。そのため、以下は正式な修正の代替ではなく、更新までの一時的な露出低減策です。(Microsoft Security Response Center)
信頼できない入力をashへ渡さない
特に、次のようなコードや設定を確認します。
sh -c "$USER_INPUT"外部入力を含む文字列を組み立ててsh -cへ渡す設計は避け、可能であれば引数配列を使って対象プログラムを直接実行します。
また、入力値は許可リスト方式で検証し、制御文字や想定外の区切り文字を含む値を拒否します。
外部公開された実行機能を制限する
更新までの間、次のような機能の停止またはアクセス制限を検討します。
- 利用者が任意のコマンドを指定できるAPI
- 外部入力を受け取るジョブ実行機能
- シェルスクリプトのアップロード機能
- 認証なしで利用できるWebhook
- 外部から設定を受信する管理エージェント
ネットワーク制限だけで完全に防げるとは限りませんが、攻撃可能な利用者や経路を減らす効果はあります。
権限と再起動回数を制限する
対象サービスを必要最小限の権限で実行し、コンテナやサービスにCPU・メモリ・再起動回数の制限を設定します。
これは脆弱性そのものを修正する対策ではありませんが、異常終了が繰り返された場合の影響範囲を抑えるために役立ちます。
対応時に失敗しやすいポイント
| 失敗例 | 問題点 | 正しい対応 |
|---|---|---|
busybox --helpだけを見る | -24と-25を区別できない | rpm -qで完全なリリースを確認 |
| 上流の1.38.0表記だけで判断する | Azure Linuxのバックポート状況を見落とす | Azure LinuxのRPMリリースを基準にする |
| ホストだけ更新する | コンテナ内のBusyBoxが残る | イメージを再ビルドして再デプロイ |
| RPM更新だけで完了扱いにする | 起動中プロセスが旧コードを使い続ける可能性 | 関連サービスを再起動 |
| 修正版が表示されないまま放置する | ミラーやキャッシュが古い可能性 | リポジトリと同期状況を確認 |
| 非公式サイトからRPMを入手する | 改ざんや依存関係破損のリスク | Microsoftが提供する正規リポジトリを使用 |
| 一時的な入力制限だけで完了とする | 脆弱なバイナリが残る | 最終的に1.36.1-25以降へ更新 |
対応完了を判断するチェックリスト
次の項目をすべて確認してから、対応完了とします。
- Azure Linux 3.0の対象ホストを一覧化した
- ホストのBusyBoxパッケージを確認した
1.36.1-24の環境を1.36.1-25以降へ更新したrpm -qの結果を証跡として保存した- BusyBoxや
ashを使用するサービスを再起動した - コンテナイメージを再ビルド・再デプロイした
- 古いコンテナやPodが残っていないことを確認した
- サービスのヘルスチェックとログを確認した
- 脆弱性スキャナーのデータベースを更新して再スキャンした
- 更新できない環境の理由、暫定対策、対応期限を記録した
まとめ：1.36.1ではなくRPMのリリース番号を確認する
CVE-2026-38754への対応では、Azure Linux 3.0のBusyBoxが1.36.1-24であれば、1.36.1-25以降へ更新することが最優先です。公式の個別回避策は示されていないため、一時的な入力制限やネットワーク制限だけで対応済みとしてはいけません。
まず、次のコマンドで現在の状態を確認します。
rpm -q --qf '%{NAME} %{VERSION}-%{RELEASE}.%{ARCH}\n' busybox1.36.1-24が検出された場合は、次のコマンドで更新します。
sudo tdnf update -y busyboxその後、完全なパッケージリリースが1.36.1-25以降になったことを確認し、関連サービスの再起動、コンテナイメージの再ビルド、再スキャンまで実施してください。(GitHub)
コメント