CVE-2025-40775とは｜BIND 9.20/9.21がTSIG不正でnamedを停止するDoSの対象版・修正版と確認手順

CVE-2025-40775は、ISC BIND 9の権威サーバーとフルリゾルバの両方に影響するサービス運用妨害（DoS）の脆弱性です。DNSメッセージに付いたトランザクション署名（TSIG）のアルゴリズム欄に不正な値が入っていると、BINDはアサーション失敗でnamedプロセスを即座に止めます。影響するのはBIND 9.20.0〜9.20.8と9.21.0〜9.21.7で、9.18系は脆弱なコードを含まず対象外です。TSIGを設定していないサーバーも対象になります。

この記事では、ISCとOSベンダーの一次情報をもとに、影響範囲・CVSS・ディストリビューションごとの状況・確認コマンド・更新方針を整理します。修正版9.20.9を当てた後に追うべき9.20.30までの修正リリースと、2026年10月にCISAのKEVへ追加された旧CVE-2015-5477も扱います（2026年10月30日時点）。

まとめ：CVE-2025-40775の対策は修正版への更新のみ

• 何が起きるか：不正なTSIGアルゴリズムを含むDNSメッセージ1つでnamedが停止する。認証は要らず、遠隔から到達できる。
• 影響版：BIND 9.20.0〜9.20.8、9.21.0〜9.21.7。9.18系は非該当。権威サーバーもリゾルバも対象で、TSIG未使用でも対象。
• 修正版：9.20.9／9.21.8（2025年5月21日公開）。回避策は無く、named.confのACLでも軽減できない。
• 深刻度：ISCは「High」、CVSS 3.1は7.5。失われるのは可用性だけで、情報漏えいや改ざんは伴わない。
• OSパッケージ：RHEL 6〜10、Amazon Linux 1／2／2023、Debian 12、Ubuntu 24.04 LTSは影響なし。9.20系を載せたDebian 13とUbuntu 24.10／25.04は修正済み。
• 悪用状況：ISCの内部テストで発見。KEVには2026年10月29日版でも未収録だが、GitHubにはクラッシュを再現するデモ環境が公開されている。
• 今の推奨版：9.20.9で止めず、2026年10月21日公開の9.20.30まで上げる。9.20.11〜9.20.30の間に、通常版で42件のCVEが修正されている。

CVE-2025-40775の仕組み：TSIGのアルゴリズム欄の不正値によるnamedの停止

TSIG（Transaction Signature）はRFC 8945で定義された仕組みで、ゾーン転送・NOTIFY・Dynamic UpdateなどのDNS通信に共有鍵の署名を付けます。ISCのアドバイザリによると、BINDはTSIGを含むメッセージを受け取ると必ず検査します。アルゴリズム欄に不正な値があると、エラーとして捨てずにアサーション（内部の整合性チェック）で異常終了します。

攻撃の前提条件は軽く、CVSSベクトル AV:N/AC:L/PR:N/UI:N のとおり、ネットワーク越しに権限も特別な条件も無しで成立します。攻撃者はTSIGの共有鍵を知らなくてよく、署名の正当性を確かめる前に落ちます。JPRSの緊急情報は、外部から問い合わせパケットを1つ送るだけでnamedを異常終了させられること、TSIGを設定・利用していない場合も対象になることを明記しています。「TSIGを使っていないから関係ない」は誤判定です。

一方でC:N／I:N（機密性・完全性への影響なし）なので、起きるのはプロセスの停止に限られます。停止時にはassertion failureのメッセージがログに残ります。ただしアサーション失敗は他の不具合でも起きるため、ログは手掛かりにとどまり、該当するかは版番号と合わせて判断します。

弱点の分類は情報源で異なります。NVD（CNAはISC）は未定義値の不適切な処理を示すCWE-232、Red Hatはアサーション到達を示すCWE-617です。同じ現象を入力側と結果側から見た違いで、分類の読み方はCVEとCWEの違いとCVSSの読み方で整理しています。Red Hatは自社製品を「影響なし」としながら、上流の利用者向けの深刻度を「Important」としました。理由として、単一クエリの処理を誤らせるのではなく、TSIG検証経路でnamedデーモン全体が落ちる点を挙げています。

