MENU

CVE-2026-62299とは？CoreDNS rewriteのリモートDoSとAzure Linux 3.0更新手順

Linux

CVE-2026-62299への基本対応は、Azure Linux 3.0のcorednsパッケージを1.11.4-18.azl3以上へ更新することです。1.11.4-17.azl3では、CoreDNSのrewriteプラグインがOPTレコードを含まないDNS応答を処理した際、nilポインタ参照によるpanicを起こす可能性があります。外部から認証なしでサービス妨害を引き起こせるため、該当バージョンを利用している場合は、設定の確認だけで済ませず更新を優先してください。MicrosoftはAzure Linux向けに修正をバックポートし、RPMのリリース番号を17から18へ更新しています。(マイクロソフトセキュリティ応答センター)

特に注意したいのは、アップストリームのCoreDNSでは修正版が1.14.5とされている一方、Azure Linux 3.0では1.11.4を維持したまま修正パッチが適用されている点です。脆弱性スキャナーが「1.14.5未満」と判定しても、Azure Linuxの1.11.4-18.azl3は修正済みです。バージョン番号の前半だけで判断せず、RPMのReleaseまで確認することが重要です。(GitHub)

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

CVE-2026-62299の概要

CVE-2026-62299は、CoreDNSのrewriteプラグインに存在するNULLポインタ参照の脆弱性です。EDNS0オプションを応答時に元へ戻す処理で、OPTレコードが存在することを確認せずにデータへアクセスするため、条件を満たしたDNSクエリによってpanicが発生します。

項目内容
CVE番号CVE-2026-62299
対象Azure Linux 3.0のCoreDNS
影響を受けるパッケージcoredns-1.11.4-17.azl3
Azure Linux向け修正版coredns-1.11.4-18.azl3
アップストリーム修正版CoreDNS 1.14.5
脆弱性の種類NULLポインタ参照、リモートDoS
CWECWE-476
CVSS v3.15.3、Medium
攻撃経路ネットワーク
認証不要
ユーザー操作不要
主な影響SERVFAILの発生、処理負荷の増加、条件によってはCoreDNSプロセス停止

CVSSベクトルはCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Lです。機密性や完全性への直接的な影響は示されていませんが、DNSの可用性に影響します。(GitHub)

CoreDNS rewriteプラグインでリモートDoSが起きる仕組み

EDNS0では、従来のDNSメッセージを拡張するためにOPTと呼ばれる疑似リソースレコードを使用します。CoreDNSのrewriteプラグインには、DNSリクエストへEDNS0オプションを追加または置換し、応答時に元の状態へ戻すrevert機能があります。

脆弱性が発生する流れは次のとおりです。

  1. DNSクエリがrewrite edns0 ... revertルールに一致する
  2. rewriteプラグインがリクエスト内のEDNS0オプションを変更する
  3. 応答時に変更を元へ戻すための処理が登録される
  4. 後続プラグインがOPTレコードを含まないDNS応答を返す
  5. res.IsEdns0()がnilを返す
  6. コードがnilチェックをせず、OPTレコードのOptionへアクセスする
  7. nilポインタ参照によるpanicが発生する

問題のあった処理は、主に次の2つです。

  • edns0SetResponseRule
  • edns0ReplaceResponseRule[T]

修正版では、res.IsEdns0()の結果がnilだった場合に処理を終了するチェックが追加されています。応答にOPTレコードがなければ元に戻す対象も存在しないため、そのまま戻るのが正しい動作です。Azure Linuxの修正パッチでも、このnilチェックが両方の処理へ追加されています。(GitHub)

攻撃が成立する条件

CVE-2026-62299は、CoreDNSを起動しているだけで無条件にプロセスが停止する脆弱性ではありません。主に次の条件が重なった場合に問題が発生します。

rewrite edns0とrevertを使用している

Corefileに、次の形式に該当するルールが必要です。

rewrite edns0 <local|nsid|subnet> <set|append|replace> ... revert

重要なのは末尾のrevertです。revertが指定されると、DNS応答へ変更を戻す処理が登録され、脆弱なコードへ到達します。

後続処理がOPTレコードのない応答を返す

hosts、file、whoami、templateなど、独自にDNS応答を組み立てるプラグインは、OPTレコードを付けない応答を返すことがあります。特別に細工された巨大パケットや異常なDNSレコードが必要なわけではありません。

さらに、攻撃側のDNSクエリ自体にEDNS0オプションが含まれていなくても、setやappendによってCoreDNS内部でオプションが追加されるため、通常のDNSクエリでも条件を満たす可能性があります。(GitHub)

CoreDNSへネットワーク経由で到達できる

攻撃者には認証もログイン権限も必要ありません。DNSクエリを対象のCoreDNSへ送信できれば攻撃条件の一つを満たします。

