DNSの定番ソフト「BIND」に偽の応答を信じ込まされる脆弱性 CVE-2026-13321、9.20.26／9.21.24へ更新を

インターネットの「住所案内」を担う代表的なソフト「BIND（バインド）」に、攻撃者が用意した偽の応答を「正しいものだ」と信じ込まされてしまう脆弱性（ソフトの弱点）が、2026年7月22日に公表されました。開発元のISC（Internet Systems Consortium）が2件まとめて告知し、いずれも修正版が同時に公開されています。

特に注意したいのが、10点満点で8.6と評価されたCVE-2026-13321です。悪用されると、攻撃者が特定のサイトについて「そんな住所は存在しない」といった偽の答えをBINDのキャッシュに埋め込み、そのサーバーを使う利用者全員を目的のサイトにつながらなくできる可能性があります。厄介なのは、この偽の答えが電子署名の検証を通り抜け、「本物と確認済み」の顔をして混ざり込む点です。もう1件のCVE-2026-13204（7.5）は、細工した問い合わせでBINDそのものを異常終了させ、名前解決を止められる弱点です。

いずれも古いバージョンが対象で、最新版に更新すれば防げます。今のところ実際に悪用されたという報告はありません。この記事では、自分のサーバーが対象になるのか、どのバージョンに上げればよいのか、今すぐ何をすればよいのかを、専門知識がなくても分かるように整理します。

そもそも「BIND」とDNSとは何か

私たちが「example.com」のような文字の住所（ドメイン名）を入力すると、コンピュータはそれを「203.0.113.10」のような数字の住所（IPアドレス）に変換してから通信します。この変換の仕組みをDNS（ドメイン名システム）と呼び、インターネットの「住所案内所」にあたります。ここが止まったり、間違った住所を返したりすると、メールもWebも一斉につながらなくなります。

BINDは、そのDNSを動かすソフトの中で最も古くから使われ、世界で最も広く普及している定番です。企業の社内ネットワーク、プロバイダ、クラウド事業者、官公庁など、あらゆる場所でインターネットの土台として使われています。名前は知らなくても、多くの人が知らないうちにBINDの上で通信しているというのが実情です。だからこそ、DNSの家庭用ルータ向けソフト「dnsmasq」の弱点や、Java向け通信部品「Netty」のDNS弱点と同じく、BINDの脆弱性も影響範囲が広くなりやすいのです。

今回の弱点を理解するうえで、もうひとつ大事な仕組みがDNSSECです。これは、DNSが返した答えが途中ですり替えられていないかを電子署名で確かめる、いわば「住所案内に公印を押す」仕組みです。今回の2件は、どちらもこのDNSSECの検証処理にひそんでいた欠陥でした。

2026年7月に公表された2つの脆弱性

今回の弱点は、ISCの公式の告知（CVE-2026-13321）と同（CVE-2026-13204）で公開されました。まず「どのバージョンが対象で、どこまで上げれば直るか」を一覧にまとめます。深刻度は10点満点で、9以上が「緊急」、7〜8点台が「重要」です。

2件に共通する対象・修正版は次のとおりです。使っているバージョンの系列（枝番号）に応じて、上げるべき先が変わります。

大事なのは、修正版が9.20.26と9.21.24だという点です。長く使われてきた9.18系には今回の修正版が用意されていないため、9.18以前を使っている場合は9.20系への移行が必要になります。修正版はISCの公式ダウンロードページから入手できます。

誰が狙い、何をしてくるのか

深刻度の数字や専門用語だけでは、自分に関係があるのか判断しづらいものです。ここでは、より危険なCVE-2026-13321を中心に「誰が・何のために・どんな被害を出すのか」をかみくだいて説明します。

この弱点を突けるのは、署名済みのドメインを1つでも自分で用意できる攻撃者です。特別な立場は要りません。安いドメインを取得してDNSSEC（電子署名）を有効にするだけで、攻撃の足場が作れてしまいます。標的のサーバーに直接侵入する必要もなく、その気になれば誰でも準備できるのが怖いところです。