影響を受けるBINDのバージョンと修正版、主要ディストリビューションの状況

ISCの系列ごとの影響版と修正版

ISCのアドバイザリ（文書版2.0）が示す対象版と修正版は次のとおりです。改訂履歴では、2025年5月14日に事前通知、5月19日に対象版の記載を明確化、5月21日に一般公開されています。

9.18.0より前の版は評価されていません。ISCのダウンロードページは2026年10月30日時点で、9.20.30をCurrent Stable（ESV、2026年10月リリース、EOL予定2028年第2四半期）、9.18.50をEOL（2026年6月リリース）、9.21.27をDevelopmentと表示しています。本番の移行先は9.20系です。

RHEL・Amazon Linux・Debian・Ubuntuのパッケージ版で見る対応状況

エンタープライズ系の多くは9.18系以前をベースにしているため「影響なし」です。9.20系を採用した比較的新しいリリースだけが修正を必要としました。Red Hat、Amazon Linux Security Center、Debianのトラッカー、Ubuntuのトラッカーの記載は次のとおりです。

Ubuntu 25.04の修正版は、上流の版番号が9.20.4のままです。修正だけをバックポートしているため、版番号を上流の影響範囲と突き合わせると「影響あり」に見えます。ディストリビューションの判定は、トラッカーのパッケージ版で行ってください。Ubuntuのトラッカーには25.10と26.04 LTSの行がありませんが、Launchpadの公開版はそれぞれ9.20.11と9.20.24ベースで、いずれも上流の修正版9.20.9より新しい版です。

named -vとパッケージ版で影響の有無を確かめる手順

まず実行ファイルの版を確認します。named -vが返すのはPATH上のバイナリの版です。サービスが別のパスのバイナリを使う環境では、systemdのユニットファイルにある実行パスと突き合わせてください。

named -v
# 出力例: BIND 9.20.8 (Stable Release) ...
# パッケージ管理下なら導入済みパッケージの版も見る
rpm -q bind bind9.18          # RHEL / AlmaLinux / Rocky / Amazon Linux
dpkg -l bind9 | grep '^ii'    # Debian / Ubuntu

ソースからビルドしたBINDやISC公式パッケージなら、上流の版番号で判定できます。版番号を文字列のまま比べると「9.20.10は9.20.9より小さい」と誤判定するため、sort -Vで比較します。次のスクリプトは、named -vの出力やパッケージの版文字列からepoch（1:）と接尾辞を落として上流の版番号だけを取り出し、影響範囲と比べます。版番号として読めない入力は「判定不能」として終了コード2で止まり、安全側の判定に流れません。境界値の9.20.8／9.21.7は「影響範囲」、9.20.9／9.20.10／9.21.8は「影響範囲外」と出ます。

#!/bin/sh
# 上流の版番号で CVE-2025-40775 の該当範囲を判定する（ディストリ版はトラッカーで確認）
v="${1:-$(named -v | awk '{print $2}')}"
v="${v#*:}"    # 1:9.20.4-3ubuntu1.1 のようなepochを落とす
v="${v%%-*}"   # -3ubuntu1.1 や -S1 の接尾辞を落とす
if ! printf '%s\n' "$v" | grep -Eq '^9\.[0-9]+\.[0-9]+$'; then
  echo "$v: 版番号を読み取れないため判定不能"; exit 2
fi
in_range() { [ "$(printf '%s\n%s\n' "$2" "$1" | sort -V | head -n1)" = "$2" ] && [ "$(printf '%s\n%s\n' "$1" "$3" | sort -V | head -n1)" = "$1" ]; }
if in_range "$v" 9.20.0 9.20.8 || in_range "$v" 9.21.0 9.21.7; then
  echo "$v: CVE-2025-40775 の影響範囲"
else
  echo "$v: CVE-2025-40775 の影響範囲外"
fi

このスクリプトは上流の版番号だけを見るので、Ubuntu 25.04の修正済みパッケージの版文字列（1:9.20.4-3ubuntu1.1）を渡すと、上流版9.20.4として「影響範囲」と表示します。安全側に倒れる誤判定ですが、ディストリビューションのパッケージは前掲のトラッカーで最終判断してください。

稼働中のサーバーに外部から版を問い合わせるならdig @192.0.2.53 version.bind chaos txtが使えます。ただし応答はnamed.confのversion設定で任意の文字列に変えられるため、確定には使いません。digの読み方は名前解決の仕組みとdig・nslookupでの確認方法を参照してください。すでに停止が起きていないかは、ログのassertion failureを手掛かりに確かめます。

journalctl -u named --since "2025-05-21" | grep -i "assertion failure"

公開PoCで本番サーバーを「脆弱性テスト」しない理由

GitHubには、CVE-2025-40775を使うデモ環境のリポジトリ（AlexSvobo/nhi-zero-trust-bypass、2025年5月23日作成）が公開されています。READMEによると、Scapyで不正なTSIGを持つDNSパケットを作り、Docker上のBIND 9.20.8を停止させたうえで、DNS停止がシークレットのローテーション失敗につながる流れを示す構成です。

このパケットは「該当すればnamedが落ちる」ものなので、本番の権威サーバーやリゾルバに投げれば、それ自体がサービス停止になります。該当確認は上の版確認とトラッカーで足ります。挙動を見たいときは、隔離した検証環境で9.20.8と修正版を並べて試すにとどめてください。外部の脆弱性スキャナーを使う場合も、多くは版の応答（version.bind）で判定しており、版を隠している環境では見逃しも誤検知も起きます。

回避策の無いCVE-2025-40775への対応：修正版への更新とACLの限界

ISCのアドバイザリは「既知の回避策なし（No workarounds known）」と明記しています。TSIG処理を止める設定は無く、修正版への更新が唯一の対応です。

• ソースビルド／ISC公式パッケージ：修正の下限は9.20.9、9.21系は9.21.8。9.21系は開発版なので本番には据えず、9.20系の最新版（2026年10月30日時点で9.20.30）へ上げる。
• ディストリビューションのパッケージ：OSのセキュリティ更新を適用し、トラッカーで「修正済み」とされた版以降か確認する。更新後はnamed（Debian系の旧名はbind9、RHELのchroot構成はnamed-chroot）を再起動する。

JPRSは、named.confのACLや設定オプションの変更では影響を回避・軽減できないとしています。allow-queryで問い合わせ元を絞っても、メッセージを受け取ってTSIGを検査する段階で落ちるためです。効果があるのは、社内専用のリゾルバのように、ファイアウォールで外部からUDP・TCPの53番への到達そのものを遮断できる構成に限られます。権威サーバーやISPのリゾルバのように不特定多数から受ける構成では、更新以外に手はありません。versionオプションで版を隠すことも、攻撃が版の開示に依存しないため緩和になりません。

国内では、IPAの注意喚起「BIND 9の脆弱性対策について（CVE-2025-40775）」が2025年5月23日に公開され（5月30日に影響範囲の記載を更新）、DNSサーバー管理者にアップグレードを求めています。

9.20.9適用後も続くBIND 9.20系の修正リリースと追従の単位

9.20.9を当てても、9.20系の運用はそこで安全に固定されません。ISCの脆弱性マトリクスを見ると、9.20.9の後も脆弱性修正を含むリリースが続いています。追う単位をCVE番号ではなく安定系列のマイナーリリースに置き、系列の最新版へ追従するほうが取りこぼしません。

同じ2025年7月16日の行にはCVE-2025-40776もありますが、これはEDNS Client Subnetを使えるSubscription Edition（9.20.11-S1）だけの修正で、通常版のBINDは対象外です。マトリクスの行を数えるとき、-S1版だけの行を含めると件数が1件ずれます。通常版で9.20.11から9.20.30までに修正されたCVEは計42件です。

マトリクスには、9.20.14（2025年10月8日）、9.20.25（2026年7月20日）、9.20.28（2026年9月8日）がリリース撤回（Release Withdrawn）と記録されています。撤回版で止まっている環境は、その次の修正版まで上げます。

