BIND 9.20.26公開、9件のCVEを修正 LLM支援の監査で月次パッチが常態化
2026年7月25日 15:39
BINDを運用する管理者は、特に検証機能付きリゾルバやDoHエンドポイントを使っている場合、BIND 9.20.26への更新を急ぐ必要がある。ISCによれば、2026年7月22日に公開したこの更新では9件の脆弱性を修正した。ISCは、これら9件について現時点で実際の悪用は確認していないとしているが、BIND 9.18系は6月末でサポート終了となっており、継続利用時の未修正リスクは積み上がる。
■9件のCVEを同時修正、背景には構造的な変化
Internet Systems Consortium（ISC）は2026年7月22日、DNSサーバーソフトウェア「BIND 9」の新版「BIND 9.20.26」を公開し、9件の脆弱性を修正した。公開の1週間前には管理者向けに事前告知も行っていた。今回の修正対象には、DNSSEC検証の回避、メモリ枯渇、Response Policy Zones（RPZ）におけるワイルドカード型ファイアウォール回避が含まれる。
7月22日の公開に合わせて出たセキュリティ情報は、CVE-2026-13321とCVE-2026-10723（NSECおよびNSEC3レコード処理に起因するDNSSEC検証回避）、CVE-2026-11331（ワイルドカードCNAMEによるRPZポリシー回避）、CVE-2026-11605（署名済みDNSSECレコードの不要な再検証によるリソース負荷）、CVE-2026-11622（検証リゾルバでのメモリ枯渇）、CVE-2026-11721（RRSIGレコードとワイルドカードにおけるラベル数不一致）、CVE-2026-12617（CNAMEまたはDNAMEレコード順序で発生する予期しない終了）、CVE-2026-10822（PRIVATEDNSアルゴリズムの鍵レコードによる予期しない終了）、CVE-2026-13204（7月公開分で追加開示された助言）である。
この更新は単発ではない。2026年のそれ以前の月次リリースでも、BINDのDNS-over-HTTPS（DoH）実装におけるヒープuse-after-free（CVE-2026-3593、2026年5月のBIND 9.20.23で初回修正）に加え、リソース枯渇やアクセス制御リスト（ACL）回避の不具合が修正されてきた。9.20.20未満を使っている管理者は、これらを含む累積分の未修正リスクを抱えることになる。
ISCは2026年5月12日のブログ投稿で、この報告急増の背景を大規模言語モデル（LLM）にあると説明した。ISCは『LLMによって、オープンソースソフトウェアの脆弱性を見つけることがはるかに容易になり、研究者だけでなく悪意ある行為者にとっても参入障壁が下がっている。その結果、当組織や多くのオープンソースプロジェクトに、一時的な脆弱性報告の洪水が生じている』と記した。ISCによれば、外部研究者からの報告と、自社のLLM支援分析の両方を合わせたトリアージ件数は、過去の基準を10倍超で上回っている。ISCが「一時的」と表現したのは報告の洪水であって、構造変化そのものではない。LLMは再利用可能な監査手段になっており、インターネット上のオープンソースCコードベース全体が同様の再点検にさらされている。
■今回の中核リスクはDNSSEC検証回避
7月22日公開分で特に影響が大きいのは、DNSSEC検証回避の2件だ。CVE-2026-13321とCVE-2026-10723は、BINDによるNSECおよびNSEC3レコードの処理方法を突く。これらは、ある名前がゾーン内に存在しないことを暗号学的に証明するDNSレコード種別である。
DNSSECでは、各応答にデジタル署名が付き、署名鍵上の名前はそのレコードを所有するゾーンと一致していなければならない。問題は、特定のコード経路で、BINDがNSECおよびNSEC3レコードについてその一致を検証していなかったことにある。攻撃者が、見かけ上は正当だがゾーンと一致しない署名を持つDNS応答を細工すると、検証をすり抜け、DNSSECで認証済みに見える応答を偽造できる。するとリゾルバのキャッシュには、暗号学的に検証済みだと信じているが実際にはそうではないデータが残る。ISCの修正では、応答受理前に署名者名が所有ゾーンと一致していることを強制する。
CVE-2026-11331は、別の層にあるDNSセキュリティ機構であるRPZに影響する。RPZは、マルウェアやフィッシングなどに関連するドメインへの問い合わせを遮断または転送する、BINDのDNSレベルのファイアウォール機能だ。この回避は長さの境界条件で発生する。問い合わせ名が十分に長いと、BINDのRPZ処理はワイルドカードCNAMEのポリシールールを評価する前にNAMETOOLONGエラーを生成し、そのままポリシーエンジンを抜けてしまう。その結果、本来なら遮断されるべき問い合わせが通過しうる。RPZベースの脅威遮断に依存している組織は、更新後にワイルドカードCNAMEの設定を見直す必要がある。
■DoHのuse-after-freeと、LLMで加速する脆弱性発見
5月20日に開示されたDoHのuse-after-free（CVE-2026-3593）は、別系統のリスクを示した。これはBINDのDoH実装にあるヒープメモリ破損の不具合で、応答を書き込んでいる間にクライアントがHTTP/2 SETTINGSフレームをDoHエンドポイントへ大量送信すると、BINDのメモリアロケータが、まだダングリングポインタから参照されている領域を解放してしまう。攻撃者がその解放済み領域に入る内容を制御できれば、条件次第でnamedに任意コードを実行させられる可能性がある。BINDは通常、高いシステム権限で動作するため、成功時にはそのプロセス権限で制御を奪われる。
これらの脆弱性をつなぐ共通項は偶然ではない。CISAが引用し、MicrosoftやGoogleの研究でも確認された調査によれば、CおよびC++コードベースにおけるセキュリティ脆弱性のおよそ70％は、ダングリングポインタ、use-after-free、バッファーオーバーフローなどのメモリ安全性の問題に由来する。BINDはCで書かれている。人手によるコードレビューは、どれだけ熟練していても逐次的かつ時間制約のある作業だが、LLMは既知の脆弱性クラスに合致する箇所をコードベース全体から並列かつ網羅的に数時間で洗い出せる。
ISCは5月の告知で、脆弱性公表時に再現テストケースも同時公開する方針を明らかにした。その理由は、それらのテストがすでにLLM経由で大半発見可能だからだという。含意は明確で、十分な能力を持つLLMとBINDのオープンソースコードベースにアクセスできる攻撃者は、ISCとほぼ同じ速度で概念実証用の攻撃材料を導き出せるということになる。テストケースの公開は、防御側だけが有意な先行時間を持てるという前提を崩す。
この状況はISCだけのものではない。BIND 9.20.26の公開と同じ日に、NLnet Labsは複数CVEを修正した「Unbound 1.25.2」を公開し、その中にはDNS-over-QUICのサービス妨害の欠陥も含まれていた。PowerDNSも、RRSIGラベル回避問題に対処するため、Recursor 5.2.12、5.3.9、5.4.4を公開した。LLM支援監査によって脆弱性報告量が段階的に増えるという同じ構造変化が、DNSソフトウェアのエコシステム全体で同時進行している。
オープンソースのセキュリティ団体も正式な指針を出し始めている。Cloud Native Computing FoundationとOpen Source Security Foundationが2026年5月に出したガイドは、AIツールがソフトウェアの構築、保護、攻撃のされ方を変えつつあり、その中心にオープンソースがあると明記した。さらに、LLMは人間のチームでは及ばない速度と規模で、脆弱性の発見、パッチ生成、コードレビューを実行できるとしている。
■検証リゾルバとBIND 9.18利用者への影響
BINDを検証機能付きの再帰リゾルバとして使っている管理者にとって、DNSSEC検証回避のCVE-2026-13321とCVE-2026-10723は、脆弱な版のリゾルバではDNSSECの信頼連鎖を強制できないことを意味する。リゾルバと権威サーバーの間に位置する攻撃者は、任意ドメインについて署名済みに見せかけた応答を偽造でき、リゾルバはそれを認証済みとしてキャッシュし、クライアントに返してしまう。これは理論上だけの話ではない。2025年10月には、構造的に類似する以前のBINDキャッシュ汚染脆弱性（CVE-2025-40778）について概念実証コードが示され、積極的な悪用可能性が実証されていた。
DNSSECは、国別トップレベルドメインのおよそ半数ですでに導入されており、米国では.govゾーンに対する連邦要件にもなっている。DNSSEC署名済み応答の偽造を黙って受け入れるリゾルバは、利用者に対してそのセキュリティモデルを根本から無効化する。
BIND 9.18は2026年6月末でサポート終了を迎えた。ISCは9.18系に対してセキュリティ修正をバックポートしないことを確認している。したがって、BIND 9.18の全導入環境は、新たな助言が出るたびに未修正の露出を積み増していく。7月22日分だけでも、9.18サーバーには未解決の脆弱性が9件残ることになり、8月にも増える可能性がある。
9.18から9.20への移行は、特にDoHやTLSトランスポート設定の違いがあるため簡単ではない。ISCは9.18と9.20の主な変更点をまとめたナレッジベース記事を公開しており、本番投入前にステージング環境で9.20.26を検証すべきだ。BIND 9.20はISCの現行安定ブランチで、2028年まで保守される。
運用上の追加要因もある。今BIND 9.20へ更新する管理者は、2026年10月11日に予定されているDNSSECルートゾーンKSKロールオーバーへの備えも確認しなければならない。この日、ICANNはインターネット上のすべてのDNSSEC検証リゾルバにとって信頼の起点となる暗号鍵を置き換える。RFC 5011による自動トラストアンカー更新を有効にした新しめのBIND（9.9以降）であれば自動的に処理できるが、トラストアンカーを手動設定しているリゾルバや古いソフトウェアでは、ロールオーバー後にDNSSEC署名済みドメイン全体でSERVFAILを返し始める。
■ISCはBIND 9.22を2026年末まで延期
ISCは、セキュリティ修正に開発リソースを集中させるため、次期安定ブランチとして計画していたBIND 9.22の公開を少なくとも2026年末まで延期した。新機能の開発を停止したわけではないが、脆弱性対応より優先度を下げたとしている。
ISCはまた、CVSSスコア7.0超の問題については今後もすべてCVE番号を付与するとし、5〜7の中程度の問題にもCVEを発行し始めるべきか評価中だとした。2026年第4四半期に現行の加速したリリース体制を再評価し、2027年第1四半期までに、四半期に1回のセキュリティリリースという従来ペースへ戻れることへの期待も示している。
それまでの間、ISCのEarly Vulnerability Notificationプログラムは、購読組織に対しCVEの一般公開前に事前通知を提供する。公開と攻撃コード化の速度差が縮まっている環境では、こうした先行通知の価値は相対的に高い。
■管理者が取るべき対応
本番環境でBINDを運用している事業者は、遅滞なく9.20.26へ更新すべきだ。9.20.20未満には、複数のパッチサイクルにまたがるメモリリーク、ACL回避、キャッシュ汚染、DoH use-after-freeの未修正分が累積している。防御可能な最低ラインは9.20.26となる。
展開形態別では、DoHエンドポイントを運用している組織は、HTTP/2 SETTINGSフレームに起因するuse-after-freeを優先事項として扱う必要がある。初回修正は5月公開分だったが、9.20.26には追加のハードニングも含まれる。DoH機能が不要な環境では、パッチ適用が完了するまでの防御強化策として無効化を検討できる。
RPZを使っている運用者は、更新後にワイルドカードCNAMEのブロックポリシーを見直し、意図した問い合わせが引き続き遮断されているか確認すべきだ。CVE-2026-11331の回避は問い合わせ名の長さで発生するため、意図的な細工によって再現可能である。
なおBIND 9.18をまだ使っている組織は、9.20.26への移行を直ちに運用上の最優先事項として扱う必要がある。2026年6月30日以降、この系統に対するセキュリティ修正のサポート経路は存在しない。ISCのナレッジベースには、9.18から9.20への移行に必要な設定変更がまとめられている。
セキュリティ要件の高い環境では、ISCのEarly Vulnerability Notificationプログラムを購読することで、一般公開前に事前警告を受けられる。再現テストケースがCVEと同時公開される現在、この種の先行把握は以前より構造的に価値が高い。
■注目ポイントQ&A
●BIND 9.20.26で修正された9件のCVEは何ですか
2026年7月22日に開示された9件は、CVE-2026-13321とCVE-2026-10723（NSEC／NSEC3処理に起因するDNSSEC検証回避）、CVE-2026-11331（ワイルドカードCNAMEによるRPZポリシー回避）、CVE-2026-11605（不要なDNSSECレコード再検証）、CVE-2026-11622（検証リゾルバでのメモリ枯渇）、CVE-2026-11721（ワイルドカードレコードとRRSIGのラベル数不一致）、CVE-2026-12617（CNAMEまたはDNAMEの順序による予期しない終了）、CVE-2026-10822（PRIVATEDNSアルゴリズムの鍵レコードによる予期しない終了）、CVE-2026-13204（追加助言）です。さらに2026年の以前の更新では、CVE-2026-3593（DoHのuse-after-free、5月に初回修正）やCVE-2026-5950（無制限のリゾルバ再送ループ）にも対処しており、これらも9.20.26に含まれています。
●BIND 9.18はまだセキュリティパッチを受け取れますか
いいえ。BIND 9.18は2026年6月末でサポート終了となり、ISCはこの系統に新しいセキュリティ修正をバックポートしないとしています。9.18を動かしているサーバーは、月次リリースのたびに未修正CVEが積み上がります。継続的な保護を受けるにはBIND 9.20.26への移行が必要で、BIND 9.20は2028年までサポートされます。
●短期間で脆弱性が増えたのはなぜですか
ISCによれば、大規模言語モデルによって体系的なコード監査が大幅に効率化されたためです。ISCは2026年5月、外部研究者からの報告と自社のLLM支援分析を合わせた脆弱性報告が、過去の10倍超のペースになっていると説明しました。これは新たにコード品質が悪化したというより、長年潜在していた不具合が、コードベース全体を短時間で網羅的に照合できる手段によって表面化したという性格が強いとされます。同じ動きはUnboundやPowerDNSでも起きています。
●DoHの脆弱性は企業利用に何を意味しますか
BINDのDoH実装にあるヒープuse-after-free（CVE-2026-3593、5月のBIND 9.20.23以降で修正）は、DoHを有効化しているサーバーに影響します。遠隔の攻撃者は、細工したHTTP/2 SETTINGSフレームを大量送信してメモリ破損を引き起こし、namedのクラッシュや、条件次第では攻撃者が制御するコードの実行につなげる可能性があります。最近DoHを有効化した組織は、少なくともBIND 9.20.23以上であることを確認し、追加のハードニングを含む9.20.26への更新を進めるべきです。DoHを使っていない組織は、攻撃面を減らすため無効化を検討できます。
元記事: BIND 9 Nine-CVE July Release: LLM Code Audits Push Monthly Security Patches