Unbound の既定設定でDNSキャッシュポイズニングが成立（so-reuseport がスレッド識別子になる・1.25.2 で修正）

Critical（CVSS 9.3）に分類されるNLnet Labs Unboundの脆弱性です。DNS キャッシュリゾルバ Unbound の 1.4.22 から 1.25.1 まで（両端を含む）に、DNS キャッシュポイズニングを成立させる欠陥がある。UDP の送信元ポートはランダム化されて DNS トランザクションのエントロピー源（秘密の値）として働くことが前提だが、その秘密が負荷分散の副作用で漏れる、という構造の問題である。Unbound は起動時に利用可能な UDP 送信元ポート空間をほぼ等分の互いに素な部分集合へ無作為に分割し、各部分集合をワーカースレッド1つに割り当てる。問い合わせが届くと、カーネルの SO_REUSEPORT による負荷分散が、その問い合わせを特定のスレッドのソケットへ決定論的に割り当てる。そして解決の過程で外向きに出る問い合わせは、担当スレッドに割り当てられた部分集合の中からしか送信元ポートを選ばない。部分集合はスレッド間で重ならないので、**権威サーバ側で観測できる外向きクエリの送信元ポートが、そのまま「どのワーカースレッドが処理したか」の指標になる**。攻撃者は（送信元IPを固定したうえで）入ってくる UDP 送信元ポートとワーカースレッドの対応関係を取得でき、スレッドあたりのランダムポート母数を実質的に減らしてキャッシュポイズニングを成立させられる。この条件は SO_REUSEPORT が有効なときに満たされ、Unbound では `so-reuseport: yes` が**既定**であるため、既定構成が対象となる。CWE は CWE-349。CVSS は評価元で大きく割れており、NVD（Primary）が CVSS 3.1 で 9.3 Critical（AV:A/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:H）、開発元の NLnet Labs（sep@nlnetlabs.nl）が CVSS 4.0 で 5.7 Medium（AV:A/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:H/E:P）である。**両者に共通するのは AV:A（隣接ネットワーク）**で、インターネットの任意の場所から誰でも撃てるという評価にはなっていない。修正版は 1.25.2。NVD の vulnStatus は Analyzed、最終更新は 2026年7月24日。2026年8月17日時点で CISA KEV カタログには収載されていない（カタログ版 2026.08.14 で確認）。

まず数字の読み方を決めておく。9.3（NVD・CVSS 3.1）と 5.7（開発元・CVSS 4.0）は4点近く離れているが、これは片方が間違っているのではなく、評価軸とバージョンが違う。両者が一致しているのは攻撃元が AV:A（隣接ネットワーク）である点で、ここが対応の優先度を決める鍵になる。つまり「インターネットに面した権威サーバ」ではなく、**そのリゾルバに問い合わせを投げられる位置に攻撃者がいるか**が問題になる。判定手順は3つ。(1) 稼働中の Unbound のバージョンを確認する（`unbound -V`）。1.4.22 以上 1.25.1 以下なら対象である。バージョンの下限が 1.4.22 と古いので、長く動かしている社内リゾルバはほぼ全部が範囲に入ると考えたほうがよい。(2) `so-reuseport` の設定値を確認する（`unbound-checkconf -o so-reuseport` または unbound.conf）。**既定が yes なので、明示的に no にしていなければ有効**である。(3) そのリゾルバに問い合わせできる主体を洗い出す。社内のクライアント全台からアクセスできる共有リゾルバ、マルチテナントのVPCやコンテナネットワークで共有しているリゾルバ、ゲスト用Wi-Fiと同じセグメントに置いてあるリゾルバは、攻撃者が隣接に入りうるので優先度が高い。逆に1台のホスト内から localhost 経由でしか引かれないリゾルバなら、優先度は下がる。対処は 1.25.2 以上への更新である。ディストリのパッケージを使っているなら、そのディストリが 1.25.2 相当へ更新するか修正をバックポートするので、自分のディストリのセキュリティトラッカーで当該CVEの状態を確認してから更新する。すぐに更新できない場合の緩和として、設定で `so-reuseport: no` にすると本欠陥の成立条件（負荷分散の結果が送信元ポートに依存して露出すること）が崩れる。ただしこれは SO_REUSEPORT による性能上の利点を捨てる変更なので、問い合わせ量の多いリゾルバでは性能低下を測ってから決めること。恒常的な防御としては、DNSSEC 検証を有効にしておくこと（キャッシュポイズニングで差し込まれた偽の応答は署名検証で落とせるため、この種の欠陥に対する最も効く多層防御である）と、リゾルバを引ける範囲を `access-control` で必要なセグメントだけに絞ることが挙げられる。なお NVD 側が S:C（スコープ変更あり）と評価しているのは、汚染されたキャッシュの影響がリゾルバ自身ではなくそれを信じるクライアント側に及ぶためで、被害の広がり方を考えるうえではこちらの見方のほうが実態に近い。

NLnet Labs Unbound を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報（https://nvd.nist.gov/vuln/detail/CVE-2026-50252）で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド／OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。