インターネットへ公開しているDNSサーバーだけでなく、次の環境も対象になり得ます。

  • 社内ネットワークのDNSサーバー
  • コンテナ環境内のサービスディスカバリー用DNS
  • 複数テナントが共有するネットワーク
  • 信頼性の低い端末からアクセスできる内部DNS
  • Kubernetesなどでクラスタ内名前解決を担うCoreDNS

debugディレクティブの有無で影響が変わる

CoreDNSの標準的な構成では、DNS処理中のpanicを回復処理が捕捉します。この場合、CoreDNSプロセス全体が即座に停止するとは限らず、問題のクエリに対してSERVFAILを返します。

ただし、攻撃者がクエリを繰り返せば、次の影響が発生します。

  • 対象となるDNSクエリが継続的にSERVFAILになる
  • panicと回復処理が繰り返される
  • CPU使用率やログ出力量が増える
  • 名前解決の遅延やタイムアウトが発生する
  • 監視アラートが大量に発生する

Corefileでdebugディレクティブを有効にしている場合は、panicの回復処理が無効になり、同じ問題によってCoreDNSプロセス自体が終了する可能性があります。debugを本番環境で有効にしている構成は、より高い優先度で対応すべきです。(GitHub)

CVSS 5.3でも軽視できない理由

CVE-2026-62299のCVSS基本値は5.3で、深刻度はMediumです。これは、通常構成ではpanicが回復処理によって捕捉され、機密情報の漏えいやデータ改ざんも発生しないことが反映されています。

しかし、実務上の対応優先度はCVSSだけで決めるべきではありません。DNSは多くのサービスの前提となるため、DNS障害が次のような二次障害へ発展します。

  • Webアプリケーションからデータベースへ接続できない
  • APIや外部サービスの名前解決に失敗する
  • コンテナの起動やヘルスチェックに失敗する
  • 認証基盤や監視サービスへ接続できない
  • 障害対応用の管理ツールまで利用できなくなる

単一のCoreDNSインスタンスに依存している環境や、外部から直接DNSクエリを受け付ける環境では、Mediumであっても緊急度を上げて対応する必要があります。

Azure Linux 3.0で影響を確認する手順

OSがAzure Linux 3.0か確認する

最初に、対象ホストのOS情報を確認します。

cat /etc/os-release

ID、NAME、VERSION_IDなどを確認し、Azure Linux 3.0であることを特定します。

CoreDNSがコンテナ内で動作している場合は、ホストOSだけではなく、CoreDNSを含むコンテナイメージのベースOSとパッケージも確認してください。

インストール済みのcorednsパッケージを確認する

RPMでインストールされている場合は、次のコマンドでバージョンを確認します。

rpm -q coredns

詳細な形式で確認する場合は、次のコマンドを使用します。

rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' coredns

影響を受ける代表的な出力は次の形式です。

coredns-1.11.4-17.azl3.x86_64

修正済みであれば、次のようにReleaseが18以上になります。

coredns-1.11.4-18.azl3.x86_64

Azure Linuxではパッケージ管理にtdnfを使用します。リポジトリで利用できるバージョンは、次のコマンドでも確認できます。(Microsoft Learn)

tdnf list coredns

RPM以外のCoreDNSも確認する

次のケースでは、rpm -q corednsが「インストールされていません」と表示されても、CoreDNSが稼働している可能性があります。

  • 手動で配置したバイナリ
  • 独自ビルドしたCoreDNS
  • コンテナイメージに組み込まれたCoreDNS
  • Kubernetes DeploymentやDaemonSetで稼働するCoreDNS
  • アプリケーション製品へ同梱されたCoreDNS

実行中のプロセスを確認します。

ps -eo pid,args | grep '[c]oredns'

バイナリがPATH上にある場合は、アップストリームのバージョンも確認します。

command -v coredns
coredns -version

ただし、Azure LinuxのRPMへセキュリティ修正がバックポートされている場合、coredns -versionには1.11.4までしか表示されないことがあります。修正済みかどうかはRPMのRelease番号やコンテナイメージのビルド情報で判断してください。

Corefileの場所を特定する

systemdサービスとして起動している場合は、起動引数からCorefileのパスを確認します。

systemctl show -p ExecStart coredns

プロセスのコマンドラインも確認します。

ps -eo pid,args | grep '[c]oredns'

-confオプションなどで指定されているファイルが、実際に読み込まれているCorefileです。

rewrite edns0とrevertの組み合わせを検索する

Corefileが/etc/coredns/Corefileにある場合の例です。

grep -nE '^[[:space:]]*rewrite[[:space:]]+edns0.*[[:space:]]revert([[:space:]]|$)' \
  /etc/coredns/Corefile

設定が複数ファイルへ分割されている場合は、設定ディレクトリ全体を検索します。

