Unbound 1.25.1 公開｜CVE-2026-42960 キャッシュポイズンの仕組みと対処

はじめに

DNS リゾルバへのキャッシュポイズン攻撃は、古典的でありながら継続的に新しい亜種が報告されている領域です。2025 年 10 月に Unbound で公開された CVE-2025-11411 は権威セクションに紛れ込んだ NS RRSet を介したキャッシュ汚染が論点でしたが、その補完修正として 2026 年 5 月 20 日に CVE-2026-42960 が公開されました。今回は NS 以外のレコード（MX など）を起点とした類似のキャッシュ汚染が論点となっており、Unbound 1.25.0 までが影響を受けます。

注目すべきは CVSS スコアの評価が割れている点です。NVD は CVSS v3.1 で 10.0 Critical と評価している一方、ベンダーである NLnet Labs（CNA）は CVSS v4.0 で 5.7 Medium と評価しており、運用判断の優先度付けに迷いが生じやすい状況です。本記事では、この脆弱性の技術的な仕組み、評価差の背景、そして実務的な対処手順を整理します。

CVE-2026-42960 の概要

CVE-2026-42960 は、Unbound 1.25.0 までのバージョンに存在するキャッシュポイズンの脆弱性です。攻撃者が偽装パケットやフラグメンテーション攻撃で応答を注入できる条件下において、Unbound のキャッシュに任意のアドレスレコードを書き込める可能性があります。CWE 分類は CWE-349（信頼できるデータ受け入れ時の信頼できない無関係なデータの受け入れ）です。

参考: NLnet Labs 公式アドバイザリ Summary
“Promiscuous RRSets that complement DNS replies in the authority section can be used to trick Unbound to cache such records. If an adversary is able to attach such records in a reply (i.e., spoofed packet, fragmentation attack) he would be able to poison Unbound’s cache.”
（DNS 応答の権威セクションを補完するプロミスキャス（曖昧）な RRSet を悪用することで、Unbound にそのレコードをキャッシュさせることが可能となる。攻撃者が応答にそのようなレコードを添付できる場合（偽装パケットやフラグメンテーション攻撃など）、Unbound のキャッシュを汚染できる可能性がある。）
https://www.nlnetlabs.nl/downloads/unbound/CVE-2026-42960.txt

脆弱性の位置付け（CVE-2025-11411 の補完修正）

本脆弱性は、2025 年 10 月に公開された CVE-2025-11411 の補完修正として位置付けられています。アドバイザリ本文にも “This is a complement fix to CVE-2025-11411.” と明記されており、前回の修正で対処しきれなかった攻撃面を塞ぐためのリリースです。

両者の関係を整理すると次のようになります。

前回の修正では「権威セクションに紛れ込んだ未要求の NS RRSet」をスクラブ（除外）する処理が追加されました。しかし、その後の検証で、NS 以外の RRSet（例えば MX レコード）に付随する追加セクションのアドレスレコードを介して同様のキャッシュ汚染が成立することが判明し、今回の補完修正となった経緯です。

攻撃シナリオ（promiscuous RRSet と additional セクションの悪用）

DNS 応答パケットは大きく分けて 4 つのセクション（Question / Answer / Authority / Additional）で構成されています。今回の攻撃の鍵となるのは、権威（Authority）セクションに紛れ込ませた NS 以外の RRSet と、追加（Additional）セクションに添付されたそのアドレスレコードの組み合わせです。

具体的な攻撃の流れは次のとおりです。

1. 攻撃者は、被害となる Unbound に対する DNS 応答を偽装またはフラグメンテーション攻撃で注入する
2. その応答の権威セクションに、本来要求されていない MX レコード（あるいは他の非 NS 型 RRSet）を含める
3. さらに追加セクションに、それらの RRSet に対応するアドレスレコード（A / AAAA）を添付する
4. Unbound が権威 RRSet を「委任ポイント内のデータ」として十分に信頼している場合、追加セクションのアドレスレコードまでキャッシュしてしまう

結果として、攻撃者が指定した IP アドレスが特定のホスト名に紐付けてキャッシュされ、その後その名前に対する問い合わせが攻撃者の制御するサーバーへ誘導される可能性があります。

