CVE-2025-13878とは｜BIND 9のBRID/HHITレコードでnamedが停止するDoS脆弱性の対象版と対策

CVE-2025-13878は、ISC BIND 9がドローン識別用のBRIDレコード・HHITレコードを処理する際に、不正な形式のデータでnamedが異常終了するサービス運用妨害（DoS）の脆弱性です。ISCが2026年1月21日に公表し、深刻度は「High」、CVSS 3.1の基本値は7.5です。対象は9.18.40〜9.18.43、9.20.13〜9.20.17、9.21.12〜9.21.16と狭く、RHEL・Ubuntu・Amazon Linuxは影響を受けません。この記事では、対象版の判定方法、修正がBRID用・HHIT用の長さチェックを各1行直すものだった中身、9.18系がEOLとなった後の更新先を、ISC・Red Hat・各ディストリビューションの一次情報で整理します。2026年11月11日時点の情報に更新しています。

まとめ：CVE-2025-13878は9.18.40〜9.18.43と9.20.13〜9.20.17が対象

• 何が起きるか：不正な形式のBRID/HHITレコードを処理するとnamedがアサーション違反で異常終了する。認証は不要で、権威サーバーとリゾルバの両方が対象。
• 対象版：9.18.40〜9.18.43、9.20.13〜9.20.17、9.21.12〜9.21.16（Supported Preview Editionの-S1版も同範囲）。BRID/HHITに対応する前の9.18.39以前・9.20.12以前は対象外。
• 修正版：9.18.44／9.20.18／9.21.17。修正の実体はレコード長の下限チェックを>= 3から> 0へ直す各1行で、回避策は無い。
• ディストリ：RHEL 6〜10、Ubuntu 22.04／24.04／25.10、Amazon Linux 2／2023は影響なし。Debian 12は1:9.18.44-1~deb12u1以降、SUSE Linux Enterprise 15 SP7／16.0は9.20.18系、16.1は9.20.26系で修正済み。
• 悪用状況：ISCは悪用を把握していない。CISAのKEVには2026年11月10日版でも未収録、EPSSは0.094（推定確率約9.4%・全CVEの上位約5%）。
• 今の更新先：9.18系は2026年6月にEOL。ISC版を使うなら9.18.44ではなく9.20系の最新版9.20.30（2026年10月21日公表）へ上げる。

旧版からの主な訂正：旧版の「RHEL向けに更新が提供」「多くのディストリの9.18系が範囲に入る」という記述は、いずれも誤りでした。9.18系で対象なのは9.18.40〜9.18.43だけで、9.18.40は公開前の試験で回帰が見つかり撤回されたため、実際に配布されたのは9.18.41〜9.18.43の3版です。あわせて、HHIT・BRIDの説明をRFC 9886の定義に改め、ACLが効かない理由の推測（送信元アドレスの詐称）とスキャン活動の記述は一次情報に根拠が無いため削除し、版判定スクリプトにはepochの除去と入力の検証を加えました。

CVE-2025-13878の仕組み：BRID/HHITレコードでnamedが異常終了

ISCのアドバイザリは、この脆弱性を「不正な形式のBRID/HHITレコードによりnamedが予期せず終了しうる」と説明しています。攻撃者は、処理結果として壊れたレコードや悪意あるレコードを生む問い合わせを送ることでnamedを停止させられます。JVNVU#94755059は、BRID/HHITレコードの処理に問題があり、意図的にアサーション違反を起こせる脆弱性（CWE-617）と分類しています。

RFC 9886で定義されたHHIT・BRIDレコードとドローン識別DRIPの関係

DRIP（Drone Remote Identification Protocol）は無人航空機を識別するためのプロトコル群で、その識別子DET（DRIP Entity Tag）はRFC 9374で定義されています。DETをDNSで扱う方式を定めたのが2025年12月公開のRFC 9886で、ここで2つのリソースレコードが使われます。

HHITはHierarchical Host Identity Tag、BRIDはUAS Broadcast Remote IDの略です。BINDがこれらの新しい型を実装した際に、不正な形式の入力を検証しきれない不備が残っていました。

攻撃の前提条件と権威サーバー・フルリゾルバの両方が対象になる理由