grep -RInE '^[[:space:]]*rewrite[[:space:]]+edns0.*[[:space:]]revert([[:space:]]|$)' \
  /etc/coredns 2>/dev/null

Corefileでimportを使用している場合、メインファイルだけを確認すると対象ルールを見落とします。読み込まれる設定ファイルをすべて確認してください。

debugディレクティブを確認する

grep -RInE '^[[:space:]]*debug([[:space:]]|$)' \
  /etc/coredns 2>/dev/null

debugが有効で、同時に脆弱なrewrite edns0 ... revertルールが存在する場合、プロセス停止へ発展する可能性があるため、最優先で更新します。

対応優先度の判断基準

状況判断
1.11.4-18.azl3以上Azure Linux向け修正済み
1.11.4-17.azl3で対象ルールなし現在の設定では到達しにくいが、更新を推奨
1.11.4-17.azl3でrewrite edns0 ... revertあり早急に更新
上記に加えてdebugあり最優先で更新
外部または信頼できないネットワークから到達可能優先度を上げる
CoreDNSが1台だけで冗長化されていない優先度を上げる
コンテナ内の独自バイナリRPM更新では直らないためイメージ更新が必要

対象ルールが現在存在しなくても、「今は攻撃条件を満たさない」というだけで、脆弱なコード自体が消えるわけではありません。将来の設定変更やプラグイン追加によって条件を満たす可能性があるため、修正版へ更新するのが確実です。

Azure Linux 3.0でcorednsを1.11.4-18へ更新する手順

更新前に設定と稼働状態を記録する

更新前に、最低限次の情報を保存します。

rpm -q coredns
systemctl status coredns --no-pager
systemctl show -p ExecStart coredns

Corefileもバックアップします。

sudo cp -a /etc/coredns/Corefile \
  /etc/coredns/Corefile.bak.$(date +%Y%m%d%H%M%S)

実際のCorefileが別の場所にある場合は、そのパスへ置き換えてください。

冗長構成の場合は、全インスタンスを同時に更新せず、1台ずつ更新してDNS応答を確認します。

corednsパッケージを更新する

Azure Linuxでは、次のコマンドでcorednsだけを更新できます。

sudo tdnf update coredns

更新後にパッケージを確認します。

rpm -q coredns

期待する出力は、次のバージョンまたはそれ以降です。

coredns-1.11.4-18.azl3

tdnf list corednsで1.11.4-18が表示されない場合は、次を確認します。

  • Azure Linux 3.0用リポジトリが有効になっているか
  • パッケージメタデータが更新されているか
  • プロキシやファイアウォールがリポジトリ通信を妨げていないか
  • 社内ミラーへ修正版が同期されているか
  • バージョン固定や除外設定が行われていないか

CoreDNSプロセスを再起動する

RPMを更新しても、すでに起動しているプロセスは古いバイナリをメモリ上で使用し続ける場合があります。systemd管理の場合は、メンテナンス手順に従って再起動します。

sudo systemctl restart coredns
sudo systemctl status coredns --no-pager

コンテナで稼働している場合は、RPM更新ではなく、修正版を含むイメージへ更新してコンテナを再作成します。ホスト側のcorednsパッケージを更新しても、コンテナ内のCoreDNSには反映されません。

更新後に確認すべき項目

RPMのReleaseが18以上になっているか

rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' coredns

1.11.4-18.azl3以上であることを確認します。

DNS応答が正常か

環境内で確実に存在するDNS名を指定して、UDPとTCPの両方を確認します。

DNS_SERVER=127.0.0.1
TEST_NAME=host.example.internal

dig @"$DNS_SERVER" "$TEST_NAME" A +time=2 +tries=1
dig @"$DNS_SERVER" "$TEST_NAME" A +tcp +time=2 +tries=1

次の点を確認してください。

  • 応答コードが想定どおりである
  • 不要なSERVFAILが発生していない
  • 応答時間が大きく悪化していない
  • rewrite対象と非対象の名前解決が両方成功する
  • EDNS Client SubnetやNSIDなど、利用中のEDNS0機能が維持されている

ログにpanicが残っていないか

sudo journalctl -u coredns --since "10 minutes ago" --no-pager |
  grep -Ei 'panic|nil pointer|SERVFAIL|rewrite'

更新前から大量のpanicやSERVFAILが記録されている場合は、CVE-2026-62299が実際に誘発されていた可能性だけでなく、別のプラグインや設定不備も含めて調査します。

panicメトリクスが増加していないか

CoreDNSでprometheusプラグインを有効にしている場合、coredns_panics_totalでpanicの累計を確認できます。標準的なメトリクス待受先を使用している場合の例は次のとおりです。(CoreDNS)

curl -fsS http://127.0.0.1:9153/metrics |
  grep '^coredns_panics_total'

更新後も値が増加し続ける場合は、別のpanic要因が残っている可能性があります。

すぐに更新できない場合の一時的なリスク低減策

MSRCはCVE-2026-62299に対する個別の公式回避策を示していません。そのため、正式な対応は1.11.4-18.azl3以上への更新です。(マイクロソフトセキュリティ応答センター)

更新までの間に実施する措置は、あくまで運用上の一時対策として扱ってください。

一時対策効果と注意点
対象のrewrite edns0 ... revertルールを停止する脆弱な応答復元処理を通らなくなるが、EDNS0の動作やクライアント情報連携が変わる
revertを外すpanicの経路を避けられる可能性があるが、応答時に元のEDNS0状態へ戻らなくなる
本番環境のdebugを無効化するプロセス全体の停止リスクを下げるが、SERVFAILやpanic処理負荷は残る
DNSの到達元をACLで制限する攻撃可能な範囲を狭めるが、許可済みネットワークからの攻撃は防げない
レート制限を適用する大量クエリによる負荷を軽減できるが、単発のpanic自体は防げない
CoreDNSを複数インスタンス化する障害耐性は上がるが、全インスタンスが同じ脆弱な設定なら根本解決にならない

設定を変更する場合は、EDNS Client Subnet、NSID、独自EDNS0オプションなどを利用しているシステムへの影響を事前に確認してください。GitHubのアドバイザリでは、revertを無効にした場合には問題の応答ルールが登録されず、同じ処理でpanicしないことが確認されていますが、修正版への更新を置き換えるものではありません。(GitHub)

脆弱性対応で失敗しやすいポイント

CoreDNS 1.11.4という表示だけで未修正と判断する

Azure Linuxでは、アップストリームのCoreDNS 1.14.5へそのまま更新するのではなく、修正を1.11.4へバックポートしています。

したがって、次の判断は誤りです。

1.11.4は1.14.5より古いので、必ず脆弱

Azure Linuxでは、次のRPM Releaseまで確認します。

1.11.4-17.azl3  脆弱
1.11.4-18.azl3  修正済み

脆弱性スキャナーがアップストリームのバージョンだけで判定している場合は、MicrosoftのアドバイザリとRPMのパッチ履歴を根拠に例外判定を行います。(GitHub)

RPMだけ確認してコンテナ内のCoreDNSを見落とす

ホスト上のRPMと、コンテナ内のCoreDNSは別物です。次の情報を資産台帳へ分けて記録してください。

  • ホストOSのcorednsパッケージ
  • コンテナイメージ名とダイジェスト
  • コンテナ内のCoreDNSバージョン
  • 独自パッチの有無
  • Corefileの配布元
  • 再デプロイが必要なワークロード

パッケージ更新後に再起動しない

ディスク上のバイナリが修正版になっても、起動中のプロセスが古いコードを使用していれば、脆弱性は運用上残ったままです。パッケージ更新、プロセス再起動、DNS応答確認を一つの作業として実施します。

debugを無効化しただけで対応完了とする

debugを無効にすれば、標準の回復処理によってプロセス全体の終了を避けられる可能性があります。しかし、対象クエリのSERVFAILやpanic処理負荷は残ります。

debugの無効化は影響を抑える措置であり、脆弱性の修正ではありません。

冗長化したCoreDNSを同時に再起動する

DNSサーバーを複数台運用していても、全台を同時に更新・再起動すると、その間の名前解決が停止します。

安全な手順は次のとおりです。

  1. 1台をDNSの振り分け対象から外す
  2. パッケージを更新する
  3. CoreDNSを再起動する
  4. DNS応答、ログ、メトリクスを確認する
  5. 振り分け対象へ戻す
  6. 次のインスタンスを更新する

まず実施すべき対応

CVE-2026-62299への対応では、次の順序で確認すると見落としを減らせます。

  1. Azure Linux 3.0上でCoreDNSが稼働しているか確認する
  2. RPM、コンテナ、手動配置のどの形態か特定する
  3. coredns-1.11.4-17.azl3が存在しないか確認する
  4. Corefile内のrewrite edns0 ... revertを検索する
  5. debugディレクティブの有無を確認する
  6. 1.11.4-18.azl3以上へ更新する
  7. CoreDNSプロセスまたはコンテナを再起動する
  8. DNS応答、ログ、coredns_panics_totalを確認する

この脆弱性では設定条件によって実際の影響が変わりますが、設定調査だけで対応を終了すべきではありません。Azure Linux 3.0ではRPMのReleaseを18以上へ更新し、実行中のCoreDNSへ修正版を確実に反映することが最終的な対応です。

Linux
EDNS0 Azure Linux DoS CoreDNS CVE-2026-62299

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次