参考: 攻撃手法の詳細（NLnet Labs 公式アドバイザリ）
“A malicious actor can exploit the possible poisonous effect by injecting RRSets other than NS that are also accompanied by address records in a reply, for example MX. This could be achieved by trying to spoof a reply packet or fragmentation attacks.”
（悪意ある攻撃者は、応答にアドレスレコードを伴う NS 以外の RRSet（例えば MX）を注入することで、このキャッシュ汚染を悪用できる。これは応答パケットの偽装やフラグメンテーション攻撃によって達成され得る。）
https://www.nlnetlabs.nl/downloads/unbound/CVE-2026-42960.txt

想定される影響（キャッシュ汚染 → 通信のリダイレクト）

キャッシュポイズンが成立した場合、想定される影響は次の通りです。

通信のリダイレクト

本来到達すべきサーバーとは異なる IP アドレスに DNS 解決結果が誘導され、後続の通信が攻撃者の制御するシステムへ向かう可能性

メールフローの操作

MX レコードを起点とした攻撃の場合、メールの宛先サーバーが汚染され、機密情報の流出経路となり得る。

下流サービスへの波及

汚染された DNS リゾルバを利用する全クライアントが影響を受けるため、組織内部での影響範囲が広がりやすい。

JVN では想定される影響を「機密性への影響なし／完全性は全面的な書き換えの可能性／可用性は完全停止の可能性／他ソフトウェアへの波及あり」と整理しています。機密性そのものは直接攻撃対象ではないものの、完全性（Integrity）と可用性（Availability）が大きく損なわれる点が、この脆弱性の重大さを表しています。

なお、攻撃の実行には「Unbound への応答を偽装またはフラグメンテーション攻撃で注入できる位置にあること」が前提となります。インターネット上の任意のノードから単純な HTTP リクエストで成立する類のものではない点は、後述する CVSS 評価差の章であわせて整理します。

CVSS スコアの読み解き（独自視点）

CVE-2026-42960 を運用判断の対象として扱う上で、最初に整理しておきたいのが CVSS スコアの評価差です。NVD と CNA（ベンダーである NLnet Labs）で同じ脆弱性に対して大きく異なるスコアが付与されており、それぞれの算出根拠を理解しないと優先度判断を誤る可能性があります。

NVD: CVSS v3.1 で 10.0 Critical

NVD（NIST）は CVSS v3.1 で評価し、ベーススコアは 10.0（Critical） と算出しています。ベクトル文字列は次のとおりです。

参考: NVD による CVSS v3.1 評価（NVD）
“CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:H”
（攻撃元区分: ネットワーク／攻撃条件の複雑さ: 低／必要権限: なし／ユーザー関与: なし／スコープ: 変更あり／機密性: 影響なし／完全性: 高／可用性: 高）
https://nvd.nist.gov/vuln/detail/CVE-2026-42960

ポイントとなるメトリックは次の 2 点です。

AV:N（Attack Vector = Network）

インターネット越しに攻撃可能と評価

S:C（Scope = Changed）

脆弱な Unbound プロセスの境界を越えて影響が及ぶ（汚染されたキャッシュを利用する下流クライアント全体に波及する）と評価

特に Scope = Changed が効くことで、完全性（I:H）と可用性（A:H）の影響が大きくスコアに反映され、結果として満点に近い 10.0 となっています。「リゾルバの DNS キャッシュが汚染されると、それを利用するすべての配下クライアントが影響を受ける」という現実的な波及範囲が、Scope = Changed という形でスコアに織り込まれている構造です。

CNA（NLnet Labs）: CVSS v4.0 で 5.7 Medium

一方、CNA である NLnet Labs は CVSS v4.0 で評価しており、ベーススコアは 5.7（Medium） となっています。ベクトル文字列は次のとおりです。

