DNSの定番ソフト「BIND」に脆弱性9件、特定サイトが開けなくなる恐れ CVE-2026-13321ほか9.20.26／9.21.24へ更新を

インターネットの「住所案内」を担う代表的なソフト「BIND（バインド）」に、2026年7月の定例セキュリティ更新であわせて9件の脆弱性（ソフトの弱点）が公表されました。開発元のISC（Internet Systems Consortium）が同時に告知し、いずれも修正版が同じ日に公開されています。

最も注意したいのが、攻撃者が用意した偽の応答を「正しいものだ」と信じ込ませる系統です。中でも10点満点で8.6と評価されたCVE-2026-13321は、特定のサイトについて「そんな住所は存在しない」といった偽の答えをBINDのキャッシュに埋め込み、そのサーバーを使う利用者全員を目的のサイトにつなげなくできる可能性があります。厄介なのは、この偽の答えが電子署名の検証を通り抜け、「本物と確認済み」の顔をして混ざり込む点です。残りの多くは、細工した問い合わせでBINDそのものを止めてしまうサービス妨害（DoS）系の弱点です。

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

2026年7月に公表された9件の一覧

まず全体像です。深刻度は10点満点で、9以上が「緊急」、7〜8点台が「重要」、4〜6点台が「警告」の目安です。今回はどれも、名前解決を担うキャッシュDNS（リゾルバ）が主な対象です（役割の違いは後述します）。

9件のうち、偽の応答を信じ込ませる「詐称・キャッシュ汚染」系が3件、BINDを止める「サービス妨害（DoS）」系が5件、防御ルールをすり抜ける系が1件です。以下、この3グループに分けて中身を見ていきます。

偽の応答を信じ込ませる脆弱性（最も注意）

最初のグループは、攻撃者の偽情報を「検証済みの正しい答え」としてBINDに信じ込ませるタイプです。利用者から見ると「ちゃんと確認された答え」に見えるため、疑う手がかりがなく、被害に気づきにくいのが特徴です。技術に詳しくない方は、各項目の1〜2行目だけ読めば概要はつかめます。

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

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

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

CVE-2026-11721：ラベル数の食い違いを突いてキャッシュに偽情報（7.5）

こちらも偽情報をキャッシュに焼き付ける弱点です。攻撃者が、実際のゾーンよりラベル（ドットで区切られた階層）の数が少ない署名（RRSIG）を含む応答を作ると、BINDが本来より短いワイルドカード項目を生成してしまい、キャッシュに偽の情報が残ります。ISCは「ラベル数の食い違い・署名・ワイルドカードを組み合わせたキャッシュ汚染」と説明しています。名前解決の際にDNSSECから答えを合成する設定（synth-from-dnssec、初期状態で有効）が前提となる点も、多くの環境で条件を満たしてしまうため注意が必要です。13321と同じくPalo Alto NetworksのQifan Zhang氏が報告。深刻度7.5、9.20.26／9.21.24で修正です。

CVE-2026-10723：偽の「存在しません」を信じ込ませる（6.8）

存在しないことを証明する方式のひとつNSEC3のレコードを、BINDが本来受け入れるべきでない形でも受理してしまう弱点です。これを突くと、隣接するゾーンについて「そんな名前は存在しない（NXDOMAIN）」という偽の不在証明を、検証済みのように信じ込ませられます。13321と同系統のDNS詐称につながりますが、深刻度は6.8とやや低めです。こちらも修正版は9.20.26／9.21.24で、悪用報告はありません。

サービスを止めてしまう脆弱性（サーバー停止・資源枯渇）

2つ目のグループは、細工した問い合わせや応答でBINDを異常終了させたり、CPU・メモリを食い尽くしたりして、名前解決を止めてしまうサービス妨害（DoS）系です。5件が該当します。BINDが止まると、そのサーバーを使う社員やプロバイダの利用者は一斉にインターネットにつながりにくくなります。

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

署名が正しく整っていないドメインが、親側でNSECとNSEC3の両方に覆われ、かつ片方の種類にしか署名（RRSIG）が付いていない、という特殊な組み合わせが起きると、ISCの告知によればBINDが検証中に内部の整合性チェックに引っかかり、プロセスが強制終了します。攻撃者は認証なしで、細工した名前を問い合わせさせるだけでこの状態を引き起こせます。深刻度は7.5、9.20.26／9.21.24で解消します。

CVE-2026-12617：CNAME／DNAMEの順序でBINDが落ちる（7.5）

応答の中で、別名を表すCNAMEや、別名をまとめて転送するDNAMEのレコードが特定の順序・組み合わせで届くと、BINDが内部の整合性チェックに引っかかって異常終了します。たとえば、肯定的な応答の後に遅れて否定的なDNAME応答が届く、といった状況が引き金になります。攻撃者は認証なしで、細工した応答を返すだけでBINDを止められます。深刻度7.5で、9.20.26で修正されました。

CVE-2026-11622：メモリを設定上限より食い尽くす（7.5）