CVSSベクトルはAV:N／AC:L／PR:N／UI:N／S:U／C:N／I:N／A:Hで、ネットワーク経由・認証不要・可用性のみ喪失という評価です。JPRSの緊急情報によると、不正な応答や悪意を持つ応答を生成する問い合わせを処理する際にnamedが異常終了し、外部から該当する問い合わせパケットを1つ送るだけで停止させられます。

ISCは権威サーバーとリゾルバの両方を対象としています。リゾルバは外部の権威サーバーから受け取った応答を処理する立場、権威サーバーは自ゾーンのデータで応答を組み立てる立場で、どちらもBRID/HHITの処理経路を通りえます。BRIDやHHITを自ゾーンで使っていないから無関係、とは判断できません。

BRID・HHITの長さチェック各1行の修正と到達可能なアサーションの正体

この脆弱性の実体は、BINDがBRID/HHITレコードをDNSワイヤ形式へ書き戻す関数（towire）に置かれた長さチェックの誤りでした。ISCの修正コミットは、BRID用とHHIT用の2ファイルで、それぞれ次の1行を直しています。

// lib/dns/rdata/generic/brid_68.c と hhit_67.c（towire関数）
-	REQUIRE(rdata->length >= 3);
+	REQUIRE(rdata->length > 0);

受信側のfromwire関数は、レコード長が0のときだけ拒否し、1〜2バイトの短いBRID/HHITレコードはそのまま受け入れて保持します。その後にそのレコードを応答へ書き戻そうとすると、towire側が「長さは3バイト以上」という前提（REQUIRE）を満たさず、アサーション違反でnamed全体が停止します。受け入れ条件（長さ>0）と書き戻し条件（長さ>=3）の食い違いが、外部から到達できるアサーション（CWE-617）になっていた、という構造です。

弱点の分類は情報源で割れます。NVDではISC（CNA）がCWE-617（到達可能なアサーション）、Red HatがCWE-1286（構文的に正しくない入力の検証不備）を付けています。到達の引き金を見ればアサーション違反（617）、根本原因を見れば入力長の検証漏れ（1286）で、どちらも成立します。CVEとCWEの読み分けはCVEとCWEの違いとCVSSの読み方で解説しています。

影響を受けるBIND 9のバージョンと修正版、9.18系で対象が狭い理由

ISCのアドバイザリ（文書版2.0）では、2026年1月14日に事前通知、1月21日に一般公開されています。対象版と修正版は次のとおりです。

9.18系の対象は9.18.40〜9.18.43だけです（9.18.40は撤回版のため、配布されたのは9.18.41〜9.18.43。9.20系でも範囲内の9.20.14は撤回されています）。前章のとおりBRID/HHITの型はこれらの版で実装されたため、それ以前の版には脆弱なコード自体が存在しません。Debianのトラッカーも、9.18系より古いBINDを載せるDebian 11を「BRID/HHITの型は後から導入された」として対象外にしています。

RHEL・Debian・Ubuntu・Amazon Linux・SUSEの判定（2026年11月）

各ベンダーの判定は、搭載しているBINDの版が対象範囲に入るかで分かれます。9.18系の古い版や9.20.12以前を載せるディストリは「影響なし」、9.20.13〜9.20.17相当を載せるディストリは修正パッケージを配布しています。

Red Hatは、RHEL 6〜10のbind・bind9.16・bind9.18をすべて「Not affected」としています（修正RHSA-2026:6935が出たのはRed Hat Hardened Imagesのbind-main-9.18.48向けのみ）。Ubuntuの公開パッケージは、22.04が9.18.39、24.04が9.18.39と9.18.50、25.10が9.20.11で、いずれも対象範囲に入らないため影響なしです（launchpadの公開版、2026年11月11日確認）。26.04はUbuntuのCVEページに行がありませんが、収録版は修正版の9.20.18以降です。SUSEは対象範囲内の9.20系を載せていたため影響を受け、SUSE-SU-2026:20135-1（2026年1月22日）とSUSE-SU-2026:0348-1（1月30日）で15 SP7と16.0向けの修正版を配布しました。16.1はGA時点で9.20.26を収録しています。

本件に限ればDebian 12も13も修正済みですが、Debian 12の状況は別のCVEで見ると異なります。Debianのbind9パッケージのページでは、2026年10月に公表されたCVE-2026-94300・96888・97313がbookwormで「vulnerable」のまま残っています。CVE-2025-13878が直っていることは、Debian 12のBINDが安全であることを意味しません。

named -vとsort -VでCVE-2025-13878の該当有無を判定する手順

まずインストールされているバイナリとパッケージの版を確かめます。named -vは呼び出したバイナリの版を表示するだけなので、更新後に再起動していないプロセスがどの版で動いているかはrndc statusのversion:行で確かめます。

named -v
# 出力例: BIND 9.18.41-1~deb12u1-Debian (Extended Support Version) ...

rpm -q bind bind9.18          # RHEL 系（RHEL 9 は bind9.18 も別パッケージ）
dpkg -l bind9 | grep '^ii'    # Debian / Ubuntu

ソースビルドやISC公式パッケージなら、上流の版番号で判定できます。範囲が3系列に分かれ、9.20.13と9.20.9のように桁数が変わる比較もあるため、文字列比較ではなくsort -Vを使います。次のスクリプトはDebian系のepoch（先頭の1:）とパッケージ接尾辞の両方を落としてから判定します。

#!/bin/sh
# 上流の版番号で CVE-2025-13878 の該当範囲を判定する（ディストリ版は各トラッカーで最終確認）
v="${1:-$(named -v 2>/dev/null | awk '{print $2}')}"
v="${v#*:}"    # 1:9.20.18-1~deb13u1 などの epoch を落とす
v="${v%%-*}"   # 9.18.41-1~deb12u1-Debian などの接尾辞を落とす
if ! printf '%s\n' "$v" | grep -Eq '^9\.[0-9]+\.[0-9]+$'; then
  echo "判定不能: 版番号を読み取れません（入力: '${1:-named -v の出力なし}'）" >&2
  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.18.40 9.18.43 || in_range "$v" 9.20.13 9.20.17 || in_range "$v" 9.21.12 9.21.16; then
  echo "$v: CVE-2025-13878 の影響範囲"
else
  echo "$v: CVE-2025-13878 の影響範囲外"
fi

使う前に、境界値を流して判定を確かめておくと安全です。2026年11月11日にmacOS 26.6.2の/bin/shで実行した結果は、9.18.40・9.18.43・9.20.13・9.20.17・9.21.12・9.21.16と1:9.18.41-1~deb12u1が「影響範囲」、9.18.39・9.18.44・9.20.12・9.20.18・9.20.30・9.21.11・9.21.17・1:9.20.18-1~deb13u1が「影響範囲外」でした。badのような不正な入力や、namedが無い環境で引数を省いた場合は「判定不能」を出して終了コード2で止まります。

ただしこのスクリプトは接尾辞を落とすため、ディストリがバックポートで修正したパッケージも「影響範囲」と表示することがあります。安全側の誤判定ですが、ディストリ版は前掲の各トラッカーで最終判断してください。外部からdig @192.0.2.53 version.bind chaos txtで版を問い合わせる方法は、応答をnamed.confのversion設定で変えられるため確定には使いません。digの基本は名前解決の仕組みとdig・nslookupでの確認方法を参照してください。

「影響範囲外」と出ても、それは本件についての判定です。ISC版で9.20.29以前を動かしているなら、2026年10月の4件は残っています。本件の判定と最新版との差の確認は、分けて行ってください。

回避策が無いCVE-2025-13878の対策：9.20.30への更新と停止時間の短縮

ISCは「既知の回避策なし」としています。JPRSも、named.confによるアクセスコントロール（ACL）や設定オプションの変更では影響を回避・軽減できないと明記しています。前章のとおり、脆弱なレコードは正規の問い合わせ処理の中で組み立てられるため、入口での選別では止まりません。確実な対策は修正版への更新だけです。

9.18系EOL後の更新先：ISC版の9.20系移行とディストリ版のサポート条件

公表時点の修正版は9.18.44と9.20.18でした。その後、ISCのダウンロードページでは9.18.50がEOL（2026年6月リリースの最終版）、9.20.30がCurrent Stable（ESV、2026年10月リリース、EOL予定は2028年第2四半期）、9.21.27がDevelopment版と表示されています（2026年11月11日確認）。ISCのEOL一覧は9.18系の最終EOLを2026年6月としており、サポート終了系列の脆弱性一覧では、古い系列は原則として新しい脆弱性の修正を受けないと説明しています。