参考: CNA（NLnet Labs）による CVSS v4.0 評価（NVD）
“CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:H/E:P/U:Amber”
（攻撃元区分: 隣接ネットワーク／攻撃条件の複雑さ: 低／攻撃要件: 成立条件あり／必要権限: なし／ユーザー関与: なし／脆弱なシステムへの機密性: 影響なし／脆弱なシステムへの完全性: 高／脆弱なシステムへの可用性: 影響なし／後続システムへの機密性: 影響なし／後続システムへの完全性: 高／後続システムへの可用性: 高／悪用済み: PoC あり）
https://nvd.nist.gov/vuln/detail/CVE-2026-42960

NVD 評価と比べた違いは次の 3 点です。

AV:A（Attack Vector = Adjacent）

隣接ネットワーク（同一サブネット、または応答パケットを偽装・割り込みできる位置）からの攻撃が前提

AT:P（Attack Requirements = Present）

攻撃が成立するには特定の条件（偽装パケットを通せる経路、フラグメンテーション攻撃の成立など）が必要

CVSS v4.0 では Scope の概念が廃止

代わりに「脆弱なシステム」と「後続システム」を分けて評価する方式

つまり NLnet Labs は、「攻撃には特定のネットワーク位置や条件が必要であり、任意のインターネット越しのクライアントから即座に成立するものではない」という前提に立って評価しており、その結果がスコアの低さに表れています。

なぜ評価が分かれたのか

両者のスコア差は単純な誤差ではなく、評価の前提条件と CVSS のバージョン差に由来する構造的な違いです。整理すると次のようになります。

NVD の評価は「最悪のケースを想定し、波及範囲を Scope で大きく拡張する」考え方であり、CNA の評価は「実際の攻撃成立条件を厳密に織り込む」考え方と整理できます。どちらが正解というものではなく、評価の視点が異なるものです。

運用者としてどちらを基準にすべきか

実務的には、次のような考え方が現実的です。

緊急度判断の起点としては NVD の 10.0 Critical を採用する

社内のセキュリティ規程やパッチマネジメントポリシーで CVSS スコアが閾値として使われている場合、NVD のスコアに従うのが運用上の整合性を取りやすい。

実際の攻撃成立条件は CNA の評価を参考にする

自社の Unbound がインターネット直接公開なのか、内部 LAN 専用なのか、上位 DNS との経路に偽装パケットが混入し得るかを評価する材料となる。

DNSSEC 検証の有無による緩和度合いも個別に勘案する

アドバイザリは DNSSEC 検証時の挙動には踏み込んでいないが、DNSSEC で署名されているゾーンであれば、汚染されたデータが検証失敗で破棄される可能性が高まる。

つまり、「優先度は高く扱うが、自社環境の実際のリスク像は CNA 評価とネットワーク構成から見積もる」という二段構えが、評価差を実務に落とし込む際の現実的なアプローチです。

影響範囲と修正版

影響を受けるバージョン

CVE-2026-42960 の影響を受けるのは、Unbound 1.25.0 以前のすべてのバージョンです。

参考: 影響を受ける製品（NLnet Labs 公式アドバイザリ）
“Unbound up to and including version 1.25.0.”
（Unbound バージョン 1.25.0 まで（同バージョンを含む）が影響を受ける。）
https://www.nlnetlabs.nl/downloads/unbound/CVE-2026-42960.txt

NVD の CPE 設定でも cpe:2.3:a:nlnetlabs:unbound:*:*:*:*:*:*:*:* で 1.25.1 未満が影響対象として登録されています。CVE-2025-11411 の修正である 1.24.1 / 1.24.2 を適用済みの環境でも、本 CVE には影響を受ける点に注意が必要です。

修正版 Unbound 1.25.1

修正版として Unbound 1.25.1 がリリースされています。本バージョンには、追加セクションのアドレスレコードについて「権威 NS レコードと明示的に関連しないもの」を無視する修正が含まれており、今回のキャッシュポイズンを緩和します。

参考: 修正版の挙動（NLnet Labs 公式アドバイザリ）
“Unbound 1.25.1 includes a fix that disregards address records from the additional section if they are not relevant to authority NS records, mitigating the possible poison effect.”
（Unbound 1.25.1 には、権威 NS レコードに関連しない追加セクションのアドレスレコードを無視する修正が含まれており、キャッシュ汚染の影響を緩和する。）
https://www.nlnetlabs.nl/downloads/unbound/CVE-2026-42960.txt

