BIND 9の脆弱性4件(CVE-2026-94300ほか、2026年10月)|9.20.30への更新、対象のバージョンと9.18系の扱い

BIND 9の脆弱性4件のアイキャッチ。ISCが2026年10月21日に公表、9.20.30に更新する。4件とも深刻度は「高」で回避策はなく直す方法は更新、対象のバージョンは9.11.0〜9.18.50・9.20.0〜9.20.29・9.21.0〜9.21.26、直ったバージョンは9.20.30(開発バージョンの9.21系は9.21.27)、9.18系はISCの修正が出ないので9.20.30かディストリビューションの更新へ、の4つを示す図

BIND 9を動かしているDNSサーバーは、BIND 9.20.30か、ディストリビューションが出す修正済みのパッケージに更新してください。ISCが2026年10月21日に公表した脆弱性4件は、どれも深刻度「高(High)」で、ネットワークの外から突かれるおそれがあり、回避策がありません。

目次

結論:9.20.30に更新する。9.18系はもう直らない

  • 直った脆弱性:CVE-2026-94300・CVE-2026-19630・CVE-2026-96888・CVE-2026-97313の4件。ISCの評価はどれも深刻度「高(High)」
  • いちばん重いもの:CVE-2026-94300(CVSS 8.1)。namedのメモリが壊れ、止まるか、リモートでコードを実行されるおそれがあります
  • 対象のバージョン:BIND 9.11.0〜9.18.50、9.20.0〜9.20.29、9.21.0〜9.21.26(CVE-2026-96888とCVE-2026-97313は9.16.0から)
  • 直ったバージョン:BIND 9.20.30(安定バージョン)と9.21.27(開発バージョン)。ISCのサポート契約の顧客向けのエディション(BIND Supported Preview Edition)は9.20.30-S1
  • 9.18系:ISCは2026年6月17日に出した9.18.50を9.18系の最後のメンテナンスバージョンとし、9.18系のサポートはそこで終わっています。9.18系の修正バージョンは出ていません。9.20.30に上げるか、ディストリビューションの更新を当てます
  • 回避策:4件とも、ISCは「知られている回避策はない」としています
  • 悪用:4件とも、ISCは「悪用は確認していない」としています

直った脆弱性4件

ISCのアドバイザリとBIND 9.20.30のリリースノートをもとにした一覧です。

CVE・CVSS 何が起きるか・対象になる条件
CVE-2026-94300
CVSS 8.1
GSS-TSIGで署名したメッセージの扱いの不具合で、namedのメモリが壊れる。止まるか、リモートでコードを実行されるおそれ
対象になる条件:9.11.0〜9.18.50、9.20.0〜9.20.29、9.21.0〜9.21.26(設定による条件はアドバイザリに書かれていない)
CVE-2026-19630
CVSS 7.5
細工したDNSメッセージで、CPUとメモリを使い切らされ、サービスが止まる
対象になる条件:BINDをリゾルバー(キャッシュDNSサーバー)として使っている場合
CVE-2026-96888
CVSS 7.5
リダイレクトの処理中にnamedが異常終了する
対象になる条件:リゾルバーで「redirect」ゾーンと「qname-minimization strict」の両方を設定している場合
CVE-2026-97313
CVSS 7.5
RPZが始めた問い合わせの続きの処理でnamedが異常終了する
対象になる条件:再帰問い合わせを受け付け、RPZのゾーンを2つ以上置き、1つが「recursive-only yes」(初期値)、もう1つが「recursive-only no」の場合

CVE-2026-94300:GSS-TSIGでメモリが壊れる(CVSS 8.1)

GSS-TSIGは、Kerberosなどの認証(GSS-API)を使って、DNSのやりとりに署名する仕組みです。JPRSの説明では、BIND 9のGSS-TSIGの実装の不具合で、namedのメモリが壊れることがあり、リモートコード実行に至るおそれがあります。

リリースノートによると、TKEYで決めたGSS-TSIGのセッションは、その鍵で署名・検証するすべてのメッセージで共有されていました。namedはこのセッションへの同時のアクセスを順番に並べておらず、同時に届いた署名つきのメッセージでKerberosの状態が壊れ、namedが止まることがありました。9.20.30では、共有のセッションへのアクセスを順番に処理するように直っています。

ISCは社内のテストでこの不具合を見つけていて、OpenAIのDave Aitel氏も別に見つけて報告した、と書いています。

CVE-2026-19630:細工したメッセージでCPUとメモリを使い切る(CVSS 7.5)

BINDのリゾルバーは、ある構造を持ったDNSメッセージを受け取ると追加の処理をしますが、その量に上限がありませんでした。その構造をたくさん詰めたメッセージを送られると、CPUの時間とメモリを使い切り、サービスが止まるおそれがあります。

リリースノートでは、圧縮された名前を展開する量に上限を設け、上限を超えたメッセージにはFORMERRを返すように直したとしています。ふつうの通信は、ゾーン転送や動的更新を含めて上限に届かない、とも書かれています。

CVE-2026-96888:redirectゾーンとstrictのQNAME minimizationで落ちる(CVSS 7.5)

「redirect」ゾーンと「qname-minimization strict」の両方を設定したリゾルバーで、リダイレクトの処理中にnamedが異常終了することがあります。リリースノートでは、NXDOMAINの応答を処理するときに起きるとしています。

CVE-2026-97313:RPZの特定の設定で落ちる(CVSS 7.5)

