CVE-2026-94300 BIND 9｜GSS-TSIG の影響と更新判断

はじめに

2026 年 10 月 21 日、ISC（Internet Systems Consortium）は BIND 9 の脆弱性 CVE-2026-94300 を公開しました。GSS-TSIG で署名された UDP メッセージの再送を起点に named のメモリ破損が発生し得るもので、ISC は影響としてプロセスの異常終了と、リモートコード実行（RCE）の可能性を挙げています。CVSS 3.1 のスコアは 8.1（High）です。

「RCE」という語から緊急度を高く見積もりがちですが、攻撃の成立には GSS-TSIG の利用や鍵の有効期間など複数の前提があります。一方で、2026 年 6 月に EOL となった 9.18 系には ISC の修正版が提供されないため、運用中の系列によっては単純なパッチ適用で済まない点に注意が必要です。本記事では、影響確認から更新完了までの判断に必要な情報を、ISC の一次情報に基づいて整理します。

結論として、GSS-TSIG を設定している BIND 9 を運用している場合は、最優先で 9.20.30（Supported Preview は 9.20.30-S1）への更新を計画してください。ISC が直接提供する 9.18 系以前を使っている場合は 9.20 系への移行が必要です。一方、RHEL や Debian などの OS ベンダーが提供するパッケージは修正がバックポートされる場合があるため、各ベンダーの修正済みパッケージを確認します。GSS-TSIG を使っていない環境でも、リゾルバであれば同時公開の CVE-2026-19630 に該当する可能性があるため、更新計画自体は必要です。

CVE-2026-94300 の概要と RCE の成立条件

CVE-2026-94300 は、GSS-TSIG のセッションに対する同時アクセスの制御不備に起因するメモリ破損の脆弱性です。まず ISC が公表している主要な情報を整理します。

参考: ISC CVE-2026-94300 アドバイザリ（Impact）
“Memory corruption, leading to program abort and/or potential remote code execution.”
（メモリ破損により、プログラムの異常終了や、リモートコード実行の可能性につながる。）
https://kb.isc.org/docs/cve-2026-94300

ISC の表現は「potential（可能性）」であり、異常終了が主な影響として確実に想定される一方、コード実行は条件次第で到達し得る結果と読むのが妥当です。メモリ破損が発生しても、それが必ず RCE につながるわけではありません。

GSS-TSIG とは（通常の TSIG との違い）

GSS-TSIG は、DNS メッセージの署名に使う鍵を Kerberos などの GSS-API で動的に確立する仕組みです。Active Directory 環境で、Windows クライアントや DHCP サーバーが Kerberos 認証付きで DNS レコードを動的更新する「セキュア動的更新」で使われることが一般的です。

TSIG

サーバー間やクライアントとの間で事前共有した秘密鍵（key ブロックで定義）を使い、DNS メッセージに署名する方式です。ゾーン転送や nsupdate による動的更新の認証で広く使われます。

TKEY

TSIG で使う鍵をサーバーとクライアントの間で交渉・確立するための DNS の仕組みです。GSS-TSIG では、TKEY の交渉で Kerberos のセキュリティコンテキストを確立します。

GSS-TSIG

TKEY で交渉した GSS-API のセッションから導出した鍵で TSIG 署名を行う方式です。事前共有鍵を配布せず、Kerberos の認証基盤を利用できます。BIND では tkey-gssapi-keytab などの設定で有効にします。

攻撃が成立する条件

ISC のアドバイザリが示す攻撃シナリオを分解すると、次の要素の組み合わせになります。

1. 対象の named で GSS-TSIG が使われており、攻撃者が過去に GSS-TSIG で署名された UDP メッセージを取得できること
2. 交渉済みの TSIG 鍵がまだ有効な間に、そのメッセージを再送できること
3. あわせて、攻撃者が制御するゾーンへの細工したクエリを送ること

根本原因について、9.20.30 のリリースノートは、TKEY で交渉した GSS-TSIG セッションがその鍵で署名・検証されるすべてのメッセージで共有されているにもかかわらず、named がセッションへのアクセスを直列化していなかったと説明しています。この結果、同時に処理される署名付きメッセージが Kerberos 側の状態を破損させ、named が予期せず終了し得るとしています。

参考: BIND 9.20.30 Release Notes（Security Fixes）
“Access to the shared session is now serialized.”
（共有セッションへのアクセスは直列化されるようになった。）
https://bind9.readthedocs.io/en/v9.20.30/notes.html

なお、ISC は「攻撃者が制御するゾーンへのクエリ」がどの処理経路を通るのか、どのサーバー役割（権威 / リゾルバ）で成立しやすいのかといった詳細を公表していません。本記事でもそれ以上の推測はせず、GSS-TSIG の利用有無を判断の起点とします。

CVSS の PR:N と前提条件の関係

CVSS ベクトルの PR:N（必要な特権なし）は、「誰でも無条件に RCE できる」という意味ではありません。攻撃者は自身の認証情報を持つ必要がなく、取得した正規の署名付きメッセージを再送する点が PR:N に反映されています。一方、署名付きメッセージの取得、鍵の有効期間内での再送、同時処理のタイミングといった攻撃者側で制御しにくい条件は、AC:H（攻撃の複雑さ: 高）として評価されています。

CVE レコードに付与された CISA の SSVC 評価は、Exploitation: none、Automatable: no、Technical Impact: total です。また Red Hat は、認証なしのコード実行があり得るとしつつ、有効期間内の鍵の取得や複雑な同時リクエストの組み立てが必要なことを理由に、深刻度を Critical ではなく Important と評価しています。Red Hat の CVE ページで評価の根拠を確認できます。

BIND 9 の影響バージョンと修正版（9.20.30）

影響範囲は 9.11.0 以降と広く、EOL の系列も含まれます。ISC が公表した影響バージョンと修正版は次のとおりです。

2026 年 10 月 21 日更新の BIND 9 Software Vulnerability Matrix では、今回の 4 件はいずれも 9.20 列で 9.20.30 が修正版として示されており、EOL となった 9.18 系の列は掲載されていません。マトリクスを使った影響確認の考え方は「BIND 9 脆弱性マトリクスの読み解き方」でも扱っていますが、同記事は 2026 年 5 月時点の脆弱性と修正版（9.18.49 / 9.20.23）を対象としており、現行のマトリクスとは表示形式も異なります。今回の修正版とは区別してご覧ください。

ISC 提供の 9.18 系はパッチ番号を上げても対応できない

9.18 系は ISC のサポートを終了しており、今回の脆弱性に対する 9.18 系の修正版は公開されていません。ISC はアドバイザリで、現在サポートしているバージョンにのみパッチを提供する方針を示しています。

参考: ISC’s Software Support Policy and Version Numbering
“was declared ESV in January, 2023 and will be EOL in June, 2026.”
（BIND 9.18 は 2023 年 1 月に ESV となり、2026 年 6 月に EOL となる。）
https://kb.isc.org/docs/aa-00896

ISC のビルドを直接運用している場合、9.18 系からの対応は 9.18.x の更新ではなく、9.20 系へのメジャーバージョン移行になります。同じ方針文書では、次の安定系列である 9.22 のリリースは少なくとも 2026 年第 4 四半期以降に延期されたとしており、2026 年 10 月 23 日確認時点で本番利用向けの移行先は 9.20 系です。移行時は、9.20 系のリリースノートに記載された削除・変更された機能と自社の named.conf を突き合わせ、検証環境で named-checkconf による構文確認を行うことを推奨します。なお、OS ベンダーが提供する 9.18 系ベースのパッケージは扱いが異なるため、次の「ディストリビューション提供パッケージの見方」で説明します。

9.21 系と Supported Preview の扱い

9.21 系は Development 系列で、ISC は新機能の試験やフィードバック用途と位置付けています。本番環境で使っている場合は 9.21.27 で今回の修正が入りますが、あわせて 9.20 系への切り替えも検討してください。Supported Preview（-S1）は ISC の有償サポート契約者向けの版で、修正版は 9.20.30-S1 のみです。入手方法は契約先の案内に従います。

ディストリビューション提供パッケージの見方

RHEL、Ubuntu、Debian などが提供する BIND パッケージは、upstream の新しい系列へ切り替えずに、セキュリティ修正を既存バージョンへバックポートすることが一般的です。バックポートの一例として、Ubuntu の USN-8929-1（2026 年 10 月 14 日）では、Ubuntu 26.04 LTS 向けの 1:9.20.24-1ubuntu0.4 が、upstream では 9.20.29 で修正された CVE への対処を含んでいます。これは upstream の 9.20.29 以前で修正済みの別の CVE 群への対応であり、今回の CVE-2026-94300 を修正したアドバイザリではありません。また RHEL 10 の bind パッケージは 9.18.33 をベースにしています。

このため、パッケージのバージョン番号を ISC の影響範囲表と照合するだけでは、修正有無を判断できません。upstream の 9.18 系が EOL であっても、ディストリビューションのサポート期間内であれば修正が提供される場合があります。判断は各ベンダーの CVE ページやセキュリティアドバイザリで行ってください。2026 年 10 月 23 日確認時点の状況は次のとおりです。

各ベンダーの対応状況は公開直後に更新されやすいため、作業前に最新の情報を確認してください。

GSS-TSIG の利用状況と影響確認

CVE-2026-94300 の影響度は、GSS-TSIG を使っているかどうかで大きく変わります。ここでは、稼働中の named のバージョンから実際の利用状況までを順に確認します。コマンドは BIND 9.20.30 の公式マニュアル（Manual Pages、Configuration Reference）に基づいています。本記事の手順は実機での検証を行っていないため、出力形式やファイルパスは環境に合わせて読み替えてください。

rndc status

named -V

rpm -qi bind

dpkg-query -W -f='${Package} ${Version}\n' 'bind9*'

named-checkconf -p -x /etc/named.conf | grep -nE 'tkey-gssapi|krb5-|ms-self|ms-sub'

journalctl -u named --since "-7 days" | grep -iE 'tkey|gss'

確認結果の読み方と限界

確認結果は次のように整理できます。ただし、これは編集部としての判断の目安であり、ISC が示した判定基準ではありません。

設定文字列が見つかることは、外部から脆弱な処理へ到達できることと同義ではありません。逆に、設定が見つからないことだけで安全と断定することもできません。確認対象外の設定ファイル、複数インスタンス、コンテナや chroot 内の別設定、構成管理ツールによる自動生成など、検索漏れの原因は環境ごとに存在します。最終的な対策は修正版への更新であり、設定確認は更新の優先順位付けに使うものと位置付けてください。

更新手順と適用後の確認

影響確認の結果を踏まえ、更新作業は次の流れで進めます。ここで示すのは編集部が推奨する一般的な運用フローであり、具体的な更新コマンドや再起動手順は、利用しているディストリビューションの公式ドキュメントに従ってください。

systemctl show named -p ActiveEnterTimestamp

rpm -q --last bind

dig @192.0.2.53 example.com SOA +norecurse

dig @192.0.2.53 www.example.net A

9.20.30 で変わる GSS-TSIG 鍵の有効期間

9.20.30 では、脆弱性修正とは別に、GSS-TSIG の鍵の扱いも変更されています。リリースノートによると、従来は TKEY の交渉で得た TSIG 鍵が最長 1 時間で失効していたため、クライアントは 1 時間ごとに TKEY 交渉をやり直す必要がありました。9.20.30 以降は、交渉したセキュリティコンテキストが有効な間は鍵を保持し、コンテキストの有効期間を判断できない場合のみ 1 時間の上限を適用します。

更新後に TKEY 交渉のログ件数が減るなど、動的更新まわりのログの傾向が変わる可能性があります。ログ監視のしきい値やアラート条件を TKEY の発生頻度で設定している場合は、更新後の傾向を確認しておくことをおすすめします。

更新までの暫定対応の位置付け

ISC はこの脆弱性について既知の回避策はないとしています。一方、Red Hat は CVE ページで、Kerberos 認証付きの動的 DNS が不要であれば GSS-TSIG を無効化すること、またはファイアウォールで DNS サービスへのアクセスを制限することを緩和策として挙げています。

これらは攻撃に必要な条件を減らす手段にはなりますが、ISC が確認した回避策ではなく、修正版への更新の代わりにはなりません。GSS-TSIG を無効化すると AD 連携の動的更新が止まるなど業務影響も大きいため、適用する場合は影響範囲を確認したうえで、更新までのつなぎとして扱ってください。

同時公開された 3 件の脆弱性

2026 年 10 月 21 日には、CVE-2026-94300 とあわせて次の 3 件も公開され、いずれも 9.20.30 / 9.21.27 / 9.20.30-S1 で修正されています。各アドバイザリとも、公表時点で既知の回避策と実際の悪用は確認されていないとしています。

影響範囲の終点は 3 件とも 9.18.50 / 9.20.29 / 9.21.26 です。GSS-TSIG を使っていない環境でも、リゾルバとして運用している BIND は CVE-2026-19630 に該当する可能性があります。一方、CVE-2026-96888 と CVE-2026-97313 は特定の設定の組み合わせが前提のため、すべての BIND サーバーで 4 件すべてが悪用可能というわけではありません。ただし、どの CVE に該当するかに関わらず修正版は同じであるため、該当する可能性が 1 件でもあれば同じ更新作業でまとめて対応できます。

まとめ

CVE-2026-94300 は RCE の可能性がある一方、GSS-TSIG の利用や鍵の有効期間内での再送など、成立には複数の前提が必要な脆弱性です。GSS-TSIG の利用状況で優先度を判断しつつ、同時公開の 3 件も含めて 9.20.30 またはベンダーの修正済みパッケージへの更新を計画することが現実的な対応です。

• GSS-TSIG の署名付き UDP メッセージの再送を起点とするメモリ破損
• RCE は可能性であり、主な影響は named の異常終了と読むのが妥当です。
• ISC 提供版の修正版は 9.20.30 で、9.18 系以前は 9.20 系へ移行します。
• ディストリビューション版は各ベンダーの修正済みパッケージで判断します。
• tkey-gssapi 設定と動的更新の利用実態で更新の優先度を判断
• 更新後は rndc status で稼働中プロセスのバージョンを確認します。
• GSS-TSIG 未使用でも、リゾルバは同時公開の CVE に該当し得ます。

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