修正版の入手方法は、ソースからのアップグレードと、1.25.0 への個別パッチ適用の 2 通りが公式に案内されています。具体的な手順は次の章で詳しく扱います。

EOL / ベンダー配布版利用時の留意点

実運用では Unbound をディストリビューションのパッケージとして導入しているケースが多いと考えられます。RHEL、Ubuntu、Debian、FreeBSD ports など、それぞれのディストリビューションで配布されている Unbound パッケージのバージョン番号は upstream の番号と完全には一致せず、セキュリティ修正がパッケージ側にバックポートされる形で配布されることが一般的です。

そのため、ベンダー配布版を利用している場合は次の順序で確認することが推奨されます。

1. unbound -V で実バージョン（upstream バージョン）を確認する。
2. 1.25.1 未満であれば影響を受ける可能性があるため、ディストリビューション側のセキュリティアドバイザリを確認する（RHSA、USN、DSA など）
3. パッケージマネージャー（dnf updateinfo、apt list --upgradable 等）で対応済みパッケージが提供されているかを確認する。
4. 対応済みであればパッケージ更新、未対応であればソースからのビルドや個別パッチ適用を検討する。

なお、同じ DNS リゾルバの分野では BIND 9 でも 2026 年 5 月に複数の脆弱性（CVE-2026-5946 / 5947 / 5950）が同時公開されており、マトリクス形式での影響バージョン確認手順は、関連記事『BIND 9 脆弱性マトリクスと CVE 3 件の読み解き方』も参照ください。複数の DNS リゾルバを併用している環境では、それぞれの脆弱性情報を体系的に管理する習慣が役立ちます。

対処手順（移行とパッチ適用）

CVE-2026-42960 への対処は、Unbound 1.25.1 への移行が基本となります。NLnet Labs 公式アドバイザリでは、修正版へのアップグレードと、1.25.0 への個別パッチ適用の 2 通りの方法が案内されています。

参考: 対処方法（NLnet Labs 公式アドバイザリ）
“Unbound 1.25.1 is released with the patch”
（Unbound 1.25.1 がパッチ込みでリリースされている。）
https://www.nlnetlabs.nl/downloads/unbound/CVE-2026-42960.txt

本章では、ソースからのアップグレード、個別パッチ適用、ディストリビューションパッケージでの対応のそれぞれを整理し、移行前後の動作確認手順までを順に解説します。

方法 1: Unbound 1.25.1 へのアップグレード

最も推奨される対応は、修正版 Unbound 1.25.1 への移行です。ソースから導入している環境では、公式の配布アーカイブを取得して再ビルドする流れになります。

# 公式の配布アーカイブを取得
wget https://nlnetlabs.nl/downloads/unbound/unbound-1.25.1.tar.gz

# 展開
tar zxvf unbound-1.25.1.tar.gz
cd unbound-1.25.1

# ビルドとインストール（既存環境の configure オプションを継承するのが基本）
./configure
make
sudo make install

./configure のオプションは、既存環境で利用しているもの（例: --with-libevent、--enable-subnet、--with-ssl など）を引き継ぐ形を推奨します。既存のビルド構成は unbound -V で確認できます。

参考: unbound -V でビルドオプションを確認（NLnet Labs Unbound man page）
“-V Show the version number and build options, and exit.”
（-V オプションでバージョン番号とビルドオプションを表示し終了する。）
https://nlnetlabs.nl/documentation/unbound/unbound/

方法 2: 1.25.0 へのパッチ適用（公式 patch_CVE-2026-42960.diff）

何らかの理由で 1.25.0 を継続利用する必要がある環境向けに、NLnet Labs は公式パッチも公開しています。このパッチは Unbound 1.25.0 上でテスト済みと明記されています。

# 公式パッチの取得
wget https://nlnetlabs.nl/downloads/unbound/patch_CVE-2026-42960.diff

# Unbound のソースディレクトリでパッチを適用
cd unbound-1.25.0
patch -p1 < ../patch_CVE-2026-42960.diff

