BIND 9 脆弱性マトリクス｜CVE-2026-5950 等 3 件と影響バージョンの読み解き方

はじめに

社内システムや公開サービスを支える DNS は、停止すると業務全体に直結する基盤の一つです。多くの環境で利用されている BIND 9 については、ISC（Internet Systems Consortium）から年に複数回のペースでセキュリティアドバイザリが公開されますが、運用担当者が最初に気にするのは「自社で使っているバージョンはこの CVE の影響を受けるのか」という点ではないでしょうか。

ISC はこの問いに答えるためのツールとして、BIND 9 Software Vulnerability Matrix（旧称: BIND 9 Security Vulnerability Matrix）という一覧表を公式に公開しています。CVE 番号と影響バージョンをマトリクス形式で可視化したもので、運用中のバージョンを縦軸、CVE を横軸に照らし合わせることで影響有無を素早く判断できます。

2026 年 5 月 20 日、ISC はこのマトリクスを更新し、新たに 3 件の脆弱性（CVE-2026-5946 / 5947 / 5950）と修正版（9.18.49 / 9.20.23 / 9.21.22）を公開しました。本記事ではこの最新情報を題材に、マトリクスの読み解き方と影響バージョン確認の実務手順をまとめます。

BIND 9 Software Vulnerability Matrix とは

BIND 9 Software Vulnerability Matrix は、ISC が公開している脆弱性情報の一覧ページです。脆弱性情報そのものは各 CVE の個別アドバイザリで詳細に確認できますが、「いま運用しているバージョンが、どの CVE の影響を受けるのか」を一画面で見渡せる点がこのマトリクスの実務的な価値といえます。

参考: BIND 9 Software Vulnerability Matrix（ISC Knowledgebase）
“The BIND 9 Software Vulnerability Matrix (previously know as the “BIND 9 Security Vulnerability Matrix”) is a tool to help DNS operators understand the current security risk for a given version of BIND.”
（BIND 9 Software Vulnerability Matrix は、特定のバージョンの BIND における現在のセキュリティリスクを DNS 運用者が把握するためのツールである。）
https://kb.isc.org/docs/aa-00913

マトリクスの 2 部構成（一覧表 + ブランチ別表）

このページは大きく分けて 2 つのパートで構成されています。

第 1 部: CVE 一覧表

ページ上部にあるテーブルで、各脆弱性の参照番号（# 列）、CVE 番号、概要（CVE 個別ページへのリンク付き）が掲載されています。参照番号は ISC が独自に振っている通し番号で、後述するブランチ別表の列見出しとして使われます。

第 2 部: ブランチ別の影響バージョン表

BIND のブランチごと（9.20 / 9.18 など）に、リリースされた各バージョンを縦軸、CVE 参照番号を横軸とした表が並んでいます。表中に + 印があれば、そのバージョンがその CVE の影響を受けることを示します。

ブランチごとに分かれているため、自社で運用しているメジャーブランチ（例: 9.18 系）の表だけを見れば、関係する CVE をまとめて確認できる構成になっています。

参照番号と CVE 番号の対応の見方

具体的な使い方は、ISC 自身が公式ドキュメント内で次のように例示しています。

参考: マトリクスの使い方の例（ISC Knowledgebase）
“For example, if you use the top table to look up CVE-2024-0760 you will see that it cross references to #152. You can look for column #152 in the lower tables to see which versions are vulnerable. If you were still running BIND 9.18.27 you would know to upgrade.”
（例えば、上部の表で CVE-2024-0760 を調べると参照番号 #152 に紐付くことがわかる。下部の表で #152 の列を確認すれば、どのバージョンが影響を受けるかが判別できる。BIND 9.18.27 を使用している場合、アップグレードが必要だと判断できる。）
https://kb.isc.org/docs/aa-00913

このように、CVE 番号 →（第 1 部で）参照番号を確認 →（第 2 部で）自社バージョンに該当する列を見る、という 3 ステップで影響有無を判定できる仕組みです。

なお、ある CVE の参照番号より自ブランチの表の見出し範囲が小さい場合、そのブランチには該当バージョンが存在しません。逆に、参照番号が表の見出しより大きい場合は未検証扱いとなり、影響を受けると仮定して扱うのが安全側の判断となります。

EOL バージョンの扱い

すでにサポートが終了している EOL（End of Life）ブランチについては、マトリクス本体ではなく別ページに分離されています。具体的には 9.0 〜 9.16 までのブランチが該当し、ブランチ別の個別記事として整理されています。