攻撃者がやろうとするのは、自分のドメインの署名の力を借りて、別人のドメインについての偽の答えをBINDに信じ込ませることです。本来なら署名は自分のドメインの範囲にしか効かないはずですが、この弱点では「隣のドメインまで署名がはみ出す」ような細工が通ってしまいます。その結果、たとえば銀行や社内システムのアドレスについて「存在しません」という偽の回答が、検証済みの正規の答えとしてキャッシュに焼き付けられます。

被害は、そのBINDを使う人すべてに一斉に及びます。同じDNSサーバーを使っている社員やプロバイダの利用者は、標的にされたサイトへ一定時間つながらなくなります。エンドユーザーから見れば「特定のサービスだけ急に開けない」状態で、原因の切り分けも難しくなります。運営する企業にとっては、サービス停止・問い合わせ殺到・信頼低下という損害に直結します。だからこそ、悪用が広がる前に修正版へ上げておくことが何より大切です。

2つの脆弱性の中身（技術的な詳細）

ここからは、2件それぞれがどういう仕組みの弱点なのかを個別に見ていきます。技術に詳しくない方は、前半の一覧表と後半の対処法だけ読めば十分です。

CVE-2026-13321：署名の効く偽の「不在証明」を隣のゾーンに撃ち込む（より危険）

今回の目玉です。DNSSECには、ある名前が「存在しないこと」を署名付きで証明するためのNSECというレコードがあります。NSECには「次に存在する名前」を書く欄があり、これによって「AとBの間には何も存在しない」と証明する仕組みです。ところがBINDのリゾルバ（名前解決を担う側）は、この「次の名前」欄が署名者のゾーン（管理範囲）の外を指していても、そのまま受け入れてしまう欠陥を抱えていました（出典元の検証不備、専門的にはCWE-346）。

これを悪用すると、攻撃者は自分が管理する署名済みゾーンから、他人のゾーンにまたがる偽のNSECを作り出せます。ISCはこれを「ゾーンをまたいだキャッシュ汚染」と表現し、しかもその偽情報が「署名で検証済み（AD=1）」の印つきでキャッシュに残ると説明しています。利用者から見れば「ちゃんと検証された正しい答え」に見えるため、疑う手がかりがありません。NVD（米国の脆弱性データベース）は深刻度を8.6と評価しています。回避策はなく、更新が唯一の対処です。この弱点はPalo Alto NetworksのQifan Zhang氏が報告し、9.20.26／9.21.24で修正されました。

CVE-2026-13204：NSECとNSEC3が同居するとBINDが落ちる

こちらは、細工した状況でBIND本体を異常終了させる弱点です。DNSSECには不在証明の方式としてNSECと、そのプライバシーを高めたNSEC3の2種類があります。ISCの告知によると、署名が正しく整っていないドメインが、親側でNSECとNSEC3の両方に覆われ、かつ片方の種類にしか署名（RRSIG）が付いていない、という特殊な組み合わせが起きると、BINDが検証中に内部の整合性チェックに引っかかり、プロセスが強制終了してしまう状態でした（到達不能とされた状態への到達、CWE-617系のアサーション失敗）。

BINDが落ちれば、そのサーバーが担っていた名前解決は止まり、配下の利用者は一斉にインターネットにつながりにくくなります。攻撃者は認証なしで、細工した名前を問い合わせさせるだけでこの状態を引き起こせるため、サービス妨害（DoS）につながります。深刻度は7.5。こちらも回避策はなく、9.20.26／9.21.24への更新で解消します。

自分のサーバーは対象なのか、どう確認するか

まず押さえておきたいのは、今回の2件はどちらも「名前解決を担うリゾルバ」だけが対象だという点です。DNSサーバーには大きく2つの役割があり、社内やプロバイダで「利用者の問い合わせに答えて名前を引く」キャッシュDNS（フルリゾルバ）と、自社ドメインの情報を外に配信する権威DNSサーバーがあります。今回の弱点はDNSSECの検証処理に関わるため、権威DNSとしてしか使っていないサーバーは基本的に影響を受けません。まずは自分のBINDがどちらの役割かを確認してください。