# 再ビルドとインストール
make
sudo make install

参考: パッチ適用手順（NLnet Labs 公式アドバイザリ）
“Apply the patch on the Unbound source directory with: patch -p1 < patch_CVE-2026-42960.diff then run ‘make install’ to install Unbound. The patch is tested to work on Unbound 1.25.0.”
（Unbound のソースディレクトリで patch -p1 < patch_CVE-2026-42960.diff を実行し、make install で導入する。本パッチは Unbound 1.25.0 上でテスト済みである。）
https://www.nlnetlabs.nl/downloads/unbound/CVE-2026-42960.txt

なお、1.25.0 以前のバージョンを利用している場合、まず CVE-2025-11411 を含む過去の修正もまとめて取り込む観点で、個別パッチではなく 1.25.1 への直接移行が推奨されます。

ディストリビューションパッケージでの対応

実運用環境ではパッケージマネージャー経由で Unbound を導入しているケースが多いと考えられます。その場合は、ディストリビューションのセキュリティアドバイザリでバックポート済みパッケージが配布されているかを確認し、それぞれの環境に合った方法で更新するのが基本です。

# Red Hat / Rocky / AlmaLinux 系
sudo dnf check-update unbound
sudo dnf update unbound

# Debian / Ubuntu 系
sudo apt update
sudo apt list --upgradable | grep unbound
sudo apt install --only-upgrade unbound

# FreeBSD（base 同梱版）
sudo freebsd-update fetch
sudo freebsd-update install

ベンダー配布版のバージョン番号は upstream の番号と完全には一致しないため、「1.25.1 にバージョンが上がっていないから未対応」と判断しないことが重要です。パッケージ側でバックポート対応が行われている場合、changelog にセキュリティ修正の記載があるかを併せて確認するのが確実です。

バージョン確認コマンド

移行前後で運用中の Unbound のバージョンと稼働状態を確認するには、次のコマンドを利用します。

# バイナリのバージョンとビルドオプションを表示
unbound -V

# 稼働中の Unbound の状態確認（unbound-control 設定が必要）
unbound-control status

# ディストリビューションパッケージのバージョン確認
rpm -q unbound          # Red Hat 系
dpkg -l | grep unbound  # Debian / Ubuntu 系

unbound -V の出力には、バージョン番号に加えて TLS バックエンド（OpenSSL / LibreSSL）や DNSSEC、DoT、DoH、ECS などのビルド時オプションが含まれます。移行後にも同じコマンドを実行し、ビルドオプションに想定外の変化がないかを確認するのが安全側の運用です。

unbound-control status は、稼働中の Unbound に対して状態を問い合わせるコマンドで、終了コードでも状態を判定できます。

参考: unbound-control status の挙動（NLnet Labs Unbound man page）
“status Display server status. Exit code 3 if not running (the connection to the port is refused), 1 on error, 0 if running.”
（status は Unbound のサーバー状態を表示する。稼働していない場合は終了コード 3、エラー時は 1、稼働中は 0 となる。）
https://www.nlnetlabs.nl/documentation/unbound/unbound-control/

なお、unbound-control を利用するには、unbound.conf の remote-control セクションで有効化し、unbound-control-setup で証明書を生成しておく必要があります。

アップグレード後の動作確認観点

修正版への移行後は、設定ファイルの互換性と稼働状態、そして名前解決の動作を併せて確認するのが安全です。最低限押さえておきたい観点は次のとおりです。

1. 設定ファイルの構文チェック

unbound-checkconf で unbound.conf の構文と整合性を検査します。unbound を再起動する前のセーフティネットとして活用できます。

# unbound.conf の構文チェック
sudo unbound-checkconf

# 設定ファイルパスを明示する場合
sudo unbound-checkconf /etc/unbound/unbound.conf

参考: unbound-checkconf の利用推奨（NLnet Labs Unbound Documentation）
“Unbound comes with the unbound-checkconf(8) tool. This tool allows you to check the config file for errors before starting Unbound.”
（Unbound には unbound-checkconf(8) ツールが付属しており、Unbound 起動前に設定ファイルのエラーを確認できる。）
https://unbound.docs.nlnetlabs.nl/en/latest/getting-started/configuration.html

