英語版で読む
技術 約10分で読めます

Microsoft 2026年5月Patch Tuesdayの本命はDNS ClientとNetlogonの認証不要RCE、ZeroLogon・SIGRedとの位置づけで読む

Microsoft Windows セキュリティ 脆弱性 CVE RCE Active Directory DNS
いけさん目次

TL;DR

影響 Windows全環境。Netlogon RCE (CVE-2026-41089) でドメインコントローラー、DNS Client RCE (CVE-2026-41096) でDNS解決を行うすべての端末。両者ともCVSS 9.8、認証不要

緊急度 公開悪用ゼロ。Exploitability IndexはNetlogonがLess Likely、DNS ClientがUnlikely。CVSSスコアだけで判断しない（ZeroLogon・SIGRedの前例あり）

優先順位 Tier 1: ドメインコントローラー＋Dynamics 365 on-premises (CVSS 9.9)。Tier 2: DNS応答受信端末＋Office/Word RCE 4件＋SharePoint。Tier 3: その他Critical

周辺タスク Secure Boot 2011証明書が2026年6月から段階的に失効。2023証明書への移行をPatch Tuesday窓で進める

2026年5月Patch Tuesdayは137件のMicrosoft CVE、Critical 30件、公開悪用ゼロで着地した。
件数の多さよりも先に押さえるべきは、認証なしでネットワーク越しにコード実行へ進む2件、CVE-2026-41089 (Windows Netlogon) と CVE-2026-41096 (Windows DNS Client) だ。どちらもCVSS 9.8、攻撃ベクトルは AV:N/AC:L/PR:N/UI:N（ネットワーク・複雑性低・認証不要・ユーザー操作不要）。
ただしMicrosoftのExploitability IndexはNetlogonがLess Likely、DNS ClientがUnlikely。CVSSスコアだけで優先順位を決めると読み違える。

両CVEはWindows環境でわかりやすい歴史的前例を持つ。Netlogonの先輩がZeroLogon (CVE-2020-1472)、DNSの先輩がSIGRed (CVE-2020-1350)。脆弱性の原理は別物だが、攻撃面と影響範囲を理解する材料として並べておく。

CVE-2026-41089: Netlogonのスタックベースバッファオーバーフロー

CVE-2026-41089はNetlogon Remote Protocol (MS-NRPC) を処理する netlogon.dll のスタックベースバッファオーバーフロー。
MSRCのアドバイザリでは、攻撃者がドメインコントローラーとして動作するWindowsサーバーへ細工したネットワークリクエストを送ることで、Netlogonサービスがリクエストを誤って処理し、サインインや事前アクセスなしでコード実行に到達する流れが説明されている。

スタックベースバッファオーバーフローは、関数のスタックフレームに確保された固定長バッファ境界を越えてデータを書き込むバグだ。書き換えがリターンアドレスや例外ハンドラに届くと、制御フローが攻撃者の指す位置にジャンプする。ヒープオーバーフロー（後述するDNS Client側）と違い、スタック側はクラシックな攻撃面で、エクスプロイト経路が伝統的に整理されている。

ZeroLogon (CVE-2020-1472) との違い

ZeroLogonはNetlogonの認証プロトコル自体の暗号学的欠陥だった。AES-CFB8初期化ベクトルが全ゼロで使われていたため、認証情報なしでドメインコントローラーのコンピューターアカウントパスワードをリセットでき、結果としてドメインを丸ごと掌握できた。CVSS 10.0、Exploitability IndexはMore Likely、当時CISAは緊急指令で48時間以内のパッチ適用を要求した。

CVE-2026-41089は同じNetlogonを攻撃面とするが、メモリ破壊系の脆弱性で、暗号プロトコルの設計欠陥ではなく実装バグだ。ZeroLogonほど即時の信頼できるエクスプロイトが期待しにくいのは、スタックカナリア、ASLR、CFG (Control Flow Guard) といったWindowsの実行時保護が積み重なっており、メモリ破壊から制御奪取への到達経路が時代ごとに難しくなっているため。

ただし「実装バグだから安心」ではない。攻撃面はドメインコントローラーそのもので、成功時の影響範囲はZeroLogon相当だ。ExploitabilityがLess Likelyとされる根拠は「リライアブルなエクスプロイトを書くのが難しい」というMicrosoftの評価であって、「攻撃価値が低い」ではない。

CVE-2026-41096: DNS Clientのヒープベースバッファオーバーフロー

CVE-2026-41096は dnsapi.dll のDNS応答パーサーにあるヒープベースバッファオーバーフロー。
MSRCのアドバイザリでは、攻撃者が細工したDNS応答を脆弱なWindowsシステムへ送ることで、DNS Clientが応答を誤って処理し、メモリ破壊からコード実行に進む経路が説明されている。

ヒープベースバッファオーバーフローは、HeapAlloc 等で確保したメモリ領域の境界を越えて書き込むバグだ。隣接するヒープチャンクのメタデータや関数ポインタを汚染できると、後続のヒープ操作や仮想関数呼び出しを乗っ取れる。スタック側と違い、ヒープ側はメモリレイアウトが動的で、リライアブルなエクスプロイトには「ヒープグルーミング」と呼ばれる事前準備が必要になる。Exploitability IndexがUnlikelyとされているのはこのあたりの難しさを反映している。

SIGRed (CVE-2020-1350) との違い

SIGRedはWindows DNS Server側のヒープオーバーフローで、CVSS 10.0・wormable（自己拡散可能）として警戒された。DNSサーバーが受け取った悪性レスポンスを処理する経路で発火し、企業ネットワークのDNSサーバー群がワーム伝播の踏み台になるシナリオが想定された。

CVE-2026-41096はDNSクライアント側で、SIGRedと攻撃面が反転している。

  • SIGRed: DNSサーバー群が標的。台数は少ないが集中していて、企業はパッチを優先配布できた
  • CVE-2026-41096: DNS解決を行うすべてのWindowsホストが標的。ワークステーション、サーバー、ジャンプホスト、ビルドエージェント、すべてが対象になる

「悪性DNS応答を受信する経路」が攻撃の入口で、これには (1) 悪性ドメインへ問い合わせを誘導するアプリケーション動線（メール内リンク、HTML埋め込み画像のホスト名解決）、(2) 上流リゾルバの侵害、(3) ローカルネットワークでのDNSスプーフィングが含まれる。境界防御で「DNSは内側だから安全」とする想定は、エンドポイント側の脆弱性には当てはまらない。

Exploitability Index “Unlikely” / “Less Likely” の読み方

MicrosoftのExploitability Indexは4段階の評価軸だ。

ラベル意味運用上の解釈
Detected既知エクスプロイトが存在即時パッチ、原則攻撃進行中前提
More Likely30日以内にエクスプロイト出現を想定優先パッチ
Less Likely出現するが信頼性は低そう通常運用、ただし攻撃価値の高い対象は警戒継続
Unlikelyエクスプロイトには相当な研究が必要通常配布、ただし数年スパンで蒸し返される可能性あり

注意点が2つある。

1つは、Exploitability Indexは「短期的にリライアブルなエクスプロイトが出る確率」を評価しているのであって、「攻撃成功時の影響」ではない。DNS Client RCEがUnlikelyでも、エクスプロイトが書ければ全Windowsエンドポイントが対象になるという範囲は変わらない。

もう1つは、Microsoftの評価は外れることがある。SIGRedも当初は「実用可能なエクスプロイトの公開は時間がかかる」とされたが、概念実証は公開直後に出回った。CVSS 9.8 × Exploitability Unlikely の組み合わせを「無視していい」と読むのは、過去にも複数回その判断が外れている。

137件中Critical 30件の主要分布

カテゴリ主なCVE種別
Windows NetlogonCVE-2026-41089Unauth RCE (CVSS 9.8)
Windows DNS ClientCVE-2026-41096Unauth RCE (CVSS 9.8)
Microsoft OfficeCVE-2026-40358, CVE-2026-40363Local RCE (UAF / heap overflow)
Microsoft WordCVE-2026-40361 (他3件)Local RCE (UAF)
Microsoft SharePointCVE-2026-40365Authenticated RCE (Site Owner+)
Azure DevOpsCVE-2026-42826RCE CVSS 10.0 (顧客作業不要)
Dynamics 365 on-premisesCVE-2026-42898Authenticated RCE (CVSS 9.9)
Windows Native WiFi Miniport(Critical RCE)RCE
Windows GDI / Graphics(Critical RCE)RCE
Windows Hyper-V(Critical)EoP / Information Disclosure

特にWord系のRCEが4件まとまっているのが特徴的だ。.docx ファイルや埋め込みオブジェクトの解析経路でメモリ破壊系が複数同時に閉じられた格好で、メール添付ファイルやSharePoint上の共有ドキュメント経由のソーシャルエンジニアリングを想定する組織はOffice側の配布を優先する。

SharePoint CVE-2026-40365は認証要件があり (Site Owner以上)、外部公開SharePointのRCE脅威としては前月までの一連のToolShell系より一段下がる。ただしSharePoint Hybrid構成でSite Ownerトークンの管理が緩い環境では、実用的に悪用される経路として残る。

Azure側のCVE-2026-42826 (Azure DevOps、CVSS 10.0) は顧客作業不要扱いで、Microsoft側のロールアウト完了を待つだけになる。一方で同じCriticalでもDynamics 365 on-premisesのCVE-2026-42898はSaaSではないのでパッチ適用が必要。「クラウド側Critical」と「on-prem Critical」を一緒にして混乱しないようにする。

パッチ優先順位の整理

優先順位は環境特性ごとに変わるが、典型的なエンタープライズの場合は以下の順で考える。

Tierタイミング対象該当CVE
Tier 1即時ドメインコントローラーCVE-2026-41089 (Netlogon RCE)
Tier 1即時Dynamics 365 on-premisesCVE-2026-42898 (CVSS 9.9)
Tier 2当週内DNS応答を処理するWindows端末CVE-2026-41096 (DNS Client RCE)
Tier 2当週内Office / WordCVE-2026-40358 ほか
Tier 2当週内SharePoint ServerCVE-2026-40365
Tier 3通常配布Hyper-V / GDI / WiFi Miniportその他Critical
Tier 3通常配布Secure Boot2023証明書への移行

Tier 1の根拠: Netlogon RCEはDC（ドメインコントローラー）を直接狙う。エクスプロイト成功時の影響範囲がドメイン全体に及ぶため、Exploitability IndexがLess Likelyでも先に閉じる。Dynamics 365 on-premisesはCVSS 9.9で、社内サーバーが標的になりやすい。

Tier 2の根拠: DNS Client RCEは台数が多くて配布完了に時間がかかるため、Tier 1と並行で広域配布を開始しつつ、当週内を目標にする。Office系はメール添付経由の標的型攻撃で踏まれる側面があり、Officeアップデートチャネルが既に動いていればキャッチアップ確認のみ。SharePointは認証要件があるので一段下げる。

Tier 3の根拠: その他のCriticalは通常運用のWSUS / Intune配布で構わない。

検出のヒント

公開エクスプロイトがない時点ではIOCベースの検知は難しいが、攻撃が発生したときに振り返るための監視ポイントを整理しておく。

Netlogon (CVE-2026-41089) 側:

  • DCに対する外部発信元からのNetlogon (RPC over SMB) トラフィック。本来DCへのMS-NRPC通信はドメイン内端末からのもので、外部VPN・テナント境界越え・インターネット直接通信は異常
  • DCのSYSTEM 権限プロセスからnetlogon.dll がロードされていない場所への子プロセス生成
  • Windows Event Log 4742 (Computer Account Changed) や 5805 (Netlogon authentication failure) のスパイク

DNS Client (CVE-2026-41096) 側:

  • 異常に大きなTXT SRV NAPTR 等のDNSレスポンス、特に外部から内部端末への直接UDP/53 応答
  • dnsapi.dll をロードしているプロセスからの不審な子プロセス生成、または dnscache サービスのクラッシュ
  • 端末側DNS設定が意図しないリゾルバを向いている形跡

Sysmon Event ID 22 (DNS query) を集約している環境では、特定の端末から外部不審ドメインへの問い合わせ密度の変化が早期検知になりうる。

Secure Boot証明書の期限更新

2026年5月の更新窓では脆弱性対応とは別カテゴリで、Secure Boot証明書の更新がある。
2011年発行のSecure Boot証明書が2026年6月から段階的に期限切れに入り、2023年発行の証明書への移行がMicrosoft Learnのドキュメントで案内されている。

未更新端末でも起動と通常更新は継続する。ただしWindows Boot Manager、Secure Bootデータベース、失効リスト、起動前コンポーネントに対する新規の保護を受け取れなくなる。「起動しなくなる」ではなく「今後のブートレベル保護が伸びなくなる」という影響だ。

脆弱性パッチと違って即時性は低いが、UEFIブートキット系のマルウェアが新型を出してきたときに、未更新端末は防御の更新を受けられないリスクが残る。Patch Tuesdayと同じ更新窓で進められる運用タスクとして手を付けておく。

参考

過去記事との関連: