DNS サーバーの定番である BIND 9 の named に、サービス停止や遠隔コード実行（RCE）につながりうる BIND 脆弱性 CVE-2026-94300 が公表されました。2026年10月22日に JPRS が緊急の注意喚起を出し、開発元の ISC が勧告とパッチを公開しています。依存関係から入る攻撃と防御の全体像はサプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説にまとめています。この記事は、自分の BIND が対象か、どの版に上げるかを一次情報の版番号で整理します。
WHAT HAPPENED2026年10月の経過
BIND 9 の GSS-TSIG に欠陥。回避策は無く、対策は更新だけ
-
10/22 JPRS が緊急の注意喚起
named のメモリ破壊の恐れを公表
-
ISC が勧告とパッチを公開
深刻度は High
-
対象は 9.11.0 以降
9.18 系は修正版なし
-
対策は更新一択
9.20.30 / 9.21.27 へ
30秒でわかる CVE-2026-94300
・BIND 9 の GSS-TSIG（RFC 3645）の実装に欠陥。署名した UDP メッセージを再送すると named のメモリが壊れ、条件次第で RCE に至る恐れ
・対象は 9.11.0〜9.18.50 / 9.20.0〜9.20.29 / 9.21.0〜9.21.26。修正版は 9.20.30（安定版）と 9.21.27（開発版）
・9.18 系はサポート終了で修正版なし。9.20.30 へ上げる
・一時的な回避策は無い。解決策は更新だけ
まずやること
・named -v で自分の BIND の版を確かめ、下の早見表で系列ごとの上げ先を見る
・GSS-TSIG（tkey-gssapi-keytab など）を設定しているか確認する。設定している構成が主な対象
・配布元（ディストリやベンダー）の修正パッケージが出ていれば、それに上げる。回避策は無いので更新を急ぐ
BIND 脆弱性 CVE-2026-94300 とは｜GSS-TSIG の実装不具合
CVE-2026-94300 は、DNS サーバー BIND 9 の named が持つ GSS-TSIG の実装不具合です。GSS-TSIG（RFC 3645）は、Kerberos や Active Directory と連携して DNS のやり取りに電子署名を付ける仕組みで、主に動的更新の認証に使われます。
ISC の勧告によれば、GSS-TSIG で署名した UDP メッセージを再送すると、named のメモリ破壊を誘発できます。原因は、TKEY で折衝した GSS-TSIG のセッションが、その鍵で署名・検証するすべてのメッセージで共有されていた点にあり、修正はそのアクセスを直列化（serialize）するものです。外部の攻撃者が制御するゾーンへ細工した問い合わせを送ることで、RCE に至る恐れがあるとされています。
HOW IT BREAKS欠陥の仕組み
署名したメッセージの再送で named のメモリが壊れる
-
GSS-TSIG で署名
TKEY で折衝した鍵
-
同じ UDP を再送
鍵を共有したまま
-
named のメモリ破壊
アクセスが直列化されず競合
-
条件次第で RCE
DNS 停止の恐れ
深刻度は ISC が「High」としています。別の評価では CVSS 8.1・攻撃の難易度（complexity）は High という見方もありますが、CVSS の具体値は ISC が公表した値ではないため、基本は ISC の High を見てください。攻撃者が再送をどう組み立てるか、ゾーンをどう細工するかといった具体的な手順は、安全のため扱いません。自分の BIND を守るのに要るのは、仕組みの概略と、対象かどうかの見分け方、そして更新です。
対象バージョンと修正版｜BIND の系列ごとの上げ先
ISC の勧告では、対象は BIND 9.11.0〜9.18.50 / 9.20.0〜9.20.29 / 9.21.0〜9.21.26 です。JPRS はこれを「9.11.0 以降のすべて」と表現しています。Supported Preview Edition は -S1 相当が対象です。
気をつけたいのは、上げ先が系列ごとに違うことです。ISC の指針は「現在の版に最も近いパッチリリースへ上げる」で、修正版は 9.20.30（安定版）と 9.21.27（開発版）、プレビュー向けの 9.20.30-S1 です。そして 9.18 系には修正版がありません。9.18.50 は影響範囲に入りますが、ISC はサポート終了（EOL）の系列にセキュリティパッチを出さないと明言しているため、9.18 系の利用者は 9.20.30 へ上げる必要があります。
WHERE TO UPGRADE系列ごとの上げ先
いまの系列ごとに上げ先が違う。9.18 系に修正版は無い
いまの系列
上げ先（修正版）
いまの系列: 9.20 系（〜9.20.29）
上げ先（修正版）: 9.20.30（安定版）
いまの系列: 9.21 系（〜9.21.26）
上げ先（修正版）: 9.21.27（開発版）
いまの系列: 9.18 系（〜9.18.50・EOL）
上げ先（修正版）: 修正版なし → 9.20.30 へ
いまの系列: 9.11〜9.17 系
上げ先（修正版）: 9.20.30 へ
| いまの系列 | 状態 | 上げ先（修正版） |
|---|---|---|
| 9.21 系（〜9.21.26） | 開発版 | 9.21.27 |
| 9.20 系（〜9.20.29） | 安定版 | 9.20.30 |
| 9.18 系（〜9.18.50） | EOL・修正版なし | 9.20.30 へ移行 |
| 9.11〜9.17 系 | 旧系列 | 9.20.30 へ移行 |
| Supported Preview | -S1 | 9.20.30-S1 |
一時的な回避策は無く、解決策は更新だけです。JPRS・ISC のどちらも設定変更などの回避策を示していません。配布元（Debian・Ubuntu・Red Hat など）が独自番号で修正を取り込む場合もあるので、パッケージで入れているなら配布元の修正版を待って上げます。
自分の BIND を確認する｜バージョンと GSS-TSIG 設定
最初に、動かしている named の版を確かめます。上流の版番号をそのまま使うパッケージなら、上の早見表と見比べられます。
# 1. named 本体の版を確認する
named -v
# 例: BIND 9.20.29-Debian
# パッケージからも確認できる（配布元の番号で入っている場合）
dpkg -l 'bind9*' 2>/dev/null | grep '^ii' # Debian / Ubuntu
rpm -q bind 2>/dev/null # RHEL 系
docker exec my-bind named -v 2>/dev/null # コンテナで動かしている場合
パッケージで入れている場合、版番号の読み方に注意が要ります。Debian や Ubuntu、Red Hat 系は上流の 9.20.30 のような番号ではなく 1:9.20.29-1 や 9.16.23-18.el9 のように配布元の番号で修正を取り込むことがあります。この場合、上流の版番号だけでは対策済みか判断できません。配布元が CVE-2026-94300 を修正したパッケージを出しているか、各ディストリのセキュリティ情報（Debian Security Advisory、Ubuntu Security Notice、Red Hat の Errata など）で確かめてください。コンテナで動かしているなら、ベースイメージを修正版に差し替えて作り直します。
次に、GSS-TSIG を設定しているかを確認します。これは構成の確認であって、脆弱性の判定ではありません。設定の展開まで含めて見るには named-checkconf -p の出力を、ファイルを直接見るには grep を使います。
# 2. GSS-TSIG を設定しているか確認する（構成の確認。判定ではない）
named-checkconf -p 2>/dev/null | grep -E 'tkey-gssapi-keytab|tkey-gssapi-credential|update-policy'
# 設定ファイルを直接見る場合（置き場所は環境で異なる）
grep -REn 'tkey-gssapi' /etc/bind/ /etc/named* 2>/dev/null
結果の読み方です。tkey-gssapi-keytab や tkey-gssapi-credential が出れば、GSS-TSIG を使った構成です。何も出なくても、この確認だけでは「安全」とは言い切れません。設定ファイルが別の場所にある、include で読み込んでいる、といった取りこぼしがあり得るためです。最終的に自分の構成が対象かは、下の節のとおり ISC の勧告と配布元の告知で確かめてください。
検証の範囲：本記事の確認コマンドのうち、GSS-TSIG 設定を探す grep は、設定を書いたサンプルの named.conf と、書いていない named.conf の両方で陽性・陰性を確かめました。named -v や dpkg / rpm は BIND を導入した環境での実行は未検証で、出力例から読み方を示しています。版の最終的な判断は配布元の情報と合わせて行ってください。
GSS-TSIG とは何か・影響範囲
GSS-TSIG は Kerberos の認証情報を使って DNS のトランザクションに署名を付ける仕組みです。Active Directory 連携の動的更新などで使われ、BIND では tkey-gssapi-keytab や tkey-gssapi-credential、update-policy を明示的に設定した構成で有効になります。多くの一般的なキャッシュ DNS や権威 DNS では、GSS-TSIG を設定していないことも多いです。
ただし、「設定していないから既定で安全」と、この脆弱性に対して断定はできません。過去の GSS-TSIG の脆弱性（CVE-2020-8625・CVE-2021-25216）は「既定構成では脆弱な経路に到達しない」とされましたが、CVE-2026-94300 が同じく既定なら影響しないかは、公開情報の範囲では確認できていません。GSS-TSIG を設定している構成が主な対象、という理解にとどめ、確実な適用条件は ISC の勧告と配布元の告知で確かめてください。
攻撃者の前提も押さえておきます。この経路を突くには、外部の攻撃者が制御するゾーンへ細工した問い合わせを named に処理させ、署名したメッセージを再送できる必要があります。言い換えると、GSS-TSIG を外部からのやり取りで使っている構成ほど距離が近く、内部に閉じた構成は相対的に遠いと考えられます。それでも回避策は無いため、対象の系列なら更新してください。
まだ分かっていないこと・まとめ
公表されている情報の範囲では、既定構成での影響の有無という適用条件が曖昧なままです。ここを埋めるのは推測ではなく、ISC の勧告原文と、各ディストリ・ベンダーのセキュリティ情報です。確認日を添えて一次情報を見てください。
やることはシンプルです。対象の系列（9.11.0 以降のすべて）なら、系列ごとの修正版へ更新する。回避策は無いので、GSS-TSIG を使っているかどうかに関わらず、更新を先延ばしにしないのが安全側の判断です。更新したら named を再起動または再読み込みし、named -v で版が修正版に上がったことを確かめます。パッケージ更新では自動で再起動されないこともあるため、プロセスが古いバイナリのまま動いていないかも見てください。権威 DNS を冗長構成にしている場合は、1台ずつ更新して解決が止まらないようにします。メモリ破壊を突く類の脆弱性の確認手順は、fraggap（CVE-2026-53362）Linux カーネル UDPv6 の OOBやnginx の CVE-2026 系の対応でも整理しています。更新を軸にした対応の型はPHP の脆弱性と更新の考え方も参考にしてください。
参照ソース
・JPRS 注意喚起「(緊急)BIND 9.xの脆弱性（CVE-2026-94300）について」：https://jprs.jp/tech/security/2026-10-22-bind9-cve-2026-94300.html
・ISC Knowledge Base CVE-2026-94300：https://kb.isc.org/docs/cve-2026-94300
・修正版パッチ（BIND 9.20.30）：https://ftp.isc.org/isc/bind9/9.20.30/
・CVE Record CVE-2026-94300：https://www.cve.org/CVERecord?id=CVE-2026-94300