9.18系は2026年6月リリースの9.18.50が最終版で、ダウンロードページではEOL（2026年第2四半期）と表示されています。ISCのアドバイザリは「現在サポートしている版にしか修正を出さない」と明記しており、9.18系に新しい修正版は出ません。ただしRHEL 9やDebian 12のように9.18系を載せるディストリビューションでは、OSのサポート期間中はベンダーが修正をバックポートします。ISC版を直接使っているなら9.20系へ、ディストリビューション版ならOSのサポート状況に従う、という分け方になります。

2026年10月の続報：9.20.30の4件修正と旧CVE-2015-5477のKEV登録

2026年10月に入ってから、9.20系の運用に関わる動きが2つありました。どちらもCVE-2025-40775そのものの評価は変えませんが、「9.20.9以降に上げたから終わり」という判断を見直す材料になります。

9.20.30で修正されたCVE-2026-94300ほか4件と9.18系への影響

ISCは2026年10月21日に9.20.30と9.21.27を公開し、脆弱性マトリクスではCVE-2026-19630、CVE-2026-94300、CVE-2026-96888、CVE-2026-97313の4件がこの版で修正されたと記録されています。

このうちCVE-2026-94300は、GSS-TSIGで署名されたUDPメッセージを再送されるとnamedがメモリ破損を起こす問題です。ISCは、攻撃者が自分の管理するゾーンへの細工したクエリと組み合わせれば遠隔コード実行に至る可能性があるとし、CVSS 3.1を8.1としています。対象は9.11.0〜9.18.50、9.20.0〜9.20.29、9.21.0〜9.21.26で、CVE-2025-40775では対象外だった9.18系も含まれます。Debianのトラッカーでは、Debian 13がDSA-6576-1（1:9.20.30-1~deb13u1）で修正済みになった一方、Debian 12の1:9.18.49-1~deb12u3は2026年10月30日時点で「vulnerable」のままです。4件それぞれの対象版と確認コマンドはBINDの脆弱性CVE-2026-94300ほか2026年10月の4件の対象版と更新手順にまとめています。

KEVへ2026年10月8日に追加されたTKEYのDoS、CVE-2015-5477

CISAのKnown Exploited Vulnerabilities Catalogには、2026年10月8日付でISC BINDのCVE-2015-5477が追加されました。対応期限（dueDate）は2026年10月11日で、追加から3日しかありません。期限の決まり方はBOD 26-04とは？KEVの是正期限を4変数で決める仕組みで解説しています。

ISCのアドバイザリAA-01272によると、これはTKEYクエリの処理誤りでREQUIREアサーションに到達し、namedが終了する2015年の脆弱性です。対象は9.1.0〜9.8.x、9.9.0〜9.9.7-P1、9.10.0〜9.10.2-P2で、修正版は9.9.7-P2と9.10.2-P3でした。ISCの深刻度はCritical、回避策は無く、第三者による概念実証コードの公開も当時から記載されています。

CVE-2025-40775と同じく「細工したパケット1つでアサーション失敗を起こしnamedを落とす」型ですが、対象版がまったく違います。9.20系や9.18系を使っている限りCVE-2015-5477は関係しません。問題になるのは、更新が止まった古いアプライアンスや組み込み機器に載ったBINDです。KEVの収録状況は、CISAが配布するJSONフィードで確かめられます。

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq -r '.catalogVersion, (.vulnerabilities[] | select(.product == "BIND") | [.cveID, .dateAdded, .dueDate] | @tsv)'

2026.10.29版のカタログでこの抽出をすると、BINDの行はCVE-2015-5477の1件だけで、CVE-2025-40775は収録されていません。一方、悪用の起きやすさを示すEPSSでは、CVE-2025-40775は2026年10月29日時点で0.153（パーセンタイル96.8%）と、全CVEの上位3%台に入ります。KEV未収録は更新を後回しにしてよい理由になりません。

続報を踏まえた環境別の更新判断：ISC版・ディストリ版・旧版