• ISC版（ソースビルド・ISC提供パッケージ）：9.18.44で止めず、9.20系の最新版（2026年11月11日時点で9.20.30）へ移行する。9.20.18より後も、累計で数十件のCVEが修正されている。
• ディストリ版：OSのセキュリティ更新を当てる。Debianならapt-get updateの後にapt-get install --only-upgrade bind9で上げる。依存するライブラリも一緒に更新されることがあるため、先にapt-get -s install --only-upgrade bind9で更新予定を確かめる。Debian 12のように9.18系を載せるOSは、OSのサポート期間中はベンダーのバックポートが続く。

9.18系から9.20系へ上げる際は、設定オプションの廃止や既定値の変更を事前に確認し、検証環境でnamed-checkconfを通してから切り替えます。9.20系の修正リリースの一覧と撤回版（9.20.25・9.20.28）の扱いは、CVE-2025-40775（TSIG不正でnamedが停止）の対象版と9.20系の修正リリース表にまとめています。

9.20.30で直った2026年10月の4件と9.20.29で止めてはいけない理由

本件は9.20.18で直っていますが、それだけでは今の運用には足りません。ISCは2026年10月21日に9.20.30を出し、GSS-TSIGのCVE-2026-94300など4件を修正しました（脆弱性マトリクス）。9.20.29以前にはこの4件が残るため、ISC版の移行先は9.20.30以降です。9.18系はEOLのため、この4件の修正版はISCから出ていません。本件では9.18.44という逃げ道がありましたが、10月の4件では9.18系に留まる選択肢がISC版には残っていないので、9.18系の環境はこれを機に9.20.30への移行日程を決めるのが現実的です。

4件それぞれの成立条件、named-checkconf -pで設定を確かめるコマンド、ディストリ別の修正状況は、BINDの脆弱性CVE-2026-94300の4件の対象版・確認コマンドとRHEL/Ubuntuの修正状況で扱っています。本記事はCVE-2025-13878の範囲と、9.18系からの移行先の判断に絞ります。

すぐ更新できない場合のsystemd自動再起動による停止時間の短縮策

更新までの間にできるのは、停止時間を短くすることだけです。namedのユニットに再起動指定が無い環境では、systemdのドロップインで異常終了時に自動で再起動させます。

sudo systemctl edit named
# 開いたエディタに次を書いて保存する
[Service]
Restart=on-failure
RestartSec=5s

sudo systemctl daemon-reload
systemctl show named -p Restart

この設定は脆弱性を塞ぎません。攻撃者が同じ問い合わせを繰り返せば停止と再起動が続き、その間は応答できません。社内専用のリゾルバなら、ファイアウォールで外部からの53番ポートへの到達を遮断することも被害の範囲を狭めます。公開する権威サーバーではこの手は取れないため、更新の日程を先に決めてください。停止の検知には、ログのassertion failureの監視が使えます。

公表から2026年11月までの時系列：ISC・JPRS・JVN・IPAの発表とKEVの状況

IPAの「BIND 9の脆弱性対策について（CVE-2025-13878）」は、悪用された場合に遠隔の第三者によって製品が異常終了する可能性があり、攻撃はまだ確認されていないがDNSサーバー管理者はアップグレードを実施するよう求めています。JPRSは「バージョンアップを強く推奨」としました。ISCは発見者としてMarlink CyberのVlatko Kosturjak氏に謝辞を述べています。

2026年11月11日時点で、CISAのKEV（2026年11月10日版、1,779件）にCVE-2025-13878は収録されていません。EPSS（2026年11月10日時点）は0.094で、30日以内に悪用が観測される推定確率は約9.4%、全CVEの中では上位約5%（95.5パーセンタイル）に入ります。ISCは悪用を把握していないとしていますが、未認証で遠隔から発火する性質上、放置してよい値ではありません。

攻撃の再現手順はすでに公開されています。発見者のMarlink Cyberは公表日と同じ2026年1月21日に自社のアドバイザリMCSAID-2025-015を公開し、報告日（2025年11月1日）とともに概念実証（PoC）コードを載せました。悪用の観測が無いことは、更新を遅らせる理由になりません。

BIND 9のDoS脆弱性を繰り返し踏まないための版管理と追従の単位

BIND 9では、2025年5月のCVE-2025-40775（TSIG）、2026年1月の本件、2026年10月の4件と、遠隔からnamedを落とせる脆弱性が続いています。3つは対象範囲がまったく違います。CVE-2025-40775は9.18系が対象外で9.20.0〜9.20.8が対象、本件は9.18系の一部が対象、10月の4件は9.18系全体と9.20.29以前を広く対象にしています。CVEごとに範囲表を読み直すより、利用系列の最新版へ定期的に追従するほうが判断を誤りません。

実務では次の順で管理すると、取りこぼしが減ります。

1. 全DNSサーバーのnamed -vとパッケージ版を台帳にし、ISC版かディストリ版かを区別する。
2. ISC版は脆弱性マトリクス、ディストリ版は各ベンダーのトラッカーを、月1回のリリース日に合わせて確認する。
3. EOLが決まった系列（9.18系）は、OSのサポート期限とあわせて移行計画を立てる。

2026年は1月・9月・10月と、ISCの公表が数か月おきに重なりました。台帳の「最新版」欄は書き換え忘れが起きやすいため、版番号をじかに書かず、ISCのダウンロードページで確認する手順を書いておく運用のほうが古くなりにくいです。

DNS応答の改ざん対策まで見直すならDNSSECの仕組みと導入手順が参考になります。公開DNSを含むサーバー群の版の棚卸しや、修正版適用後の確認を外部に任せたい場合は、一創の脆弱性診断・セキュリティ診断で対象範囲の洗い出しから相談できます。

よくある質問

CVE-2025-13878の影響判断と対応で出やすい質問をまとめます。

RHELやUbuntu、Amazon LinuxのBINDは更新が必要ですか？

この脆弱性については不要です。Red HatはRHEL 6〜10のbind・bind9.18をすべて「Not affected」、Amazon Linux 2・2023も「Not Affected」としています。UbuntuもLTSの22.04・24.04と25.10を影響なしとしています。いずれも搭載版が対象範囲（9.18.40〜9.18.43など）に入っていないためです。ほかの脆弱性に対するOSの定期更新は続けてください。

BRIDやHHITのレコードを使っていなくても影響を受けますか？

受ける可能性があります。ISCとJPRSは、壊れたレコードや悪意あるレコードを生む問い合わせを処理する際に異常終了するとしており、自ゾーンでBRID/HHITを使っているかは条件に挙げていません。権威サーバー・リゾルバの両方が対象です。版が範囲内なら、レコードの利用有無にかかわらず更新してください。

9.18.44や9.20.29に上げれば今も十分ですか？

本件は直りますが、十分とは言えません。9.18系は9.18.50を最後に2026年6月でEOLとなり、ISCは古い系列には原則として新しい脆弱性の修正を出さないとしています。9.20.29も、2026年10月21日に公表された4件（CVE-2026-94300ほか）が残ります。ISC版なら9.20系の最新版（2026年11月11日時点で9.20.30）へ上げてください。Debian 12などディストリの9.18系なら、ベンダーのバックポート更新に従います。

設定変更やACLで回避できますか？

できません。ISCは回避策なしとし、JPRSはnamed.confのACLや設定オプションの変更では回避・軽減できないとしています。脆弱なレコードは正規の応答処理の中で組み立てられるため、入口での選別では止まりません。更新までの間は、systemdの自動再起動で停止時間を縮める、社内専用サーバーならファイアウォールで外部からの到達を遮断する、といった被害を狭める手段に限られます。

実際に悪用された例はありますか？

公表されていません。ISCは悪用を把握しておらず、IPAも2026年1月23日時点で攻撃は確認されていないとしています。CISAのKEVにも2026年11月10日版で未収録、EPSSは0.094です。ただし発見者のMarlink Cyberが自社のアドバイザリで概念実証（PoC）コードを公開しており、未認証で遠隔から発火するため、対象版なら更新を先送りしないでください。

関連記事

• BINDの脆弱性CVE-2026-94300とは：4件の対象版・確認コマンドとRHEL/Ubuntuの修正状況【11月9日時点】
• CVE-2025-40775とは｜BIND 9.20/9.21がTSIG不正でnamedを停止するDoSの対象版・修正版と確認手順
• CVEとCWEの違いとは？CWEの意味と、1件のCVEにCWEが付く仕組みを実例で解説
• 脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説