再帰問い合わせを受け付けるBINDで、再帰を求める問い合わせのあとに再帰を求めない問い合わせが届くと、namedが異常終了することがあります。ISCによると、対象になるのは、再帰問い合わせを受け付けていて、RPZのゾーンを2つ以上設定し、その1つが「recursive-only yes」(初期値)、もう1つが「recursive-only no」になっている場合です。JPRSも、RPZを該当する設定で使っている場合だけが対象だとしています。

自分のサーバーが対象か確かめる

BINDのバージョンを見る

named -v

ISCのソースから入れた場合、表示されたバージョンが9.11.0〜9.18.50、9.20.0〜9.20.29、9.21.0〜9.21.26のどれかなら、CVE-2026-94300とCVE-2026-19630の対象です。

ディストリビューションのパッケージで入れたBINDは、修正をあとから取り込んでいても、表示されるバージョンが9.20.30より古いままのことがあります。JPRSは、ディストリビューションのベンダーが出す情報も集めて対応するよう勧めています。パッケージで入れた場合は、使っているディストリビューションのセキュリティ情報で、4つのCVEが直った更新が出ているかを確かめてください。

設定でredirectゾーンとRPZを使っているか見る

CVE-2026-96888とCVE-2026-97313は、特定の設定のときだけ対象になります。named-checkconfの -p は、エラーが見つからなかったときにだけ設定を表示するので、まず設定にエラーがないことを確かめます。最後に0が表示されれば、次に進めます。

named-checkconf; echo $?

-p で、読み込まれる設定(includeしたファイルを含む)をまとめて表示し、redirectとQNAME minimizationの設定を探します。-x を付けると、鍵などの秘密の値は「?」に置き換わって表示されます。

named-checkconf -px | grep -E 'type redirect|nxdomain-redirect|qname-minimization'

RPZは、response-policy のブロックごと表示します。こうすると、recursive-only を書いていないゾーンも表示されます。

named-checkconf -px | sed -n '/response-policy {/,/};/p'
  • type redirect のゾーンか nxdomain-redirect の設定があり、qname-minimization strict もある:CVE-2026-96888の対象になりうる(ISCはredirectゾーン、JPRSは nxdomain-redirect と説明)
  • response-policy の中にゾーンが2つ以上あり、recursive-only no のゾーンと、指定のないゾーン(初期値のyes)か recursive-only yes のゾーンの両方があり、再帰問い合わせを受け付けている:CVE-2026-97313の対象

どちらの設定もなくても、CVE-2026-94300とCVE-2026-19630の対象かどうかはバージョンで決まります。4件とも、直す方法は更新です。迷ったら更新してください。

9.20.30に更新する

ISCは「今のバージョンにいちばん近い修正バージョンに上げる」よう書いていて、BIND 9の安定バージョンでは9.20.30です。9.21系(開発バージョン)を使っている場合は9.21.27です。

  • ディストリビューションのパッケージで入れた場合:ディストリビューションが出す更新を当てます
  • ISCのソースから入れた場合:ISCのダウンロードページから9.20.30を入れます

ISCのダウンロードページでは、BINDのパッケージの入手先として、Copr(RHEL・CentOS・Fedora向け)、Launchpad(Ubuntu向け)、Debianのパッケージのサイト、Dockerが案内されています。

更新してnamedを起動し直したら、もう一度バージョンを確かめます。

named -v

9.18系を使っている場合

ISCは、2026年6月17日に出した9.18.50を9.18系の最後のメンテナンスバージョンとし、9.18系のサポートはそこで終わっています(ダウンロードページの状態も「EOL」)。ISCはサポート中の系列にしか修正を出さず、今回のアドバイザリの直ったバージョンにも9.18系は入っていません。JPRSも、ISCはサポートを終えた系列のセキュリティパッチを出さない、と書いています。

9.18系のBINDは、9.20.30に上げるか、ディストリビューションが自分のパッケージで直した更新を当てる必要があります。9.20系は延長サポートの安定バージョン(ESV)で、ISCのダウンロードページではサポートは2028年第2四半期までです。

9.20系では設定の書き方が変わった部分があります(たとえば、設定のいちばん外側に書く primaries や parental-agents のブロックは、9.20.5から remote-servers という名前に変えるよう勧められています)。9.18系から上げるときは、9.20のリリースノートで変わった点を見てから、named-checkconf で設定を確かめてください。

named-checkconf; echo $?

named-checkconfは、エラーが見つかると終了ステータス1を、見つからなければ0を返します。最後に0が表示されれば、設定の書き方にエラーはありません。

よくある質問

権威DNSサーバーだけなら関係ない?

CVE-2026-19630・CVE-2026-96888・CVE-2026-97313は、ISCの説明ではリゾルバーや再帰問い合わせを受け付けるサーバーで起きるものです。CVE-2026-94300は、アドバイザリで役割による区別がされていません。どの使い方でも、対象のバージョンなら更新してください。

すぐ更新できないときの回避策は?

4件とも、ISCは「知られている回避策はない」としています。JPRSも、CVE-2026-94300について一時的な回避策はないと書いています。

9.20.29で直った9月の脆弱性とは別?

別です。2026年9月16日に公表された脆弱性は9.20.29で直っていて、今回の4件は9.20.30で直りました。9.20.29より前のバージョンなら、9.20.30に上げれば両方が直ります。

DNSのしくみそのものは、DNSとは?ドメイン名がIPアドレスに変わる仕組みと、サイトが開けないときの確認方法にあります。サーバーの更新を含めた対策の順番は、メールサーバーのセキュリティ対策|やる順番と確認コマンドでもふれています。

参考(一次情報)

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

社内エンジニアとして、SREとセキュリティの仕事をしています。サーバーの構築や運用、クラウド環境の設計にも関わってきました。趣味はゲームと漫画・アニメ。

コメント

コメントする

目次