• ISC版の9.20系を直接使っている：9.20.30へ上げる。9.20.9〜9.20.29のどれでもCVE-2025-40775は直っているが、10月の4件の対象版に入る。4件は発動する設定条件がそれぞれ違うため、自環境に当たるかは各アドバイザリで確かめる。
• ISC版の9.18系を使っている：9.18.50はEOLで、CVE-2026-94300の修正は出ない。9.20.30へ移行する。
• ディストリビューションのパッケージを使っている：上流の版番号ではなく、各トラッカーでCVE-2026-94300などが「fixed」になった版を当てる。
• 9.10系以前が残っている：CVE-2015-5477がKEV入りしたため、機器ごとの更新・置き換えを最優先で計画する。

同じ9.20系で2026年1月に公表された別のDoS脆弱性は、CVE-2025-13878（BRID/HHITレコードでnamedが停止）の影響範囲と9.18系の扱いで扱っています。こちらは9.18系の一部（9.18.40〜9.18.43）も対象になる点が本件と異なります。DNS応答の改ざん対策まで見直すならDNSSECの仕組みと導入手順も参考になります。公開DNSを含むサーバー群の版管理と診断を外部に任せたい場合は、一創の脆弱性診断・セキュリティ診断で、対象サーバーの洗い出しから修正版適用後の確認まで相談できます。

よくある質問

CVE-2025-40775の影響判断と更新の場面で出やすい質問をまとめます。

CVE-2025-40775は認証なしで悪用できますか？

できます。CVSSベクトルのPR:Nが示すとおり、攻撃者はTSIGの共有鍵を持っている必要がありません。BINDは署名の正当性を確かめる前に、アルゴリズム欄の不正値で停止します。JPRSは、外部から問い合わせパケットを1つ送るだけでnamedを異常終了させられると説明しています。

TSIGを使っていないサーバーも影響を受けますか？

影響を受けます。BINDは受信したメッセージにTSIGが含まれていれば、自分がTSIGを設定しているかどうかに関係なく検査します。JPRSも「TSIGを設定・利用していない場合も対象」と明記しています。9.20.0〜9.20.8または9.21.0〜9.21.7を使っているなら、TSIGの設定有無にかかわらず更新が必要です。

BIND 9.18と9.20で影響は違いますか？9.18系は更新が必要ですか？

CVE-2025-40775では違いがあり、9.18系は脆弱なコードを含まないため影響を受けません（Debianのトラッカーも「Vulnerable code not present」と記載）。ただし2026年10月に公表されたCVE-2026-94300は、9.18.50までの9.18系も対象です。ISCの9.18系はEOLで修正版が出ないため、ISC版を直接使っているなら9.20.30への移行が必要です。RHEL 9やDebian 12の9.18系パッケージは、各トラッカーで修正済みの版が出たら適用します。

named.confのACLで問い合わせ元を絞れば防げますか？

防げません。JPRSは、named.confのACLや設定オプションの変更では影響を回避・軽減できないとしています。メッセージを受け取った時点でTSIGの検査に入るためです。効果があるのはファイアウォールで53番ポートへの到達そのものを遮断できる社内専用サーバーに限られ、公開する権威サーバーでは更新以外に手段はありません。

PoCは公開されていますか？実際に攻撃されていますか？

GitHubに、Scapyで不正なTSIGを送りDocker上のBIND 9.20.8を停止させるデモ環境が公開されています。一方、ISCは内部テストで発見したもので実際の悪用は把握していないとし、CISAのKEVにも2026年10月29日版の時点で収録されていません。遠隔・未認証で発火し、手順も公開されているため、更新は先送りにしないでください。PoCを本番サーバーに流して確かめるのは避け、版とトラッカーで判定します。

関連記事

• BINDの脆弱性CVE-2026-94300とは：2026年10月の4件の対象版と確認コマンド・更新手順
• CVE-2025-13878とは｜BIND 9のBRID/HHITレコードでnamedが停止するDoS脆弱性の対象版と対策
• 名前解決とは？DNSの仕組み・正引き/逆引き・dig/nslookupでの確認方法を実装者向けに解説
• DNSSECとは？DNSの安全性を守る仕組みと役割・導入手順をわかりやすく解説
• 脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説