次に、使っているバージョンを確認します。多くの環境では `named -v` というコマンドでバージョンが表示されます。ここが前掲の対象範囲（9.20.24以前、9.21.23以前など）に入っていれば対象です。加えて、DNSSECの検証を有効にしているかも影響します。ただし現在のBINDは検証が初期状態で有効なため、特に無効化していなければ「検証している」前提で考えておくのが安全です。「リゾルバとして使っているか」「バージョンが対象範囲か」の2点を見れば、自分が対象かどうかは切り分けられます。

BINDのようにあらゆる場所で動く基盤ソフトは、「どのサーバーで・どのバージョンを使っているか」を普段から把握しておくと、こうした告知のたびに慌てずに済みます。使っている部品と既知の弱点を突き合わせて管理する考え方は、オープンソース部品の弱点を洗い出す仕組みの記事でも整理しています。

今すぐやるべき対処

対処はシンプルで、修正版に更新することに尽きます。9.20系を使っているなら9.20.26以上へ、9.21系なら9.21.24以上へ、9.18系以前を使っているなら9.20.26へ移行します。多くのLinuxディストリビューションでは、配布元がパッケージを更新した後に `apt` や `dnf` などの通常の更新手順で適用できます。自前でビルドしている場合はISCの公式ダウンロードから最新版を取得してください。

今回はどちらの弱点にも有効な回避策（設定変更などでの一時しのぎ）が存在しません。DNSSECの検証を止めれば理屈のうえでは露出は減りますが、それは署名検証というセキュリティ機能そのものを捨てる行為で、別のリスクを招くため推奨されません。素直に更新するのが唯一かつ最善の手です。

なお、ISCは2026年に入ってから「BINDのセキュリティ更新は今後より頻繁になる」と告知しており、毎月の保守リリースでセキュリティ修正が入ることを前提に運用する必要があります。今回だけの単発対応ではなく、定期的に更新を当てる体制を整えておくと、次の告知にも落ち着いて対応できます。

実際に悪用されているのか

2026年7月22日の公表時点で、今回の2件が実際の攻撃に使われたという報告は確認されていません。米政府機関CISAが公開する「実際に攻撃されている脆弱性のリスト」（KEV）にも、いずれも登録されていません。今回の公表は、攻撃が起きてからの後追いではなく、報告を受けたISCが修正版を用意してから知らせる通常の開示の流れで行われています。SecurityWeekなど海外の専門メディアも、現時点で悪用は確認されていないと報じています。

とはいえ、BINDは世界中のDNSの土台であり、1つのリゾルバを汚染すればその配下の全利用者に影響が及ぶという性質上、攻撃者にとって狙う価値は高い部類です。弱点の詳細が公開された以上、これを手がかりに攻撃を試みる者が出てくる可能性は否定できません。実際に悪用が始まってから慌てるより、報告がない今のうちに静かに修正版へ上げておくのが、いちばん確実で手間の少ない守り方です。落ち着いて、しかし後回しにせず更新してください。

参照元

• ▸ ISC Knowledge Base - CVE-2026-13321: DNSSEC Validation Bypass via Out-of-Zone NSEC Next Field
• ▸ ISC Knowledge Base - CVE-2026-13204: Unexpected exit with NSEC and NSEC3 both present
• ▸ NVD - CVE-2026-13321（DNSSEC検証回避・キャッシュ汚染、CVSS 8.6）
• ▸ NVD - CVE-2026-13204（NSEC/NSEC3同居時のクラッシュ、CVSS 7.5）
• ▸ SecurityWeek - BIND Updates Patch High-Severity Vulnerabilities
• ▸ ISC Blog - Prepare for more frequent BIND security updates
• ▸ ISC - BIND 9 公式ダウンロード