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でまとめて公表されました。ISCは10月14日に事前通知を出し、21日に一般公開しています。いずれもISCの評価は「高（High）」です。

CVE-2026-94300のGSS-TSIGメモリ破損とCVSS 8.1のRCEリスク

ISCのCVE-2026-94300のアドバイザリによると、GSS-TSIGで署名されたUDPメッセージを再送されると、namedのメモリが壊れることがあります。攻撃者が再送するのは、以前に署名されたメッセージで、交渉済みのTSIG鍵がまだ有効な間です。さらに自分が管理するゾーンへの細工した問い合わせを組み合わせると、リモートコード実行に至る可能性があるとされています。

CVSS v3.1の基本値は8.1、ベクトルは AV:N/AC:H/PR:N/UI:N で始まります。ネットワーク越しにログイン不要で成立しうる一方、攻撃の難しさは「高」の評価です。ベクトルの読み方はCVSSv3のスコアの目安と計算式で確認できます。

GSS-TSIGは、Active DirectoryのドメインコントローラーやIdMがKerberosの認証付きでDNSレコードを動的に更新する仕組みです。Active DirectoryとLDAPの環境で、Windowsクライアントの名前をBINDに登録させている構成が典型の対象になります。

CVE-2026-19630・96888・97313のDoSとフルリゾルバー側の条件

残る3件はCVSS v3.1で7.5、影響はサービス停止です。いずれも問い合わせを受けて再帰検索をするフルリゾルバーの条件として書かれています。

CVE-2026-19630は設定に関係なく、対象版のリゾルバーなら当たります。9.20.30のリリースノートには、圧縮された名前の展開に上限を設け、超えたらFORMERRを返す修正と書かれています。CVE-2026-96888とCVE-2026-97313は、設定が条件に合うときだけです。

リゾルバーが止まると、社内の端末やアプリケーションの名前解決がすべて失敗します。外から大量の問い合わせを受ける構成なら、DDoS攻撃への備えと同じ視点で、どこから問い合わせを受け付けているかを見直す機会になります。

9.11.0から9.21.26までの対象範囲とISCの修正版の対応表

対象版の下限はCVEごとに違います。上限はどれも9.18.50・9.20.29・9.21.26です。

サポート契約者向けのSupported Preview Edition（-S1）は9.20.30-S1が修正版です。表の9.18系の列で修正版が「なし」なのは誤りではありません。BIND 9 Software Vulnerability Matrixも、現行の対象系列を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で確認できます。

# 設定ファイルの場所は 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の注意喚起が案内する配布物から入れている環境では、9.20.30へ上げます。9.20系の中での更新なら設定の書き換えは基本的に要りません。上げた後は前章の1と2で版を確かめ、rndc status で稼働を確認します。

ISCのパッケージリポジトリを使っている場合は、リポジトリ名に注意が要ります。ISCの9.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日に確認した結果を並べます。

出典はDebian security tracker、UbuntuのCVEページ、Red HatのCVEページです。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の検証と署名の動作も加えてください。

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の解説は1月の版、CVE-2025-40775の解説は2025年の版の話です。

年に数回の更新を前提にした体制では追いつきません。次の項目を確かめます。

• 権威とリゾルバー、プライマリとセカンダリの台数と版を一覧で持っている
• セカンダリから順に入れ替え、名前解決を止めずにnamedを更新する手順がある
• 取り下げられた版を入れていないかを、版の一覧で確かめられる

DNSは止めると社内のすべてのシステムに響く一方、外から問い合わせを受ける入口でもあります。BINDの版と設定に加えて、外から到達できるサービスの棚卸しまでまとめて行うなら、脆弱性診断・セキュリティ診断で外部に開いたポートと導入製品の版を洗い出すと、更新の優先順位を付けやすくなります。

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脆弱性と対象版・修正版：同じTSIG周りで起きた2025年のBINDの脆弱性です。
• CVE-2025-13878とは｜BIND 9のBRID/HHITレコードでnamedが停止するDoS脆弱性の対象版と対策：2026年1月の9.20.18で直ったnamedの停止の例です。
• 脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務を解説：脆弱性の公表から修正までの流れの基礎を確認できます。
• CVE（共通脆弱性識別子）とは？番号の読み方・CVSS/CWE/NVDとの違いと調べ方：CVE番号とアドバイザリの読み方を整理しています。
• 脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説：DNSを含むサーバー群をまとめて点検する際の進め方です。