CVE-2026-40691対策：Azure Linux 3.0のUnbound修正版と更新手順

Azure Linux 3.0でUnboundを利用している場合は、まずrpm -q unboundで導入バージョンを確認し、unbound-1.25.2-1.azl3以上へ更新してください。

MSRCのFirstFixed欄には「azl3 unbound 1.25.1-1 on Azure Linux 3.0」と掲載されています。しかし、Unboundの開発元であるNLnet Labsは、1.25.1までを影響対象、1.25.2を修正版と明記しています。MicrosoftのAzure Linux 3.0公式リポジトリにも、1.25.2-1のRPMが公開されています。そのため、実務では1.25.1-1で対応完了とせず、1.25.2-1以上を修正済みの判断基準にするのが安全です。(Microsoft Security Response Center)

CVE-2026-40691は、DNSCrypt over TCPの処理でヒープ領域外への書き込みが発生し、Unboundプロセスがクラッシュする脆弱性です。ただし、攻撃が成立するにはDNSCrypt対応ビルドと設定の有効化が必要です。この記事では、バージョン確認だけでなく、ビルド設定、稼働設定、待ち受けポートまで含めた確認方法を解説します。

CVE-2026-40691の概要

CVE-2026-40691は、UnboundがDNSCryptクエリをTCPで処理するときに発生するリモートサービス拒否の脆弱性です。