2. プロセスの稼働確認

systemd 配下で稼働している環境では、systemctl でサービスの状態を確認します。

# プロセスの状態確認
sudo systemctl status unbound

3. ログでの異常検知

アップグレード直後はログを注視し、error や warning が出ていないかを確認するのが望ましい運用です。journald 配下では次のように確認できます。

# unbound のログを直近 100 行表示
sudo journalctl -u unbound -n 100 --no-pager

# unbound のログをリアルタイム監視
sudo journalctl -u unbound -f

4. 名前解決の動作確認

実際の名前解決と DNSSEC 検証が想定通り行えるかを最終確認します。Unbound 付属の unbound-host を使うと、Unbound 自身のロジックで名前解決と DNSSEC 検証状態を確認できます。

# 通常の名前解決確認
dig @127.0.0.1 example.com A +short

# DNSSEC 検証が機能していることの確認（AD フラグが立つかを確認）
dig @127.0.0.1 example.com A +dnssec

# unbound-host による検証込みのクエリ
unbound-host -v example.com

参考: unbound-host による DNSSEC 検証確認（NLnet Labs Unbound Documentation）
“With the -v option it displays validation status: secure, insecure, bogus (security failure).”
（-v オプションを付けると、検証ステータス（secure / insecure / bogus）を表示する。）
https://nlnetlabs.nl/documentation/unbound/unbound-host/

5. キャッシュのフラッシュ

CVE-2026-42960 はキャッシュ汚染が論点であるため、移行後に既存キャッシュをそのまま継承するのは安全側の判断とは言えません。サービス再起動でキャッシュは初期化されますが、unbound-control reload を明示的に実行することでも config を再読み込みしつつキャッシュをクリアできます。

# 設定ファイル再読み込み（キャッシュフラッシュを伴う）
sudo unbound-control reload

# 特定ドメインのキャッシュを破棄
sudo unbound-control flush example.com

# 特定ゾーン配下のキャッシュをまとめて破棄
sudo unbound-control flush_zone example.com

設定ファイルの非互換変更はマイナーバージョン跨ぎで入ることが多いものの、パッチリリース（1.25.0 → 1.25.1）であれば原則として unbound.conf の変更は不要です。それでも、リリースノートに新規オプションや非推奨オプションが記載されていることがあるため、移行前に該当バージョンのリリースノートを一度確認しておくと事故を減らせます。

運用視点で押さえておきたいポイント

ここまで CVE-2026-42960 の技術的な仕組みと対処手順を整理してきました。最後に、この脆弱性を通じて見えてくる運用上の考え方を 3 点まとめます。1 回限りのパッチ適用で終わりにするのではなく、DNS リゾルバのセキュリティを継続的に管理できる体制を整えることが、安定した運用の基盤になります。

DNSSEC 検証の活用

CVE-2026-42960 の攻撃が成立するのは、キャッシュに書き込まれた偽のアドレスレコードを後続のクエリが信頼するという流れによります。この信頼の連鎖を断ち切る手段の一つとして、DNSSEC（DNS Security Extensions）の検証が有効です。

DNSSEC で署名されているゾーンのレコードは、Unbound が電子署名（RRSIG）を検証した上でキャッシュします。署名が正しくないデータは bogus として扱われ、クライアントには返されません。そのため、DNSSEC 署名済みのゾーンに対しては、攻撃者が注入した偽のアドレスレコードが署名検証に失敗し、キャッシュへの書き込みを防ぐ方向に働きます。

ただし、DNSSEC 署名されていないゾーンには効果が及ばない点と、DNSSEC そのものの設定ミスがサービス停止につながるリスクがある点には留意が必要です。導入済みの場合は unbound-host -v で常に secure が返るかを定期確認する運用が推奨されます。

なお、今回の脆弱性は「DNSSEC で保護されていないデータ」を対象とすることが論点の一つです。DNSSEC 検証を有効化すること自体が本系統の攻撃に対する根本的な緩和策という位置付けになります。