ここで注意したいのは、EOL ブランチに掲載されている脆弱性は「EOL 前、または EOL 直後に発見されたもの」に限られるという点です。ISC 自身が公式ドキュメントで明示しているとおり、EOL 後に発見された脆弱性については検証対象外であり、影響を受ける可能性があることを前提に扱う必要があります。

参考: EOL バージョンの取り扱い方針（ISC Knowledgebase）
“Vulnerability information for EOL (End of Life) versions of BIND 9 (9.0 through 9.16 and below) are included only for vulnerabilities discovered before – or in some cases shortly after – the EOL date. These versions are all known to be affected by some vulnerabilities discovered after their EOL date.”
（BIND 9 の EOL バージョン（9.0 から 9.16 以下）の脆弱性情報は、EOL 日以前、もしくは EOL 直後に発見されたものに限り掲載している。これらのバージョンは、EOL 日以後に発見された脆弱性のいくつかの影響を受けることが知られている。）
https://kb.isc.org/docs/aa-00913

EOL ブランチを使い続けている場合、マトリクス上で + 印がなくても安心はできず、ベンダー配布パッケージのバックポート対応状況や、上位ブランチへの移行を検討することが推奨されます。

2026 年 5 月 20 日公開の 3 件の CVE

2026 年 5 月 20 日、ISC は BIND 9 に関する 3 件の脆弱性アドバイザリを同時公開しました。いずれもリモートから悪用可能で、内訳は High が 2 件（CVE-2026-5946 / CVE-2026-5947）、Medium が 1 件（CVE-2026-5950）です。3 件とも 5 月 13 日に Early Notification（事前通知）が行われ、5 月 20 日に公開された経緯となります。

修正版として 9.18.49 / 9.20.23 / 9.21.22 がリリースされており、運用中のブランチに応じた最新リリースへの移行が推奨されます。以下、それぞれの CVE について公式アドバイザリの内容を整理します。

CVE-2026-5950: リゾルバの再送ループ（Medium / CVSS 5.3）

リゾルバが「応答が不正なサーバー（bad-server）」を扱う際の状態遷移に問題があり、リモートの未認証攻撃者が特定の再試行条件を引き起こすクエリを送り続けることで、リゾルバを再送ループに陥らせ、リソースを枯渇させる可能性のある脆弱性です。

参考: CVE-2026-5950 アドバイザリ（ISC Knowledgebase）
“An unbounded resend loop vulnerability exists in the BIND 9 resolver state machine during bad-server handling, enabling a remote unauthenticated attacker to cause severe resource exhaustion by sending queries that trigger specific retry conditions.”
（BIND 9 リゾルバの状態機械における bad-server 処理に、無制限の再送ループの脆弱性が存在する。リモートの未認証攻撃者が特定の再試行条件を引き起こすクエリを送ることで、深刻なリソース枯渇を発生させる可能性がある。）
https://kb.isc.org/docs/cve-2026-5950

主要な事項を整理すると以下のとおりです。

影響を受けるバージョンと修正版は次のとおりです。

権威サーバー専用構成の場合、原則として影響範囲外と整理されています。ただし、権威サーバーが内部的に再帰クエリを発行するケースも存在するため、ISC はあわせて関連ドキュメント（https://kb.isc.org/docs/why-does-my-authoritative-server-make-recursive-queries）の確認を推奨しています。

CVE-2026-5947: SIG(0) 検証時の Use-after-free（High / CVSS 7.5）

SIG(0) で署名された DNS メッセージの検証処理と、recursive-clients 制限に達した際のメッセージ破棄処理との間に競合状態（race condition）があり、解放済みメモリへの読み取りアクセス（use-after-free）が発生し得る脆弱性です。

参考: CVE-2026-5947 アドバイザリ（ISC Knowledgebase）
“Undefined behavior may result due to a race condition leading to a use-after-free violation. If BIND receives an incoming DNS message signed with SIG(0), it begins work to validate that signature. If, during that validation, the “recursive-clients” limit is reached (as would occur during a query flood), and that same DNS message is discarded per the limit, there is a brief window of time while the SIG(0) validation may attempt to read the now-discarded DNS message.”
（競合状態に起因する use-after-free 違反により未定義動作が発生する可能性がある。BIND が SIG(0) で署名された DNS メッセージを受信すると署名検証を開始するが、その検証中に “recursive-clients” 制限に達して該当メッセージが破棄されると、SIG(0) 検証が破棄済みメッセージを参照しようとする短い時間窓が生じる。）
https://kb.isc.org/docs/cve-2026-5947