存在しないサブドメインを大量に問い合わせる「ランダムサブドメイン攻撃」を受けたとき、BINDのメモリ使用量が設定した上限（max-cache-size）を大きく超えて膨らみ、応答が遅くなったりメモリ不足に陥ったりします。上限を設けていても桁違いに超えうる点が問題で、深刻度7.5。DNSSEC検証を行うリゾルバが対象で、9.20.26／9.21.24で修正です。

CVE-2026-11605：署名の過剰な検証でCPUを浪費する（7.5）

応答に必要以上の署名（RRSIG）が含まれていると、BINDがそれらを無駄に検証し続け、CPUを過剰に消費します。攻撃者はこれを利用して処理を重くし、名前解決を滞らせられます。深刻度7.5で、対象は9.20系・9.21系。9.20.26／9.21.24への更新で解消します。

CVE-2026-10822：未知の署名方式の鍵レコードで異常終了（6.5）

独自の署名アルゴリズムを指定できるPRIVATEDNSという仕組みを悪用し、不正な値を持つ鍵レコード（KEY）を処理させると、9.20系・9.21系のBINDが予期せず終了することがあります。細工したレコードを処理・保存させることで起こり、認証は不要です。深刻度6.5で、9.20.26／9.21.24で修正されました。

防御ルールをすり抜ける脆弱性

CVE-2026-11331：フィルタ（RPZ）をワイルドカードですり抜ける（7.5）

RPZ（応答ポリシーゾーン）は、危険なドメインへの名前解決をブロックするための、いわば「DNSのフィルタ」です。今回の弱点は、ワイルドカードを使ったCNAMEのポリシー設定に不備があり、この防御をすり抜けられる、あるいはBINDをクラッシュさせられるというものです。ISCの告知によれば深刻度は7.5。RPZでワイルドカードCNAMEのポリシーを使っている環境だけが対象で、RPZを使っていなければ影響しません。使っている場合は9.20.26／9.21.24へ更新してください。

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

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

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

今回の弱点を理解するうえで、もうひとつ大事な仕組みがDNSSECです。これは、DNSが返した答えが途中ですり替えられていないかを電子署名で確かめる、いわば「住所案内に公印を押す」仕組みです。今回の9件の多くは、このDNSSECの検証処理にひそんでいた欠陥でした。困ったことに、答えの正しさを守るはずの仕組みそのものが、偽装やサーバー停止の入り口になっていました。

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

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

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

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

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

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

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

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

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

今すぐやるべき対処

対処はシンプルで、修正版に更新することに尽きます。使っているバージョンの系列（枝番号）に応じて、上げるべき先が変わります。

大事なのは、修正版が9.20.26と9.21.24だという点です。長く使われてきた9.18系には今回の修正版が用意されていないため、9.18以前を使っている場合は9.20系への移行が必要になります。多くのLinuxディストリビューション（Ubuntu／Debian／RHEL／SUSEなど）では、配布元がパッケージを更新した後に apt や dnf などの通常の更新手順で適用できます。自前でビルドしている場合はISCの公式ダウンロードページから最新版を取得してください。

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

なお、ISCは2026年に入ってから「BINDのセキュリティ更新は今後より頻繁になる」と告知しており、今回9件がまとめて出たのもその流れの一環です。毎月の保守リリースでセキュリティ修正が入ることを前提に、定期的に更新を当てる体制を整えておくと、次の告知にも落ち着いて対応できます。

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

2026年7月の公表時点で、今回の9件が実際の攻撃に使われたという報告は確認されていません。米政府機関CISAが公開する「実際に攻撃されている脆弱性のリスト」（KEV）にも、いずれも登録されていません（最新の掲載状況はCISA KEVダッシュボード（日本語版）で確認できます）。ISCも大半について「社内テストで発見し、悪用は確認していない」と述べています。今回の公表は、攻撃が起きてからの後追いではなく、報告を受けたISCが修正版を用意してから知らせる通常の開示の流れで行われています。SecurityWeekなど海外の専門メディアも、現時点で悪用は確認されていないと報じています。

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

参照元

• ▸ JVNVU#97496543 - ISC BINDにおける複数の脆弱性（2026年7月）
• ▸ ISC Knowledge Base - CVE-2026-13321: DNSSEC Validation Bypass via Out-of-Zone NSEC Next Field
• ▸ ISC Knowledge Base - CVE-2026-11721: Cache poisoning with label count discrepancy, RRSIG, and wildcards
• ▸ ISC Knowledge Base - CVE-2026-13204: Unexpected exit with NSEC and NSEC3 both present
• ▸ NVD - CVE-2026-13321（DNSSEC検証回避・キャッシュ汚染、CVSS 8.6）
• ▸ SecurityWeek - BIND Updates Patch High-Severity Vulnerabilities
• ▸ ISC Blog - Prepare for more frequent BIND security updates
• ▸ ISC - BIND 9 公式ダウンロード