--- title: "BINDの脆弱性CVE-2026-94300とは：2026年10月の4件の対象版と確認コマンド・更新手順" url: "https://www.issoh.co.jp/tech/details/18989/" published: 2026-10-27 updated: 2026-10-27 categories: ["セキュリティ"] publisher: "株式会社一創" --- # BINDの脆弱性CVE-2026-94300とは：2026年10月の4件の対象版と確認コマンド・更新手順 ISCは2026年10月21日、DNSサーバーソフトウェアBIND 9の脆弱性4件を公表しました。最も深刻なCVE-2026-94300は、Kerberos認証の動的更新に使うGSS-TSIGの処理でnamedのメモリが壊れるもので、リモートコード実行につながる可能性があります。残る3件はフルリゾルバーをDoSで止められる問題です。本記事では、4件の対象条件と修正版、稼働中のnamedの版と設定を確かめるコマンド、Debian・Ubuntu・RHELのパッケージの修正状況、修正版が出ない9.18系の扱いを実装者の目線で整理します。記載内容は2026年10月27日時点の公開情報にもとづきます。 ## まとめ：BINDは9.20.30へ上げ、9.18系は移行か配布元の修正かを決める ISCの修正版は9.20.30と開発版の9.21.27です。4件とも回避策は無いとされているため、対象の版で動くnamedは版を上げるのが基本の対応になります。 9.18系は2026年6月の9.18.50で保守が終わっており、ISCから修正版は出ません。OS付属のBINDを使っているなら、配布元が9.18系に修正を移植するかを追跡ページで確かめ、出るまでの間はGSS-TSIGの無効化と53番ポートの接続元の制限でしのぎます。 DoSの3件はフルリゾルバーで、redirectゾーンやRPZなど特定の設定がある場合に限られます。権威DNSサーバーだけを動かしている組織でも、GSS-TSIGを有効にしていればCVE-2026-94300の対象です。 ## 2026年10月21日公表のBIND脆弱性4件の内容と影響を受ける条件 4件は[JVNVU#91196958](https://jvn.jp/vu/JVNVU91196958/)でまとめて公表されました。ISCは10月14日に事前通知を出し、21日に一般公開しています。いずれもISCの評価は「高（High）」です。 ### CVE-2026-94300のGSS-TSIGメモリ破損とCVSS 8.1のRCEリスク [ISCのCVE-2026-94300のアドバイザリ](https://kb.isc.org/docs/cve-2026-94300)によると、GSS-TSIGで署名されたUDPメッセージを再送されると、namedのメモリが壊れることがあります。攻撃者が再送するのは、以前に署名されたメッセージで、交渉済みのTSIG鍵がまだ有効な間です。さらに自分が管理するゾーンへの細工した問い合わせを組み合わせると、リモートコード実行に至る可能性があるとされています。 CVSS v3.1の基本値は8.1、ベクトルは `AV:N/AC:H/PR:N/UI:N` で始まります。ネットワーク越しにログイン不要で成立しうる一方、攻撃の難しさは「高」の評価です。ベクトルの読み方は[CVSSv3のスコアの目安と計算式](https://www.issoh.co.jp/tech/details/5094/)で確認できます。 GSS-TSIGは、Active DirectoryのドメインコントローラーやIdMがKerberosの認証付きでDNSレコードを動的に更新する仕組みです。[Active DirectoryとLDAP](https://www.issoh.co.jp/tech/details/13316/)の環境で、Windowsクライアントの名前をBINDに登録させている構成が典型の対象になります。 ### CVE-2026-19630・96888・97313のDoSとフルリゾルバー側の条件 残る3件はCVSS v3.1で7.5、影響はサービス停止です。いずれも問い合わせを受けて再帰検索をするフルリゾルバーの条件として書かれています。 | CVE | 起きること | 成立する条件 | | -------------- | ----------------- | ------------------------- | | CVE-2026-19630 | CPUとメモリの枯渇 | 特定の構造を大量に含むメッセージを受けるリゾルバー | | CVE-2026-96888 | アサーション失敗でnamedが終了 | redirectゾーン＋strict最小化 | | CVE-2026-97313 | アサーション失敗でnamedが終了 | 再帰許可とyes・noが混在するRPZ | [CVE-2026-19630](https://kb.isc.org/docs/cve-2026-19630)は設定に関係なく、対象版のリゾルバーなら当たります。[9.20.30のリリースノート](https://bind9.readthedocs.io/en/v9.20.30/notes.html)には、圧縮された名前の展開に上限を設け、超えたらFORMERRを返す修正と書かれています。[CVE-2026-96888](https://kb.isc.org/docs/cve-2026-96888)と[CVE-2026-97313](https://kb.isc.org/docs/cve-2026-97313)は、設定が条件に合うときだけです。 リゾルバーが止まると、社内の端末やアプリケーションの名前解決がすべて失敗します。外から大量の問い合わせを受ける構成なら、[DDoS攻撃への備え](https://www.issoh.co.jp/column/details/13260/)と同じ視点で、どこから問い合わせを受け付けているかを見直す機会になります。 ### 9.11.0から9.21.26までの対象範囲とISCの修正版の対応表 対象版の下限はCVEごとに違います。上限はどれも9.18.50・9.20.29・9.21.26です。 | CVE | 9.18系以前 | 9.20系 | 9.21系（開発版） | | -------------- | -------------- | -------------- | -------------- | | CVE-2026-94300 | 9.11.0〜9.18.50 | 9.20.0〜9.20.29 | 9.21.0〜9.21.26 | | CVE-2026-19630 | 9.11.0〜9.18.50 | 9.20.0〜9.20.29 | 9.21.0〜9.21.26 | | CVE-2026-96888 | 9.16.0〜9.18.50 | 9.20.0〜9.20.29 | 9.21.0〜9.21.26 | | CVE-2026-97313 | 9.16.0〜9.18.50 | 9.20.0〜9.20.29 | 9.21.0〜9.21.26 | | 修正版 | なし | 9.20.30 | 9.21.27 | サポート契約者向けのSupported Preview Edition（-S1）は9.20.30-S1が修正版です。表の9.18系の列で修正版が「なし」なのは誤りではありません。[BIND 9 Software Vulnerability Matrix](https://kb.isc.org/docs/aa-00913)も、現行の対象系列を9.20だけとして載せています。 ## 自社のnamedが対象かを版番号と設定の両方で確かめるコマンド 判断に要る情報は2つです。稼働中のnamedの版と配布元、それに4件の条件に当たる設定があるかどうかです。 ### named -Vとdig version.bindで稼働中の版と配布元を読み分ける 次のコマンドは読み取りだけで、設定を変えません。OSのパッケージで入れたBINDは、版番号が9.18.49のままでも配布元が修正を移植していることがあるため、パッケージの変更履歴も併せて見ます。 ``` # 1. 実行ファイルの版とビルド情報（ISC配布版か、OSのパッケージか） named -V | head -3 # 2. 動いているプロセスに直接たずねる（version を隠す設定なら応答は別の文字列） dig @127.0.0.1 version.bind chaos txt +short # 3. パッケージの変更履歴に CVE 番号があるか（修正が移植済みかの確認） apt changelog bind9 2>/dev/null | grep -m3 CVE-2026-94300 # Debian / Ubuntu rpm -q --changelog bind 2>/dev/null | grep -m3 CVE-2026-94300 # RHEL 系 ``` 1と2の版が違うなら、パッケージは更新したのにnamedを再起動していない状態です。3で何も出ない場合は、その版のパッケージにまだ修正が入っていないと読みます。サーバーが複数あるなら、ゾーン転送先のセカンダリも同じ手順で洗い出してください。 ### named-checkconf -pでGSS-TSIG・redirect・RPZを確認 `named-checkconf -p` はincludeしたファイルも展開した設定全体を出力します。そこからgrepで拾う対象は、4件の脆弱性が成立する条件に関わる設定行だけです。項目の文法は[BIND 9.20.30のConfiguration Reference](https://bind9.readthedocs.io/en/v9.20.30/reference.html)で確認できます。 ``` # 設定ファイルの場所は Debian 系が /etc/bind/named.conf、RHEL 系が /etc/named.conf sudo named-checkconf -p /etc/named.conf \ | grep -nE 'tkey-gssapi-(keytab|credential)|type redirect|qname-minimization|response-policy|recursive-only|recursion ' ``` 読み方は次のとおりです。`tkey-gssapi-keytab` か `tkey-gssapi-credential` が出ればGSS-TSIGが有効で、CVE-2026-94300の対象です。`type redirect` と `qname-minimization strict` の両方が出ればCVE-2026-96888に当たります。`response-policy` の中に `recursive-only no` のゾーンと指定の無い（既定のyes）ゾーンが並んでいれば、CVE-2026-97313の条件です。 どの行も出なくても、対象版のリゾルバーであればCVE-2026-19630は残ります。設定の確認で更新の要否が消えるのは、権威専用でGSS-TSIGを使わないサーバーに限られる点に注意してください。 ## 9.20.30への更新とディストリビューション版BINDの修正状況 更新の進め方は、BINDをISCの配布物で入れたか、OSのパッケージで入れたかで分かれます。 ### ISC配布版とbind-esvリポジトリの環境で9.20.30へ上げる流れ ソースや[JPRSの注意喚起](https://jprs.jp/tech/security/2026-10-22-bind9-cve-2026-94300.html)が案内する配布物から入れている環境では、9.20.30へ上げます。9.20系の中での更新なら設定の書き換えは基本的に要りません。上げた後は前章の1と2で版を確かめ、`rndc status` で稼働を確認します。 ISCのパッケージリポジトリを使っている場合は、リポジトリ名に注意が要ります。[ISCの9.18 EOLの告知](https://www.isc.org/blogs/2026-06-10-bind9-18-eol/)によると、長期版向けのbind-esvリポジトリは2026年7月15日から9.20を配るようになりました。bind-esvで9.18を使っていた環境は、次の更新で9.20へ上がります。 9.18から9.20へ上がると、既定値や廃止された設定項目の影響を受けます。本番に入れる前に、検証機で `named-checkconf` が警告なしで通ることと、主要なゾーンの応答を確かめてください。 ### Debian・Ubuntu・RHELの追跡ページで見る10月27日時点の状況 OSのパッケージを使っている場合、更新先は配布元が出す修正パッケージです。各配布元の追跡ページを2026年10月27日に確認した結果を並べます。 | 配布元 | 系列・リリース | CVE-2026-94300の状況 | | ------------------- | ----------- | -------------------------- | | Debian 13（trixie） | 9.20系 | 修正済み（1:9.20.30-1\~deb13u1） | | Debian 12（bookworm） | 9.18系 | 未修正（1:9.18.49-1\~deb12u2） | | Ubuntu 18.04〜26.10 | 各リリースのbind9 | いずれも未修正（Vulnerable） | | Red Hat | RHELのbind | 深刻度Important、エラッタ未掲載 | 出典は[Debian security tracker](https://security-tracker.debian.org/tracker/CVE-2026-94300)、[UbuntuのCVEページ](https://ubuntu.com/security/CVE-2026-94300)、[Red HatのCVEページ](https://access.redhat.com/security/cve/CVE-2026-94300)です。Debian 12やUbuntuのLTSのように9.18系を載せたリリースは、ISCから修正版が出ないため、配布元が修正を移植するまで待つ形になります。追跡ページは日々更新されるので、作業の当日に開き直してください。 ### 更新できない間のGSS-TSIG無効化と53番ポートの接続元制限 ISCとJPRSは回避策は無いとしています。Red Hatのページは、Kerberos認証の動的更新が要らないならGSS-TSIGの設定を外す緩和策を挙げています。 ``` # named.conf（とinclude先）の options から次の行を外す # tkey-gssapi-keytab "..."; # tkey-gssapi-credential "..."; # 設定を確かめてから再起動する（chroot 環境は named-chroot） sudo named-checkconf && sudo systemctl restart named # 53番ポートを信頼できるセグメントだけに絞る（firewalld の例・192.0.2.0/24 は置き換える） sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.0.2.0/24" service name="dns" accept' sudo firewall-cmd --permanent --remove-service=dns sudo firewall-cmd --reload ``` GSS-TSIGを外すと、Active DirectoryやIdMからの動的更新が止まり、端末の名前がDNSに載らなくなります。再起動の間は名前解決も途切れるので、作業時間を決めて行ってください。接続元の制限はDoSの3件にも効きますが、社内から問い合わせを受けるリゾルバーでは外せない経路が残ります。 ## BIND 9.18系EOL後の判断基準と月例ペースの修正を受ける体制 今回の4件で見えたのは、9.18系を使い続ける余地が狭くなったことと、BINDの修正版の間隔の短さです。 ### 9.18.50で保守を終えた系列を使い続けてよい場合と移行すべき場合 使い続けてよいのは、OSの配布元がその9.18系に修正を移植し続ける場合だけです。その場合でも、更新の主導権は配布元にあります。今回のように配布元の修正が出るまで日数がかかる間、自分で取れる手段は前章の緩和策しかありません。 次のどれかに当たるなら、9.20系への移行を先に計画します。 - ISCの配布物から自分でビルドした9.18系を動かしている（修正の出どころが無い） - GSS-TSIGを有効にしたまま運用している（緩和策で業務が止まる） - OSのサポート期限が近く、9.20系を載せた次のリリースへ上げる予定がある 前者2つは、9.18系のままでは次の脆弱性でも同じ状況になります。DNSSECの検証や署名を動かしているなら、移行の検証項目に[DNSSECの検証と署名](https://www.issoh.co.jp/tech/details/10518/)の動作も加えてください。 ### 2026年に修正版が相次ぐBINDで更新体制と手順を点検する項目 Vulnerability Matrixを見ると、2026年にCVEの修正を含む9.20系の版は、1月の9.20.18から10月の9.20.30まで6回出ています。7月の9.20.25と9月の9.20.28は公開後に取り下げられました。単一のCVEを扱った[CVE-2025-13878の解説](https://www.issoh.co.jp/tech/details/10741/)は1月の版、[CVE-2025-40775の解説](https://www.issoh.co.jp/tech/details/7003/)は2025年の版の話です。 年に数回の更新を前提にした体制では追いつきません。次の項目を確かめます。 - 権威とリゾルバー、プライマリとセカンダリの台数と版を一覧で持っている - セカンダリから順に入れ替え、[名前解決](https://www.issoh.co.jp/tech/details/13556/)を止めずにnamedを更新する手順がある - 取り下げられた版を入れていないかを、版の一覧で確かめられる DNSは止めると社内のすべてのシステムに響く一方、外から問い合わせを受ける入口でもあります。BINDの版と設定に加えて、外から到達できるサービスの棚卸しまでまとめて行うなら、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で外部に開いたポートと導入製品の版を洗い出すと、更新の優先順位を付けやすくなります。 ## BINDの脆弱性CVE-2026-94300対応でよく受ける質問と回答 今回の4件の対応で出てきやすい疑問に、公開されている一次情報の範囲で答えます。 ### 権威DNSサーバーだけを動かしていれば対応は不要ですか？ GSS-TSIGを使っていなければ、今回の4件の条件からは外れます。CVE-2026-94300はGSS-TSIGの処理の問題で、残る3件はフルリゾルバーの条件として書かれているためです。ただし、権威サーバーで再帰を許可したままの構成は珍しくありません。named-checkconf -pでrecursionとtkey-gssapiの行を確かめ、どちらも無いことを確認してから判断してください。版を上げる計画自体は、次の脆弱性に備えて立てておくべきです。 ### 9.18系の修正版をISCに頼んで入手できますか？ 公開されている修正版はありません。ISCは9.18系を2026年6月の9.18.50で保守終了としており、JPRSも、サポートを終えた系列向けのセキュリティパッチはISCがリリースしないと伝えています。サポート契約者向けのSupported Preview Editionも、修正版は9.20.30-S1です。9.18系のままで修正を得る手段は、OSの配布元による移植だけです。 ### 悪用は確認されていますか？急ぐ必要はありますか？ ISCは4件とも悪用を把握していないとしています。CVE-2026-94300は署名済みメッセージの入手が前提で、攻撃の難しさは高い評価です。それでもリモートコード実行の可能性がある以上、GSS-TSIGを有効にしたサーバーは最優先で対応します。DoSの3件は、外部から問い合わせを受け付けるリゾルバーかどうかで優先度を決めます。 ### Samba ADのBIND9\_DLZ構成も対象になりますか？ Samba ADのDNSをBIND9\_DLZで動かす構成は、Kerberos認証の動的更新のためにnamed.confへtkey-gssapi-keytabを書く手順が一般的です。その行がある限り、CVE-2026-94300の条件に当たります。この構成ではGSS-TSIGを外すとドメイン参加端末の名前登録が止まるため、緩和策ではなく、BINDのパッケージを修正版へ上げる対応を優先してください。 ### Windows ServerのDNSやクラウドのマネージドDNSは関係ありますか？ 関係ありません。今回の4件はISCのBIND 9の実装の問題です。Windows ServerのDNSやRoute 53などのマネージドDNSは別の実装なので、この4件の対象にはなりません。ただし、アプライアンス製品やルーターの中でBINDが動いていることがあります。DNS機能を持つ機器は、製品の告知でBINDの採用有無と版を確かめてください。 ## 関連記事 - [CVE-2025-40775とは｜BIND 9.20/9.21がTSIG不正でnamed停止するDoS脆弱性と対象版・修正版](https://www.issoh.co.jp/tech/details/7003/)：同じTSIG周りで起きた2025年のBINDの脆弱性です。 - [CVE-2025-13878とは｜BIND 9のBRID/HHITレコードでnamedが停止するDoS脆弱性の対象版と対策](https://www.issoh.co.jp/tech/details/10741/)：2026年1月の9.20.18で直ったnamedの停止の例です。 - [脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務を解説](https://www.issoh.co.jp/tech/details/13546/)：脆弱性の公表から修正までの流れの基礎を確認できます。 - [CVE（共通脆弱性識別子）とは？番号の読み方・CVSS/CWE/NVDとの違いと調べ方](https://www.issoh.co.jp/tech/details/5092/)：CVE番号とアドバイザリの読み方を整理しています。 - [脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説](https://www.issoh.co.jp/column/details/13101/)：DNSを含むサーバー群をまとめて点検する際の進め方です。 --- 出典: [BINDの脆弱性CVE-2026-94300とは：2026年10月の4件の対象版と確認コマンド・更新手順]()（株式会社一創）