主要な事項は以下のとおりです。

影響を受けるバージョンと修正版は次のとおりです。9.18 系については「影響を受けない」と明記されている点が他の 2 件と異なる特徴です。

なお、ISC は「メモリが再利用・再要求されていない場合は検証が正常に進行する可能性もある」「異常なデータ読み取りからのコード実行は起こりにくい」とも述べており、現実的なリスクは主に named の異常終了による DoS と整理されます。

CVE-2026-5946: CLASS != IN の処理不備（High / CVSS 7.5）

DNS メッセージの CLASS が IN（Internet）以外、たとえば CHAOS や HESIOD、あるいは質問セクションで ANY ・ NONE といったメタクラスを指定された場合の処理に複数の欠陥があり、特別に細工されたリクエストにより named がアサーション失敗で異常終了する可能性のある脆弱性です。

参考: CVE-2026-5946 アドバイザリ（ISC Knowledgebase）
“Multiple flaws have been identified in named related to the handling of DNS messages whose CLASS is not Internet (IN) — for example, CHAOS or HESIOD, or DNS messages that specify meta-classes (ANY or NONE) in the question section. Specially crafted requests reaching the affected code paths — recursion, dynamic updates (UPDATE), zone change notifications (NOTIFY), or processing of IN-specific record types in non-IN data — can cause assertion failures in named.”
（CLASS が Internet（IN）以外、たとえば CHAOS や HESIOD、あるいは質問セクションでメタクラス（ANY または NONE）を指定された DNS メッセージの処理に関し、named に複数の欠陥が確認された。再帰、動的更新（UPDATE）、ゾーン変更通知（NOTIFY）、IN 以外のデータでの IN 固有レコードタイプの処理といった、影響を受けるコードパスに到達する細工されたリクエストにより、named でアサーション失敗が発生する可能性がある。）
https://kb.isc.org/docs/cve-2026-5946

主要な事項は以下のとおりです。

影響を受けるバージョンと修正版は次のとおりです。3 件の中で最も広いバージョン範囲に影響が及んでおり、EOL となっている 9.11 〜 9.16 系も対象に含まれている点に注意が必要です。

回避策として ISC は「IN クラス以外のゾーンを設定しない」「動的更新を許可するサーバーをインターネットに公開しない」ことを挙げています。一般的な権威サーバー／キャッシュサーバーであれば前者の条件は満たしやすいですが、動的更新を利用する構成や、内部監視用に CHAOS クラスを使うケース（例: version.bind クエリの応答方式など）では構成を見直す余地がないかをあわせて確認するとよいでしょう。

なお、3 件はいずれも 2026 年 5 月 20 日付で BIND 9 Software Vulnerability Matrix 上の参照番号として、CVE-2026-5946 が #172、CVE-2026-5947 が #173、CVE-2026-5950 が #174 に登録されています。次の章では、このマトリクスを使って自社運用バージョンの影響有無を実際に照合する手順を整理します。

影響範囲と対象バージョンの確認手順

3 件の CVE はリゾルバと権威サーバーで影響範囲が異なり、また同じ 9.18 系であっても CVE-2026-5947 は影響を受けないなど、ブランチ単位ではなくマトリクスを用いた個別判定が欠かせません。ここでは、運用中のサーバーが影響を受けるかどうかを照合する手順を整理します。

マトリクスから自社バージョンを照合する 3 ステップ

ISC の BIND 9 Software Vulnerability Matrix は、次の 3 ステップで使うのが基本です。

例えば BIND 9.18.40 を運用している場合、#172（CVE-2026-5946）と #174（CVE-2026-5950）の列に + 印が並んでいるため、両方の影響を受けると判定できます。一方、#173（CVE-2026-5947）の列は空欄のため、こちらの影響は受けません。

なお、ISC は取り下げられたバージョン（リリース後に回帰バグが見つかった等の理由で撤回された版）には取り消し線を付与しています。マトリクス上で取り消し線付きで表示されているバージョンを運用している場合、それ自体が望ましくない状態であり、当該ブランチの最新版への移行が推奨されます。

参考: マトリクスでの版表記の注意点（ISC Knowledgebase）
“This BIND Security Vulnerability Matrix includes some versions of BIND that were built and then withdrawn due to regressions discovered late in the release process or, in some instances, subsequent to public release.”
（本マトリクスには、リリース工程の終盤、もしくは公開後に判明した回帰バグにより取り下げられたバージョンも掲載されている。）
https://kb.isc.org/docs/aa-00913

サーバー種別による影響の違い（権威/キャッシュ）