フラグメンテーション攻撃への理解

CVE-2026-42960 の攻撃手段として「偽装パケット（spoofed packet）」と「フラグメンテーション攻撃（fragmentation attack）」の 2 つが挙げられています。このうちフラグメンテーション攻撃は、近年の DNS キャッシュポイズン研究において繰り返し取り上げられているベクターです。

フラグメンテーション攻撃とは、UDP パケットが途中のルーターやファイアウォールで分割（フラグメント）される性質を悪用し、後半フラグメントに攻撃者が制御するデータを差し込むことで、リゾルバが受け取る DNS 応答を汚染しようとする手法です。この手法が成立しやすいのは、DNS の UDP データが大きくなりやすいケース（DNSSEC 応答、ECS 付き応答など）です。

運用上の対策として参考になる観点は次のとおりです。

EDNS バッファサイズの調整

過大な UDP 応答サイズを抑制することでフラグメンテーションが発生しにくくなる（edns-buffer-size オプション）

インフラレベルでのフラグメントフィルタリング

ファイアウォールや DNS プロキシ側で不正なフラグメントを遮断する構成

DoT / DoH の利用

TCP ベースの DNS-over-TLS や DNS-over-HTTPS はフラグメンテーション攻撃の影響を受けにくい（ただし、権威サーバーとの通信ではなく stub → Unbound 間の通信に限る）

これらは今回の CVE への直接的なパッチに代わるものではありませんが、類似の攻撃手法への耐性を高める多層防御として有効です。

脆弱性情報の一次情報源（NLnet Labs Security Advisories）

今回の CVE は JVN（Japan Vulnerability Notes）を通じて日本語でも確認できましたが、正確な影響範囲・修正バージョン・パッチの入手先を確認するには、NLnet Labs の一次情報源を参照するのが確実です。二次情報には、公開タイミングや詳細の精度にばらつきが生じやすいため、判断の材料は一次情報で固めることが推奨されます。

特に次のページは、Unbound を運用する担当者がブックマークしておくと役立ちます。

• NLnet Labs セキュリティアドバイザリ一覧: https://www.nlnetlabs.nl/projects/unbound/security-advisories/
• CVE-2026-42960 公式アドバイザリ: https://www.nlnetlabs.nl/downloads/unbound/CVE-2026-42960.txt
• Unbound リリースノート（GitHub）: https://github.com/NLnetLabs/unbound/releases

なお、前回の CVE-2025-11411 が「部分的な修正」にとどまり、今回の CVE-2026-42960 で補完修正が必要になった経緯は、DNS のセキュリティ修正が段階的に積み上がる性質をよく示しています。1 回の修正で完結したと判断せず、後継の CVE が公開されていないかを定期的に追う姿勢が、DNS リゾルバ運用においては特に重要です。

まとめ

本記事では、NLnet Labs Unbound の CVE-2026-42960（CVSS v3.1 10.0 Critical / CVSS v4.0 5.7 Medium）について、技術的な仕組みから実務的な対処手順まで整理しました。

• CVE-2026-42960 は 2025 年 10 月の CVE-2025-11411 への補完修正で、NS 以外の RRSet（MX 等）を介したキャッシュポイズンが論点
• NVD は CVSS v3.1 で 10.0 Critical、CNA（NLnet Labs）は CVSS v4.0 で 5.7 Medium と評価が分かれており、攻撃条件と評価バージョンの違いが背景
• 影響を受けるのは Unbound 1.25.0 以下で、修正版は Unbound 1.25.1
• 対処は 1.25.1 へのアップグレードが基本。1.25.0 への個別パッチ（patch_CVE-2026-42960.diff）も公式に提供されている。
• ベンダー配布パッケージは upstream バージョンと一致しないため、ディストリビューション側のセキュリティアドバイザリと合わせて確認が必要
• DNSSEC 検証の有効化が本系統の攻撃に対する根本的な緩和策として有効
• NLnet Labs セキュリティアドバイザリを一次情報源として定期的に確認する運用習慣が重要

以上、最後までお読みいただきありがとうございました。