Azure Linux 3.0でbusybox 1.36.1-24を使用している場合、CVE-2026-38755の修正を含む1.36.1-25以降へ更新する必要があります。この脆弱性は、BusyBoxのシェルであるashが細工された入力を処理した際に異常終了し、サービス停止などのDoSにつながる問題です。
MicrosoftはAzure Linux向けBusyBoxのリリースを24から25へ更新し、CVE-2026-38755のパッチを追加しています。個別の回避策は示されていないため、基本対策はパッケージ更新です。ホストOSだけでなく、BusyBoxを含むコンテナイメージや独自配布バイナリも別途確認してください。(GitHub)
CVE-2026-38755の概要
| 項目 | 内容 |
|---|---|
| CVE番号 | CVE-2026-38755 |
| 対象コンポーネント | BusyBoxのashシェル |
| 主な影響 | プロセスの異常終了によるDoS |
| Azure Linux 3.0の影響バージョン | busybox 1.36.1-24 |
| Azure Linux 3.0の修正版 | busybox 1.36.1-25以降 |
| 公式の個別回避策 | 掲載なし |
| 推奨対策 | 修正版への更新、依存サービスの再起動、コンテナの再ビルド |
NVDの説明では、BusyBoxのshell/ash.cにあるevalcommand()でヒープオーバーフローが発生し、細工した入力によってDoSを引き起こせるとされています。公開情報から確認できる主な影響は可用性の低下であり、この記事の根拠だけから任意コード実行まで可能だと判断することはできません。(NVD)
BusyBoxのashで何が起きるのか
BusyBoxは、cat、cp、grep、shなど多数のLinuxコマンドを、1つの小さな実行ファイルにまとめたソフトウェアです。軽量なため、最小構成のLinux、コンテナ、組み込み機器、復旧環境などで広く使われます。
ashはBusyBoxに含まれる軽量シェルです。環境によっては、次のように/bin/shの実体として使われています。
readlink -f /bin/shashに外部から制御できる入力が渡り、脆弱な処理経路に到達すると、BusyBoxプロセスが異常終了する可能性があります。
単発の管理用シェルが終了するだけなら影響は限定的ですが、次のような用途ではサービス障害につながります。
- Web APIが入力値を組み立てて
ash -cへ渡している - CI/CDのジョブで利用者が指定したスクリプトを実行している
- コンテナのエントリーポイントがBusyBoxの
ashである - 監視エージェントやジョブ実行基盤がシェル処理に依存している
- プロセスの異常終了と自動再起動が繰り返される
重要なのは、BusyBoxがインストールされているかだけではありません。信頼できない入力がashへ到達するか、そのプロセス停止がシステム全体へ波及するかまで確認する必要があります。
公開情報には実装箇所の表現差がある
CVEの公開説明では、evalcommand()におけるヒープオーバーフローとして記載されています。一方、BusyBoxのアップストリームパッチは「evalfun()のスタックオーバーフロー修正」とされ、再帰的なシェル関数によるスタック枯渇を防ぐため、関数呼び出しの深さを制限する内容です。(NVD)
Azure Linuxの修正パッケージにも、この再帰深度を制限するパッチが取り込まれています。したがって、実務では関数名やCWEの表記だけで該当性を判断せず、Microsoftが示すAzure Linuxのパッケージリリース番号を基準に対応するのが確実です。(GitHub)
Azure Linux 3.0が影響を受けるか確認する方法
OSのバージョンを確認する
最初に、対象環境がAzure Linux 3.0であることを確認します。
cat /etc/os-release出力にAzure LinuxとVERSION_ID="3.0"が含まれているか確認してください。
Azure Linux 3.0では、パッケージ管理に主にtdnfを使用します。Azure Linux 4.0ではdnf5へ変更されているため、異なるメジャーバージョン向けの手順を混在させないよう注意が必要です。(Microsoft Learn)
BusyBoxのRPMバージョンを確認する
次のコマンドで、バージョンだけでなくRPMのリリース番号まで表示します。
rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' busybox判断の目安は次のとおりです。
| 確認結果 | 判断 |
|---|---|
busybox-1.36.1-24... | CVE-2026-38755の影響対象。更新が必要 |
busybox-1.36.1-25... | Azure Linux向け修正を含む |
busybox-1.36.1-26...など、25より新しいリリース | 通常は修正を継承しているが、パッケージ履歴も確認 |
package busybox is not installed | ホストのRPMは対象外。ただしコンテナやコピー済みバイナリを別途確認 |
| 独自ビルドや他社配布版 | Azure Linuxのリリース番号では判定できない。配布元のアドバイザリを確認 |
MicrosoftのAzure Linuxリポジトリでは、BusyBoxのVersionは1.36.1のまま、Releaseが24から25へ変更されています。1.36.1-25の変更履歴には、CVE-2026-38755とCVE-2026-38754のパッチ適用が記載されています。(GitHub)
busybox --helpだけでは判定しない
次のような確認だけでは不十分です。
busybox --help | head -n 1この出力には、通常はアップストリームのバージョンである1.36.1しか表示されません。修正前の1.36.1-24と修正後の1.36.1-25は、どちらも同じ1.36.1に見える可能性があります。
そのため、必ずrpm -qでRPMのRelease番号まで確認してください。
実行中のBusyBoxがRPM管理下にあるか確認する
BusyBoxの場所と、どのRPMから導入されたかを確認します。
command -v busyboxrpm -qf "$(command -v busybox)"RPM名が返らず「ファイルがどのパッケージにも属していない」と表示される場合は、次のような可能性があります。
- 手動で配置したBusyBoxバイナリ
- 別のビルドステージからコピーした静的バイナリ
- ベンダー製品に同梱されたBusyBox
- コンテナ内部にのみ存在するBusyBox
この場合、ホストのbusyboxパッケージを更新しても、そのバイナリは修正されません。
BusyBoxを1.36.1-25以降へ更新する手順
更新前に確認しておくこと
本番環境では、更新前に次の点を確認します。
- BusyBoxを使用するサービスやバッチ処理
- コンテナ、VM、アプライアンスへの組み込み状況
- ロールバック手段やVMスナップショット
- 更新後に再起動するサービス
- 同じ構成を持つ検証環境の有無
- Azure Linux 3.0用リポジトリが有効か
BusyBoxは小さなパッケージですが、シェルや起動スクリプトに使われていると影響範囲が広くなります。更新前後の動作確認項目を決めてから適用してください。
tdnfでBusyBoxを更新する
まず、リポジトリのキャッシュを削除します。
sudo tdnf clean all続いて、BusyBoxだけを更新します。
sudo tdnf upgrade busybox -ytdnf upgradeは、指定したパッケージをリポジトリで利用可能な上位バージョンへ更新するコマンドです。Azure Linuxではtdnf upgradeがパッケージ更新に使用されます。(Microsoft Learn)
リポジトリ情報を明示的に更新しながら実行する場合は、次のようにします。
sudo tdnf upgrade busybox --refresh -y「Nothing to do」と表示される場合
1.36.1-24のまま「Nothing to do」と表示された場合、修正版が利用中のリポジトリに見えていない可能性があります。
有効なリポジトリを確認します。
sudo tdnf repolistBusyBoxのインストール済み・利用可能バージョンを確認します。
sudo tdnf info busybox更新候補全体を確認する場合は、次のコマンドも利用できます。
sudo tdnf list updates修正版が表示されない場合は、次を確認してください。
- Azure Linux 3.0用の公式リポジトリを参照しているか
- 社内ミラーの同期が完了しているか
- プロキシやファイアウォールでメタデータ取得が妨げられていないか
- リポジトリ設定で更新用チャネルが無効になっていないか
- パッケージがバージョン固定されていないか
出所不明のRPMを外部サイトから取得して置き換えるのは避けてください。社内ミラーを利用している場合は、まずミラー側で1.36.1-25以降が同期されているか確認します。
更新後の確認手順
RPMのリリース番号を確認する
更新後、再度バージョンを確認します。
rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' busybox少なくとも次の状態になっていることを確認します。
busybox-1.36.1-25...1.36.1-25より新しいAzure Linux向けリリースでも、当該パッチが継承されていれば問題ありません。
インストール済みファイルを検証する
RPMデータベース上の情報と実ファイルに差異がないか確認します。
rpm -V busybox問題がなければ、通常は何も表示されません。出力がある場合は、BusyBoxのファイルが手動変更されていないか確認してください。
ashの基本動作を確認する
攻撃入力を再現する必要はありません。通常のシェル処理が動作するかを確認します。
busybox ash -c 'printf "%s\n" "ash-ok"'次のように表示されれば、基本的な起動確認は完了です。
ash-okその後、BusyBoxに依存するサービス、バッチ、コンテナのヘルスチェックを実施します。
稼働中のプロセスを再起動する
RPMを更新しても、すでに起動しているプロセスは更新前の実行コードを保持したまま動作することがあります。
BusyBoxやashを継続利用するサービスがある場合は、対象サービスを再起動してください。依存関係を特定しにくい場合は、メンテナンス時間内にOSを再起動する方法もあります。
ただし、BusyBoxはカーネルパッケージではないため、パッケージ更新そのものが常にOS再起動を要求するわけではありません。再起動の要否は、実際にBusyBoxを利用しているプロセスと運用方針で判断します。
コンテナではホスト更新だけで終わらせない
BusyBoxは最小構成のコンテナで利用されることが多いため、ホストOSだけを更新して対応完了と判断しないことが重要です。
ホストのRPMを1.36.1-25へ更新しても、既存のコンテナイメージに含まれるBusyBoxは変更されません。
実行中のコンテナで確認する
RPM管理されたAzure Linuxベースのコンテナであれば、コンテナ内で確認します。
kubectl exec -n <namespace> <pod-name> -- \
rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' busyboxDocker環境では、次のように確認できます。
docker exec <container-name> \
rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' busyboxコンテナ内にrpmがない場合は、SBOM、Dockerfile、イメージスキャン結果、ビルドログからBusyBoxの供給元を確認してください。
Dockerfileで更新する
Azure Linux 3.0ベースのイメージでBusyBoxがRPM管理されている場合は、Dockerfile内で更新します。
RUN tdnf upgrade busybox -y \
&& tdnf clean allその後、イメージを再ビルドし、レジストリへ登録して再デプロイします。
対応の流れは次のとおりです。
- Dockerfileまたはベースイメージを更新する
- キャッシュだけに依存せずイメージを再ビルドする
- イメージスキャンでCVE-2026-38755を再評価する
- 新しいイメージダイジェストを確認する
- Podやコンテナをローリング更新する
- 実行中のコンテナ内部でバージョンを再確認する
単体コピーされたBusyBoxに注意する
次のようなDockerfileでは、RPMの更新履歴を追跡できない場合があります。
COPY --from=builder /bin/busybox /bin/busyboxこの構成では、最終イメージでrpm -q busyboxを実行しても、パッケージが存在しないと表示されます。
対策として、次を記録してください。
- コピー元イメージのダイジェスト
- BusyBoxバイナリのハッシュ値
- ビルド元のソースやパッチ
- SBOM上のBusyBoxバージョン
- CVE-2026-38755の修正を含むことを確認した根拠
なお、上流版のバージョン番号が新しいことだけでは安全と判断できません。NVDの公開説明ではBusyBox 1.38.0にも言及されているため、独自ビルドでは修正コミットの有無まで確認する必要があります。(NVD)
すぐに更新できない場合の暫定対策
MSRCではCVE-2026-38755専用の回避策が示されていません。そのため、次の対応はあくまで更新までの補完的なリスク低減策です。修正版への更新の代わりにはなりません。
| 暫定対策 | 目的 | 注意点 |
|---|---|---|
外部入力をash -cへ直接渡さない | 攻撃入力がシェルへ到達するのを防ぐ | 文字列のエスケープだけに依存しない |
| 利用者が指定したシェルスクリプトの実行を停止する | 不特定入力による再帰処理を防ぐ | CI/CDやジョブ実行基盤への影響を確認 |
| APIや管理画面へのアクセスを制限する | 攻撃可能な利用者を減らす | 恒久対策にはならない |
| コンテナのCPU・メモリ・プロセス数を制限する | 障害の波及範囲を抑える | BusyBox自体の異常終了は防げない |
| 再起動回数やバックオフを設定する | 再起動ループによる負荷増大を防ぐ | サービス停止時間が延びる場合がある |
| 対象ワークロードをネットワーク分離する | 外部到達性を下げる | 内部利用者からの入力は別途管理が必要 |
| 重要度の低い対象サービスを一時停止する | 可用性事故を回避する | 業務影響との比較が必要 |
特に避けるべき実装は、利用者入力をそのままコマンド文字列へ連結する方法です。
busybox ash -c "$USER_INPUT"入力値をシェルへ渡さず、固定したコマンドと個別の引数として処理できる設計へ変更してください。
対応優先度の判断基準
CVE-2026-38755は、公開されているCVSS評価にも差があります。NVD自身の評価は未提示で、MITREの評価は2.9、CISA-ADPの評価は7.5となっています。攻撃元や必要条件、可用性への影響について見方が一致していないため、スコアだけで対応期限を決めるべきではありません。(NVD)
実際の優先度は、次の順に判断します。
| 環境 | 対応優先度の目安 |
|---|---|
外部入力をashへ渡すインターネット公開サービス | 最優先で更新 |
| 複数利用者がスクリプトを実行できるCI/CD基盤 | 最優先で更新 |
| コンテナのPID 1や起動処理にBusyBoxを使用 | 高 |
| 障害時に多数の再起動や再スケジュールが発生する | 高 |
| 管理者だけがローカルで利用し、外部入力経路がない | 計画的に早期更新 |
| ホストには未導入だが、コンテナの状況が不明 | イメージ棚卸しを優先 |
1.36.1-25以降への更新と再起動を確認済み | 対応済みとして記録 |
DoSであっても、認証、ルーティング、監視、ジョブ管理などの重要プロセスが停止すれば、システム全体へ影響します。「情報漏えいではないから後回し」と判断せず、停止時の業務影響を基準にしてください。
対応時によくある失敗
上流バージョンだけを確認する
busybox --helpで1.36.1と表示されただけでは、修正前か修正後か分かりません。
次の形式でRPMのRelease番号を確認します。
rpm -q --qf '%{VERSION}-%{RELEASE}\n' busyboxホストだけを更新してコンテナを残す
ホストのbusyboxパッケージと、コンテナイメージ内のBusyBoxは別物です。イメージの再ビルドとワークロードの再デプロイまで実施してください。
更新後に長時間稼働プロセスを再起動しない
ディスク上の実行ファイルが更新されても、起動済みプロセスが自動的に新しいコードへ切り替わるとは限りません。BusyBoxに依存するプロセスを再起動します。
Nothing to doを対応済みと判断する
tdnfが更新なしと表示しても、インストール済みパッケージが1.36.1-24なら未対応です。リポジトリ、ミラー、キャッシュ、バージョン固定を調査してください。
独自RPMや非公式バイナリで上書きする
緊急対応でも、出所や署名を確認できないRPMを導入すると、サプライチェーンリスクや依存関係の破損につながります。Azure Linuxの正規リポジトリ、または組織が管理する検証済みミラーを使用してください。
暫定的な入力制限を恒久対策とみなす
入力制限、ネットワーク分離、リソース制限は被害を抑えるための対策です。脆弱なコード自体は残るため、最終的には1.36.1-25以降へ更新する必要があります。
CVE-2026-38755への対応を完了するための確認項目
最初に、Azure Linux 3.0上で次のコマンドを実行します。
rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' busybox1.36.1-24が表示された場合は、次のコマンドで更新します。
sudo tdnf clean all
sudo tdnf upgrade busybox -y更新後は、1.36.1-25以降になったことを確認し、BusyBoxに依存するサービスを再起動します。コンテナ環境では、ホスト更新とは別にイメージを再ビルドし、実行中のPodやコンテナを入れ替えてください。
最終的な対応完了条件は、単に更新コマンドが成功したことではありません。対象資産の棚卸し、修正版の導入、プロセスの再起動、コンテナの再デプロイ、更新後のバージョン確認までを一連の作業として記録することが重要です。
参考情報
- Microsoft Security Response CenterのCVE-2026-38755情報。(Microsoft Security Response Center)
- Azure LinuxのBusyBox修正コミットと
1.36.1-25の変更履歴。(GitHub) - NVDのCVE-2026-38755概要およびCVSS情報。(NVD)
- BusyBoxアップストリームの
ash再帰処理修正パッチ。(BusyBox メーリングリスト)
“
コメント