3 件の CVE はサーバー種別による影響の有無が異なるため、運用構成に応じた優先度付けが可能です。

キャッシュサーバー（リゾルバ）を運用している場合は 3 件すべてが対象となるため、優先度を高く扱うのが妥当です。権威サーバー専用構成の場合でも、CVE-2026-5947 と CVE-2026-5946 は影響対象に含まれるため、修正版への移行は同様に推奨されます。

EOL ブランチ（9.16 以下）利用時の注意

CVE-2026-5946 は、すでに EOL となっている 9.11 〜 9.16 系も影響範囲に含まれています。ただし、これらの EOL ブランチには ISC からのパッチ提供はなく、修正は上位ブランチ（9.18 系以降）への移行で実施することになります。

ベンダー（Red Hat、Canonical 等）が独自にバックポート対応する場合もあるため、ディストリビューションのセキュリティアドバイザリも併せて確認することが推奨されます。なお、EOL ブランチを継続利用する場合、マトリクスに掲載されていない脆弱性の影響を受けている可能性を前提に運用を見直す必要があります。

修正バージョンと移行時の確認ポイント

修正版一覧（9.18.49 / 9.20.23 / 9.21.22）

2026 年 5 月 20 日の同時公開で示された修正版は次の 3 つです。3 件の CVE すべてがこれらのバージョンで修正されています。

なお、ISC はサポート対象のバージョンに対してのみパッチを提供する方針を公式に示しています。

参考: ISC のパッチ提供方針（ISC Knowledgebase）
“ISC patches only currently supported versions. When possible we indicate EOL versions affected. For current information on which versions are actively supported, please see https://www.isc.org/download/.”
（ISC は現在サポート対象のバージョンに対してのみパッチを提供する。可能な範囲で影響を受ける EOL バージョンも記載する。サポート対象の最新情報は https://www.isc.org/download/ を参照のこと。）
https://kb.isc.org/docs/cve-2026-5950

バージョン確認コマンド

運用中の BIND のバージョンは、named バイナリのオプションで確認できます。インフラ運用上は次の 3 つのコマンドを使い分けると、移行判断に必要な情報を素早く揃えられます。

# バージョンのみを表示
named -v

# バージョンに加え、コンパイル時のオプションや実行環境を表示
named -V

# ビルトインのデフォルトオプション値を確認（9.18.3 / 9.16.29 以降で利用可能）
named -C

-V オプションは、コンパイル時の構成オプション（DNSSEC、DoT、DoH などのサポート状況）まで一覧できるため、移行前後の構成差分を比較する用途で有用です。-C オプションは BIND 9.18.3 および 9.16.29 で追加されたもので、named.conf で明示していないオプションのデフォルト値を把握するのに役立ちます。

参考: named -C オプションの追加について（ISC Knowledgebase）
“From versions 9.18.3 (and backported to 9.16.29) a new switch is available for named; -C.”
（バージョン 9.18.3 から named に新しいスイッチ -C が利用可能になった（9.16.29 にもバックポート済み）。）
https://kb.isc.org/docs/aa-00704

また、稼働中の named プロセスに対しては rndc status でランタイム情報を確認できます。

# 稼働中の named のバージョンや動作状態を確認
rndc status

ディストリビューション配布パッケージの場合は、パッケージ管理コマンドからもバージョンを確認できます。

# Red Hat 系
rpm -q bind

# Debian / Ubuntu 系
dpkg -l | grep -E '^ii\s+bind9'

ベンダー配布版は upstream のバージョン番号にディストリビューション独自のサフィックスが付くため、マトリクス上のバージョンと完全一致するとは限りません。後述の「ベンダー配布 BIND 使用時の留意点」もあわせて確認することが推奨されます。

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

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

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

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

# named.conf の構文チェック
named-checkconf /etc/named.conf

# ゾーンファイルの構文チェック（個別ゾーン）
named-checkzone example.com /var/named/example.com.zone

2. プロセスの稼働確認

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

# プロセスの状態確認
systemctl status named   # Red Hat 系
systemctl status bind9   # Debian / Ubuntu 系

3. ログでの異常検知

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

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

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

4. 名前解決の動作確認

dig で実際の名前解決が想定通り行えるかを最終確認します。リゾルバとして公開している場合は、内部ホスト名と外部ドメインの両方で確認するのが基本です。

# 自ホストのリゾルバに対するクエリ
dig @127.0.0.1 example.com A +short

# DNSSEC 検証が機能していることの確認
dig @127.0.0.1 example.com A +dnssec +short

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

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

ここまではマトリクスの読み方と移行手順を中心に整理してきましたが、最後に運用面で押さえておきたい考え方を 3 点まとめます。1 回のアップグレード作業を完了させるだけでなく、継続的にセキュリティ情報を把握できる体制を持つことが、DNS 基盤の安定運用には欠かせません。

マトリクスを定期的に確認する習慣

ISC はサポート対象ブランチに対するセキュリティリリースを、年に複数回（おおむね四半期前後の頻度）で公開しています。本記事で取り上げた 2026 年 5 月 20 日の同時公開も、同様のリリースサイクルにおける一例です。

そのため、運用者側でも月次・四半期単位でマトリクスを確認するルーチンを組み込んでおくと、新しい CVE と運用バージョンの突き合わせを抜け漏れなく行えます。具体的には次のような工夫が考えられます。

• 月次の運用レビューにマトリクス確認を組み込む
• BIND の named -v 出力を CMDB や構成管理ツール（Ansible 等）で定期収集し、現行バージョンを一覧化しておく
• ISC のメーリングリストを購読し、新規アドバイザリ公開時に通知を受けられるようにする

ベンダー配布 BIND（RHEL/Ubuntu 等）使用時の留意点

実運用環境では、ISC からソースを直接ビルドするケースよりも、RHEL や Ubuntu などのディストリビューションが配布するパッケージを利用するケースが多いと考えられます。この場合、パッケージのバージョン番号は upstream の番号と必ずしも一致しません。

例として、RHEL 系では bind-9.16.23-24.el9_4.4 のようにメジャー・マイナー部分の後ろにディストリビューション独自のリビジョンが付与され、セキュリティ修正もそのリビジョン側にバックポートされるのが一般的です。マトリクス上の 9.16.23 は影響ありと表示されていても、実際にはバックポート済みパッチが適用されていて影響を受けないケースが存在します。

したがって、ベンダー配布 BIND を使っている場合の確認順序は次のようになります。

1. マトリクスで upstream バージョンの影響有無を確認する
2. 影響ありと判定された場合、ディストリビューション側のセキュリティアドバイザリ（Red Hat の RHSA、Ubuntu の USN、Debian の DSA 等）を確認する
3. パッケージマネージャー（dnf updateinfo、apt list --upgradable 等）で対応済みパッケージが提供されているかを確認する
4. 対応済みであればパッケージ更新、未対応であれば緩和策の検討や上位ブランチへの移行を検討する

この流れを定着させておくと、「upstream は影響を受けるがディストリビューション側は対応済み」という現場で頻発するケースを正しく判定できます。

セキュリティ情報の一次情報源としての ISC KB

DNS の脆弱性情報はさまざまなメディアで取り上げられますが、正確な影響範囲や CVSS スコア、修正バージョンを確認するには、ISC の Knowledgebase（KB）を一次情報源として参照するのが確実です。報道や二次情報には、影響範囲の解釈に揺れがあったり、修正版の最新情報が反映されていないケースが見られます。

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

• BIND 9 Software Vulnerability Matrix: https://kb.isc.org/docs/aa-00913
• 各 CVE 個別アドバイザリ（例: CVE-2026-5950）: https://kb.isc.org/docs/cve-2026-5950
• BIND のダウンロード／サポート状況一覧: https://www.isc.org/download/

社内で脆弱性対応の判断材料を共有する際も、これら一次情報の URL とあわせて引用することで、対応方針の説明責任を果たしやすくなります。

まとめ

本記事では、BIND 9 Software Vulnerability Matrix の読み解き方と、2026 年 5 月 20 日に公開された 3 件の CVE への対応ポイントを整理しました。

• BIND 9 Software Vulnerability Matrix は CVE と影響バージョンを照合できる ISC 公式の一覧ツール
• 2026 年 5 月 20 日に CVE-2026-5946 / 5947 / 5950 の 3 件が公開され、修正版 9.18.49 / 9.20.23 / 9.21.22 がリリース
• 3 件はサーバー種別による影響範囲が異なり、リゾルバ運用環境では 3 件すべてが対象
• 影響有無の判定は「CVE → 参照番号 → ブランチ表 → バージョン行」の 3 ステップで実施可能
• 移行前後の確認は named -V、named-checkconf、rndc status、dig を組み合わせて実施
• ベンダー配布 BIND はバックポート対応の有無を別途ディストリビューションのアドバイザリで確認することが重要
• 月次・四半期単位でのマトリクス確認と、ISC KB を一次情報源とする運用習慣が DNS 基盤の安定につながる

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