項目	内容
CVE番号	CVE-2026-40691
対象ソフトウェア	Unbound
影響を受ける上流バージョン	1.9.0以上、1.25.1以下
上流の修正版	Unbound 1.25.2
Azure Linux 3.0での更新目標	`unbound-1.25.2-1.azl3`以上
主な影響	Unboundのクラッシュ、DNSサービスの停止
攻撃経路	DNSCrypt over TCP
CVSS v3.1	7.5、High
CVSSベクター	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H`
主なCWE	CWE-122：ヒープベースのバッファオーバーフロー
認証の要否	不要
ユーザー操作	不要

NVDにはCWE-122に加えてCWE-787も掲載されていますが、主要な問題は、TCP応答を格納するヒープバッファの範囲を超えてデータが書き込まれることです。(NVD)

DNSCrypt over TCPでUnboundがクラッシュする仕組み

問題は、DNSCryptの応答をTCPで暗号化する処理にあります。

Unboundは応答データを同じバッファ内で移動しながら暗号化します。しかし、脆弱なバージョンでは、TCP経路に対して応答長と書き込み先バッファ容量の照合が十分に行われません。

UDP経路にはサイズを制限する処理がありますが、TCP経路には同じ制限が適用されていませんでした。そのため、65,504バイトを超える応答を48バイト前方へ移動すると、msg-buffer-sizeで確保されたヒープ領域の終端を超えて書き込む可能性があります。

細工された暗号化クエリは1件でもUnboundをクラッシュさせる可能性があり、DNS名前解決が停止します。CVSSベクターでも機密性と完全性への影響は「なし」、可用性への影響は「高」と評価されています。公開情報から確認できる主な影響はサービス拒否であり、この情報だけを根拠に任意コード実行が可能と判断すべきではありません。(NVD)

MSRCの1.25.1-1表記を修正版と断定しない

MSRCのFirstFixed欄には、次の製品名が掲載されています。

azl3 unbound 1.25.1-1 on Azure Linux 3.0

ただし、この値をそのまま「1.25.1-1にはCVE-2026-40691の修正が入っている」と解釈すると、上流情報との矛盾が生じます。

NLnet Labsは次のように明示しています。

Unbound 1.9.0から1.25.1までが影響を受ける
Unbound 1.25.2に修正が含まれる
1.25.1を継続利用する場合は、別途公式パッチを適用する必要がある

また、Microsoftの公式パッケージリポジトリでは、1.25.1-1が2026年5月23日に、1.25.2-1が同年7月23日に公開されています。x86_64版とaarch64版の両方で1.25.2-1を確認できます。

Azure Linux 3.0の公開されているunbound.specでも、1.25.1-1の変更履歴には複数の別のCVEが記載されていますが、CVE-2026-40691は含まれていません。ソースも上流の1.25.1を参照しており、公開spec上ではCVE-2026-40691専用のパッチ指定を確認できません。(GitHub)

したがって、運用上は次の基準で判断します。

Azure Linux 3.0では、unbound-1.25.2-1.azl3以上をインストールし、Unboundを再起動した時点で修正完了とする。

すでに1.25.2-1より新しいバージョンを使用している場合、MSRCに表示された1.25.1-1へ戻す必要はありません。MSRC側の掲載内容が後日更新される可能性もあるため、上流アドバイザリ、配布RPM、実際の導入バージョンを組み合わせて判断してください。

影響を受ける環境を判断する4つの条件

CVE-2026-40691は、脆弱なバージョンを導入しているだけで直ちに攻撃できるとは限りません。次の条件が重なった環境で、既知の攻撃経路が成立します。

確認項目	危険な状態
Unboundのバージョン	1.9.0以上、1.25.1以下
ビルド設定	`--enable-dnscrypt`を指定してビルド
Unboundの設定	`dnscrypt:`セクションを設定し、DNSCryptを有効化
ネットワーク	DNSCryptのTCP待ち受けポートへ攻撃者が接続可能

4項目がすべて該当する場合は、優先度を上げて更新してください。特に、インターネットや信頼できないネットワークからTCPポートへ到達できる場合や、1台のUnboundに多数のシステムが依存している場合は、サービス停止時の影響が大きくなります。(NVD)

Azure Linux標準RPMのビルド設定も確認する

公開されているAzure Linux 3.0のunbound.specには、次のようなビルドオプションが記載されています。

--with-pythonmodule
--with-pyunbound
--with-libevent

一方、--enable-dnscryptは公開spec内に見当たりません。公開specどおりにビルドされたRPMであれば、CVE-2026-40691の必須条件となるDNSCrypt対応ビルドではない可能性があります。これは公開specからの判断であり、実機確認の代わりにはなりません。独自に再ビルドしたRPM、ソースから導入したUnbound、コンテナ内のUnboundは別途確認が必要です。(GitHub)

Azure Linux 3.0でUnboundのバージョンを確認する

OSのバージョンを確認する

最初に、対象ホストがAzure Linux 3.0であることを確認します。

cat /etc/os-release

VERSION_IDなどの出力を確認し、Azure Linux 3.0のホストであることを特定します。

RPMパッケージのバージョンを確認する

次のコマンドで、インストール済みのUnboundを確認します。

rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' unbound

出力例は次のとおりです。

unbound-1.25.1-1.azl3.x86_64

この場合は更新が必要です。

修正版へ更新できている場合は、次のような結果になります。

unbound-1.25.2-1.azl3.x86_64

aarch64環境では、末尾が次のようになります。

unbound-1.25.2-1.azl3.aarch64

判定基準は次のとおりです。

確認結果	対応
1.25.1-1以下	1.25.2-1以上へ更新
1.25.2-1以上	バージョン上の修正条件を満たす
パッケージ未導入	コンテナやソース導入の有無を確認
RPM以外のバイナリが存在	`unbound -V`で個別確認

RPM管理外のUnboundを確認する

実行ファイルの場所を確認します。

command -v unbound

パスが表示された場合は、そのファイルがRPMで管理されているか確認します。

rpm -qf "$(command -v unbound)"

「どのパッケージにも所有されていない」という趣旨の結果が出た場合は、ソースビルドや手動配置の可能性があります。その場合、RPMを更新しても実際に使用されているUnboundは更新されません。

バイナリ自体の情報は、次のコマンドで確認します。

unbound -V

DNSCryptが有効か確認する

ビルドオプションを確認する

unbound -Vの出力から、DNSCrypt対応ビルドか確認します。

unbound -V 2>&1 | grep -F -- '--enable-dnscrypt'

--enable-dnscryptが表示される場合は、DNSCrypt対応でビルドされています。

何も表示されない場合は、公開されている攻撃条件の一つを満たしていない可能性があります。ただし、バージョン更新が不要になるわけではありません。将来の設定変更や独自バイナリへの置き換えを考慮し、修正版へそろえておくことが適切です。

DNSCrypt設定を検索する

Azure LinuxのRPMでは、公開spec上の既定設定ファイルが/etc/unbound/unbound.confに指定されています。まず、設定ディレクトリを検索します。(GitHub)

sudo grep -RniE \
  '^[[:space:]]*(dnscrypt:|dnscrypt-enable:|dnscrypt-port:)' \
  /etc/unbound

特に次の設定を確認します。

dnscrypt:
    dnscrypt-enable: yes

DNSCryptの公式ドキュメントでは、dnscrypt-enableの既定値はnoです。設定ファイルにDNSCrypt項目があっても、dnscrypt-enable: yesになっていなければ有効化されていない可能性があります。(Unbound Documentation)

サービス起動時に別の設定ファイルを指定していることもあるため、systemdの定義も確認します。

sudo systemctl cat unbound

ExecStartに-cオプションがある場合は、指定された設定ファイルも調査してください。

TCP待ち受けを確認する

Unboundが待ち受けているTCPポートを確認します。

sudo ss -lntp | grep unbound

DNSCrypt用ポートが表示された場合は、次の範囲も確認します。

インターネットから到達できるか
Azure NSGやホスト側ファイアウォールで制限されているか
接続元が必要なクライアントだけに限定されているか
ロードバランサーやポート転送を経由して公開されていないか

通常のDNSが53番ポートだからといって、53番ポートだけを確認してはいけません。DNSCryptは設定によって別のポートを使用できます。

Unboundを1.25.2-1以上へ更新する手順

Azure Linux 3.0では、パッケージ管理にTiny DNFのtdnfを使用します。Microsoftの案内でも、パッケージ情報の確認にはtdnf info、更新にはtdnf upgradeが示されています。(Microsoft Learn)

設定を検証してバックアップする

更新前に設定ファイルの文法を確認します。

sudo unbound-checkconf

エラーが表示された場合は、更新前に設定を修正してください。

続いて、設定ディレクトリをバックアップします。

sudo cp -a /etc/unbound \
  "/etc/unbound.backup-$(date +%Y%m%d%H%M%S)"

DNSCryptの秘密鍵などが含まれる場合があるため、バックアップの権限や保管場所にも注意が必要です。

リポジトリ情報を更新する

sudo tdnf clean all
sudo tdnf makecache
tdnf info unbound

tdnf info unboundの候補バージョンが1.25.1-1のままの場合は、社内ミラーやキャッシュが古い可能性があります。Microsoftの公式リポジトリにはx86_64版、aarch64版ともに1.25.2-1が公開されています。承認されたリポジトリの同期状況を確認し、出所不明のRPMを手動導入することは避けてください。(Microsoft Packages)

Unboundを更新する

sudo tdnf upgrade unbound -y

更新後に、RPMのバージョンを再確認します。

rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' unbound

次のバージョン以上になっていることを確認します。

unbound-1.25.2-1.azl3

更新後にサービスを再起動して動作確認する

RPMを更新しただけでは、更新前のバイナリで起動したUnboundプロセスが残っている可能性があります。サービスを再起動し、新しいバイナリを読み込ませます。

sudo unbound-checkconf
sudo systemctl restart unbound
sudo systemctl is-active unbound

is-activeの結果が次のようになれば、サービスは起動しています。

active

続いてログを確認します。

sudo journalctl -u unbound -n 100 --no-pager

次のような問題がないか確認してください。

設定ファイルの読み込みエラー
ポート競合
証明書や秘密鍵の読み込み失敗
権限エラー
起動直後のクラッシュ
systemdによる再起動の繰り返し

digが利用できる環境では、ローカルの名前解決も確認できます。

dig @127.0.0.1 example.com A

本番環境では、外部ドメインの確認だけでなく、社内向けゾーン、フォワーダー、DNSSEC検証、監視システムからのヘルスチェックも実施します。

冗長構成では、全台を同時に停止せず、ロードバランサーから1台ずつ切り離して更新すると、名前解決への影響を抑えられます。

コンテナ内のUnboundを見落とさない

Azure Linuxホスト上のRPMを更新しても、コンテナイメージ内のUnboundは更新されません。

Dockerなどを利用している場合は、対象コンテナ内で確認します。

docker exec <container-name> unbound -V

Kubernetes上では、Pod内のバイナリを確認します。

kubectl exec -n <namespace> <pod-name> -- unbound -V

コンテナで脆弱なバージョンを使用している場合は、稼働中のコンテナへ一時的にパッケージを追加するのではなく、次の流れで対応します。

Dockerfileやベースイメージを更新する
修正版を含むイメージを再ビルドする
イメージスキャンを実行する
新しいイメージをレジストリへ登録する
Deploymentなどを更新して再デプロイする
古いPodやコンテナが残っていないことを確認する

ホスト、コンテナ、サイドカー、独自ツールの同梱バイナリを分けて棚卸しすることが重要です。

すぐに更新できない場合の暫定対策

正式な対応は、1.25.2以上への更新、または上流が提供する修正パッチの適用です。更新まで時間が必要な場合は、既知の攻撃経路を一時的に閉じます。

DNSCryptを使用していない場合は無効化する

業務上DNSCryptが不要であれば、dnscrypt-enableをnoに設定し、Unboundを再起動します。

dnscrypt:
    dnscrypt-enable: no

設定変更前に、DNSCryptを利用するクライアントが存在しないことを確認してください。

接続元を制限する

DNSCrypt用のTCPポートをインターネットへ公開している場合は、Azure NSG、ファイアウォール、ロードバランサーなどで必要な接続元だけに制限します。

ネットワーク制限は、設定ミスや別経路からの到達を完全に防げるとは限りません。恒久対策ではなく、更新までの暫定措置として扱います。

ソースビルドには上流パッチを適用する

ソースからUnbound 1.25.1を構築しており、すぐに1.25.2へ上げられない場合、NLnet LabsはCVE-2026-40691向けの修正パッチを公開しています。

ただし、ディストリビューション管理下のRPMへ独自パッチを重ねると、次回更新時の追跡が難しくなります。Azure LinuxのRPM利用環境では、原則として公式の1.25.2-1以上へ更新してください。

対応時に失敗しやすいポイント

失敗例	問題点	正しい対応
MSRCの1.25.1-1だけを見て対応完了にする	上流では1.25.1が影響対象	1.25.2-1以上を基準にする
`rpm -q`だけで確認する	コンテナやソースビルドを見落とす	実行パスとコンテナ内も確認する
更新後に再起動しない	古いプロセスが動き続ける	Unboundを再起動してログを確認する
UDPの53番ポートだけ確認する	DNSCrypt over TCPの待ち受けを見落とす	TCPポートと設定値を確認する
DNSCryptを使っていないため更新しない	将来の設定変更や独自ビルドに対応できない	通常の保守枠で修正版へ更新する
社内ミラーに1.25.2がないまま作業する	古いRPMを再導入する可能性がある	ミラー同期後に候補版を確認する
ホストのRPMだけ更新する	コンテナイメージは修正されない	イメージを再ビルドして再デプロイする

CVE-2026-40691への対応を完了するためのチェックリスト

対応は、次の順序で進めます。

cat /etc/os-releaseでAzure Linux 3.0か確認する
rpm -q unboundでRPMの導入バージョンを確認する
command -v unboundでRPM管理外のバイナリがないか確認する
コンテナやPod内のUnboundも棚卸しする
unbound -VでDNSCrypt対応ビルドか確認する
設定ファイルでdnscrypt-enableと待ち受けポートを確認する
unbound-1.25.2-1.azl3以上へ更新する
Unboundを再起動する
パッケージ版、サービス状態、ログ、名前解決を確認する
適用日時、対象ホスト、適用版、確認結果を記録する

CVE-2026-40691は、DNSCrypt対応ビルドと設定の有効化が必要な条件付きの脆弱性です。一方で、条件に該当すれば、認証不要の単一クエリでDNSサービスを停止させられる可能性があります。

MSRCの1.25.1-1表記だけで判断せず、上流の修正境界とAzure Linux公式リポジトリを基準に、1.25.2-1以上への更新、サービス再起動、実通信の確認まで実施してください。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

CVE-2026-40691対策：Azure Linux 3.0のUnbound修正版と更新手順

CVE-2026-40691の概要

DNSCrypt over TCPでUnboundがクラッシュする仕組み

MSRCの1.25.1-1表記を修正版と断定しない

影響を受ける環境を判断する4つの条件

Azure Linux標準RPMのビルド設定も確認する

Azure Linux 3.0でUnboundのバージョンを確認する

OSのバージョンを確認する

RPMパッケージのバージョンを確認する

RPM管理外のUnboundを確認する

DNSCryptが有効か確認する

ビルドオプションを確認する

DNSCrypt設定を検索する

TCP待ち受けを確認する

Unboundを1.25.2-1以上へ更新する手順

設定を検証してバックアップする

リポジトリ情報を更新する

Unboundを更新する

更新後にサービスを再起動して動作確認する

コンテナ内のUnboundを見落とさない

すぐに更新できない場合の暫定対策

DNSCryptを使用していない場合は無効化する

接続元を制限する

ソースビルドには上流パッチを適用する

対応時に失敗しやすいポイント

CVE-2026-40691への対応を完了するためのチェックリスト

この記事を書いた人

コメント

コメントするコメントをキャンセル

CVE-2026-40691対策：Azure Linux 3.0のUnbound修正版と更新手順

CVE-2026-40691の概要

DNSCrypt over TCPでUnboundがクラッシュする仕組み

MSRCの1.25.1-1表記を修正版と断定しない

影響を受ける環境を判断する4つの条件

Azure Linux標準RPMのビルド設定も確認する

Azure Linux 3.0でUnboundのバージョンを確認する

OSのバージョンを確認する

RPMパッケージのバージョンを確認する

RPM管理外のUnboundを確認する

DNSCryptが有効か確認する

ビルドオプションを確認する

DNSCrypt設定を検索する

TCP待ち受けを確認する

Unboundを1.25.2-1以上へ更新する手順

設定を検証してバックアップする

リポジトリ情報を更新する

Unboundを更新する

更新後にサービスを再起動して動作確認する

コンテナ内のUnboundを見落とさない

すぐに更新できない場合の暫定対策

DNSCryptを使用していない場合は無効化する

接続元を制限する

ソースビルドには上流パッチを適用する

対応時に失敗しやすいポイント

CVE-2026-40691への対応を完了するためのチェックリスト

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル