Azure Linux 3.0でUnboundを利用しており、dns-error-reporting: yes が有効になっている場合、CVE-2026-55973への対応はunbound-1.25.2-1.azl3以上への更新を基準にしてください。
MSRCのFirstFixed情報には1.25.1-1と読める記載がありますが、同じMSRCのVEXにある修復情報は1.25.2-1.azl3を示しています。さらに、Unbound開発元は1.25.1までを影響対象、1.25.2を修正版として公表しています。したがって、実務上は1.25.1-1を修正版として扱わず、1.25.2-1.azl3以上へ更新するのが安全です。(Microsoft Security Response Center)
この記事では、CVE-2026-55973の影響条件、Azure Linux 3.0での確認方法、Unboundの更新手順、すぐに更新できない場合の緩和策まで具体的に解説します。
CVE-2026-55973の結論：Unbound 1.25.2-1.azl3以上へ更新する
CVE-2026-55973は、UnboundのDNS Error Reporting処理における入力値の検証不備です。細工されたEDNS Report-Channelオプションを処理すると、スタック上のバッファーが上書きされ、Unboundデーモンが異常終了する可能性があります。
公表されている重要事項は次のとおりです。
| 項目 | 内容 |
|---|---|
| 対象製品 | Azure Linux 3.0上のUnbound |
| 脆弱性 | スタックバッファーオーバーフロー |
| 発生条件 | dns-error-reporting: yesが有効 |
| 上流版の影響範囲 | Unbound 1.23.0以上、1.25.2未満 |
| 修正版 | Unbound 1.25.2 |
| Azure Linux向け更新基準 | unbound-1.25.2-1.azl3以上 |
| CVSS | 7.5 High |
| CWE | CWE-20：不適切な入力検証 |
| 主な影響 | Unboundの異常終了によるDNSサービス妨害 |
CVSSベクターはCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Hです。ネットワーク経由で攻撃でき、認証や利用者操作を必要とせず、可用性への影響が大きいと評価されています。公表評価上、機密性と完全性への影響は設定されていません。(Microsoft Security Response Center)
CVE-2026-55973で何が起きるのか
Unboundには、DNSの名前解決エラーを権威DNSサーバー側へ通知するDNS Error Reporting機能があります。この機能は、設定ファイルで次のように指定した場合に有効になります。
server:
dns-error-reporting: yesdns-error-reportingの既定値はnoです。そのため、設定を明示的に有効化していない環境では、この脆弱性の攻撃経路は通常有効になっていません。(NLnet Labs)
問題は、UnboundがEDNS Report-Channelオプションを含む応答を受け取ったときの長さ検証にあります。
攻撃者が委任されたDNSゾーンを制御している場合、細工したReport-Channelオプションを権威DNSサーバーから返すことができます。脆弱なUnboundは、エージェントドメイン名の実際の長さではなくEDNSオプション全体の長さを使って報告用の_er.クエリーを組み立てるため、スタック変数のバッファーを上書きする可能性があります。
開発元の説明では、攻撃者が制御する委任ゾーンからの1回の上流応答だけでも、Unboundデーモンを終了させられる可能性があります。DNSキャッシュサーバーが停止すれば、そのサーバーを利用するシステムで名前解決が失敗し、Webアクセス、API通信、認証処理などが連鎖的に停止するおそれがあります。(GitHub)
MSRCのFirstFixed「1.25.1-1」をそのまま修正版と判断しない
CVE-2026-55973では、Microsoftの公開情報内にバージョン表記の不整合があります。
| 確認先 | 掲載されている情報 |
|---|---|
| MSRCの製品ツリー／FirstFixed相当情報 | azl3 unbound 1.25.1-1を固定済み製品として掲載 |
| 同じMSRC VEXの修復情報 | 0:1.25.2-1.azl3:Security Update |
| Unbound開発元 | 1.23.0から1.25.1までが影響対象 |
| CVEレコードの解決策 | 1.25.2から修正済み |
| Azure Linux 3.0公式リポジトリ | unbound-1.25.2-1.azl3を公開 |
MSRCのVEXでは、製品ツリー上の固定済みバージョンと、修復情報に記載されたパッケージバージョンが一致していません。(Microsoft Security Response Center)
一方、Unbound開発元とCVEレコードは、1.25.1を影響対象に含め、1.25.2で修正したと明示しています。Azure Linux 3.0の公式パッケージリポジトリにも、x86_64版とaarch64版の1.25.2-1.azl3が公開されています。(GitHub)
このため、Azure Linux 3.0の運用担当者は、次のように判断してください。
1.25.1-1.azl3を修正済みと判断しない1.25.2-1.azl3以上を更新後の最低基準にする- 独自ビルドやバックポート版は、ビルド元の修正内容も確認する
- 脆弱性管理ツールの判定だけでなく、実際のRPMバージョンを確認する
Azure Linux 3.0が影響を受けるか確認する
Azure Linuxのバージョンを確認する
最初に、対象サーバーがAzure Linux 3.0であることを確認します。
cat /etc/os-release出力されたVERSION_IDが3.0系になっているか確認してください。
複数台を管理している場合は、資産管理ツールや構成管理ツールからOS情報を収集し、Azure Linux 3.0だけを抽出すると効率的です。
インストール済みのUnboundパッケージを確認する
RPMパッケージのバージョンを確認します。
rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' unbound出力例は次のとおりです。
unbound-1.25.1-1.azl3.x86_64おおよその判断基準は次のようになります。
| 確認結果 | 判断 |
|---|---|
| 1.23.0以上、1.25.2未満 | 上流の影響範囲に該当 |
1.25.1-1.azl3 | 修正前として扱い、更新が必要 |
1.25.2-1.azl3以上 | 上流修正を含むバージョン |
| 1.23.0未満 | 本CVEの公表範囲外。ただし、別の脆弱性を含む可能性があるため更新を検討 |
| package unbound is not installed | ホストのRPM版は対象外。コンテナや独自ビルドを別途確認 |
rpm -qで未導入と表示されても、ソースコードからインストールしたUnboundが存在する場合があります。念のため、次のコマンドでも確認します。
command -v unbound
unbound -Vホスト上に存在しなくても、DockerやKubernetesのコンテナ内でUnboundを動かしているケースがあります。ホストOSとアプリケーションコンテナは別々に確認してください。
dns-error-reportingの有効値を確認する
Azure Linux 3.0のUnboundパッケージでは、標準の設定ファイルとして/etc/unbound/unbound.confが使用されます。(GitHub)
設定ファイルを単純に検索するだけでなく、unbound-checkconfで読み込み後の有効値を確認します。
sudo unbound-checkconf -o dns-error-reporting /etc/unbound/unbound.conf結果が次のように表示された場合は、脆弱な処理が有効です。
yes次のように表示されれば、DNS Error Reportingは無効です。
nounbound-checkconf -oは、インクルードされた設定ファイルを含めて解析した後の値を確認できます。メイン設定ファイルだけをgrepするより、実際の動作設定を正確に判定できます。(NLnet Labs)
設定箇所を探したい場合は、次のコマンドも利用できます。
sudo grep -RniE '^[[:space:]]*dns-error-reporting:' /etc/unboundUnboundの起動時に別の設定ファイルを指定している可能性もあります。実行中のコマンドラインを確認してください。
ps -eo pid,args | grep '[u]nbound'-c /path/to/unbound.confが表示された場合は、そのファイルに対してunbound-checkconfを実行します。
sudo unbound-checkconf -o dns-error-reporting /path/to/unbound.confUnboundサービスが稼働中か確認する
systemctl is-active unbound
systemctl status unbound --no-pager確認結果から、対応優先度を次のように決められます。
| バージョンと設定 | 稼働状態 | 対応優先度 |
|---|---|---|
1.23.0～1.25.1、設定がyes | 稼働中 | 最優先で更新 |
1.23.0～1.25.1、設定がno | 稼働中 | 現時点の攻撃経路は無効だが、早めに更新 |
| 1.23.0～1.25.1 | 停止中 | 再起動する前に更新 |
| 1.25.2以上 | 稼働中 | 修正版。プロセス再起動済みか確認 |
| RPM未導入 | － | コンテナ、独自バイナリ、別ホストを確認 |
dns-error-reporting: noであっても、脆弱なコードを含むパッケージを残してよいという意味ではありません。設定変更や構成管理の再適用によって、将来yesへ戻る可能性があるためです。
Azure Linux 3.0でUnboundを更新する手順
Azure Linux 3.0では、パッケージ管理にTiny DNFのtdnfを使用します。(Microsoft Learn)
更新前に設定をバックアップする
本番環境では、保守時間帯を確保したうえで設定ファイルをバックアップします。
sudo cp -a /etc/unbound \
"/var/tmp/unbound-backup-$(date +%Y%m%d-%H%M%S)"続いて、現在の設定に構文エラーがないことを確認します。
sudo unbound-checkconf /etc/unbound/unbound.conf更新前の時点でエラーが出る場合は、先に設定内容を確認してください。構文エラーを残したままサービスを再起動すると、Unboundが起動しなくなる可能性があります。
tdnfでUnboundを更新する
次のコマンドを実行します。
sudo tdnf update unbound -y更新完了後、パッケージバージョンを再確認します。
rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' unbound少なくとも、次のバージョン以上になっていることを確認してください。
unbound-1.25.2-1.azl3.x86_64aarch64環境では、末尾が次のようになります。
unbound-1.25.2-1.azl3.aarch64公式リポジトリには両アーキテクチャ向けの1.25.2-1.azl3パッケージが掲載されています。(Microsoft Packages)
更新しても1.25.1のままの場合は、次の点を確認します。
- 独自リポジトリや社内ミラーで古いパッケージが固定されていないか
- リポジトリの同期が完了しているか
- バージョンロックや除外設定が指定されていないか
- プロキシやファイアウォールによって更新先への通信が妨げられていないか
必要に応じてメタデータを削除してから再実行します。
sudo tdnf clean all
sudo tdnf update unbound -y設定ファイルの差分を確認する
RPM更新時に、新しい設定ファイルが.rpmnewとして作成されたり、既存ファイルが.rpmsaveへ退避されたりすることがあります。
sudo find /etc/unbound -type f \
\( -name '*.rpmnew' -o -name '*.rpmsave' \) -printファイルが見つかった場合は、既存設定との差分を確認してください。.rpmnewをそのまま上書きすると、アクセス制御、転送先、待受アドレス、DNSSEC関連設定などが失われる可能性があります。
構文確認後にUnboundを再起動する
sudo unbound-checkconf /etc/unbound/unbound.conf
sudo systemctl restart unboundRPMを更新しただけでは、起動中のUnboundプロセスが更新前の実行コードを使い続ける可能性があります。パッケージの更新後は、サービスの再起動まで実施してください。
再起動後に稼働状態を確認します。
systemctl is-active unbound
systemctl status unbound --no-pageractiveにならない場合は、ログを確認します。
sudo journalctl -u unbound --since "-10 minutes" --no-pager設定変更が原因で起動できない場合は、脆弱な旧パッケージへ戻すのではなく、バックアップした設定と比較して構文や互換性を修正します。
名前解決が正常か確認する
Unboundがローカルホストの53番ポートで待ち受けている場合は、次のように確認できます。
dig @127.0.0.1 example.com A +time=2 +tries=1status: NOERRORが表示され、回答が返ることを確認します。
Unboundが別のIPアドレスやポートで待ち受けている場合は、環境に合わせて変更してください。実運用では、社内ドメイン、外部ドメイン、DNSSECを利用するドメイン、転送先を使うドメインなども確認すると確実です。
すぐに更新できない場合の一時的な緩和策
保守時間をすぐに確保できない場合は、dns-error-reportingを無効化することで、CVE-2026-55973の攻撃経路を一時的に閉じられます。
まず、設定箇所を確認します。
sudo grep -RniE '^[[:space:]]*dns-error-reporting:' /etc/unbound設定がyesになっているファイルを編集し、次のように変更します。
server:
dns-error-reporting: no設定自体が存在しない場合、既定値はnoであるため追加する必要はありません。(NLnet Labs)
変更後は構文確認とサービス再起動を実施します。
sudo unbound-checkconf /etc/unbound/unbound.conf
sudo systemctl restart unbound最後に、有効値がnoになったことを確認します。
sudo unbound-checkconf -o dns-error-reporting /etc/unbound/unbound.confこの対応は、DNS Error Reporting機能を停止する一時的な緩和策です。脆弱なパッケージそのものが修正されるわけではないため、保守時間を確保でき次第、1.25.2-1.azl3以上へ更新してください。
AKSのAzure Linuxノードで使っている場合
Azure Kubernetes ServiceのAzure Linuxノードでは、ノードへログインして個別にRPMを更新する運用は避けたほうが安全です。ノードが再作成されたときに手動変更が失われるため、ノードイメージの更新を基本にします。
特定のノードプールを最新のノードイメージへ更新する例は次のとおりです。
az aks nodepool upgrade \
--resource-group <resource-group> \
--cluster-name <cluster-name> \
--name <node-pool-name> \
--node-image-only更新後は、ノードイメージのバージョンを確認します。
az aks nodepool show \
--resource-group <resource-group> \
--cluster-name <cluster-name> \
--name <node-pool-name> \
--query nodeImageVersion \
-o tsvAKSでは、ノードイメージのみを更新する操作が公式に用意されています。更新時にはノードの入れ替えが発生するため、Pod Disruption Budget、余剰ノード容量、業務時間帯への影響も事前に確認してください。(Microsoft Learn)
Unboundを自社のコンテナイメージ内へインストールしている場合、ノードイメージの更新だけでは修正されません。その場合は、コンテナイメージのベースパッケージを更新し、イメージを再ビルドしてDeploymentやDaemonSetを再展開する必要があります。
対応時に失敗しやすいポイント
| 失敗例 | 問題点 | 正しい対応 |
|---|---|---|
FirstFixedの1.25.1-1だけを信頼する | 上流では1.25.1が影響対象 | 1.25.2-1.azl3以上を基準にする |
| メイン設定ファイルだけを検索する | include先のyesを見落とす | unbound-checkconf -oで有効値を確認 |
| RPM更新後に再起動しない | 稼働中プロセスが旧コードを使い続ける | 構文確認後にサービスを再起動 |
rpm -qだけで対象外と判断する | 独自ビルドやコンテナを見落とす | バイナリとコンテナも確認 |
.rpmnewを無条件で上書きする | 既存のDNS設定が失われる | 差分を確認して必要部分だけ反映 |
| AKSノードを手動更新する | ノード再作成時に変更が失われる | ノードイメージを更新 |
| 緩和設定だけで対応を終了する | 脆弱なパッケージが残る | 最終的に修正版へ更新 |
CVE-2026-55973対応チェックリスト
対応完了の判断には、次の項目を確認してください。
- Azure Linux 3.0の対象ホストを特定した
- RPM、独自バイナリ、コンテナ内のUnboundを確認した
- Unboundのバージョンを確認した
dns-error-reportingの有効値を確認したunbound-1.25.2-1.azl3以上へ更新した- 設定ファイルの構文を確認した
- Unboundサービスを再起動した
- サービス状態とログを確認した
- 実際の名前解決テストを実施した
- 更新日時、更新後バージョン、対象ホストを記録した
CVE-2026-55973への対応では、MSRCのFirstFixed欄だけで修正版を判断しないことが重要です。まず次の2つのコマンドで、導入版と設定状態を確認してください。
rpm -q unbound
sudo unbound-checkconf -o dns-error-reporting /etc/unbound/unbound.conf1.23.0から1.25.1までのUnboundを利用している場合は、設定がnoであっても、unbound-1.25.2-1.azl3以上へ更新します。更新後は必ずサービスを再起動し、ログと名前解決の両方を確認してください。
コメント