AI時代に増えるMicrosoft更新、622 CVEをさばく三段階のパッチ運用

Microsoftが2026年7月14日に公開した月例セキュリティ更新は、現行のSecurity Update Guideで622件のMicrosoft CVEを収録する。この月次集合のうち、Patch Tuesday当日に初めて公表されたCVEは569件だった。ただ、管理者が最初に見るべき数字はどちらでもない。実際に悪用された3件、7月17日を含むCISAの対応期限、そして一部Dell端末にかかった配信停止を分けて扱わなければ、件数の多さが優先順位を隠してしまう。

622件と569件、数字がずれる理由

Microsoft Security Response Center（MSRC）の7月リリースノートは、7月16日更新の現行版で「622 Microsoft CVEs」と明記している。ここにはWindowsの416件、Officeの82件、Microsoft Edgeの46件、開発ツールの27件、SharePoint Serverの17件などが含まれる。同じCVEがOfficeとOffice 2016の両方に現れる場合があるため、製品ファミリー別の数字は足し算できない。

一方、CVRFデータを初回公表日で分けると、7月14日に公開されたMicrosoft CVEは569件だった。残る53件は7月2日から15日までの別日に公開されている。「570件」という数字はPatch Tuesday当日の概数として広がったが、MSRCの現行月次集計とも、CVRFの7月14日分とも一致しない。

428件のChromium CVEは、Microsoftが自社の622件へ加えて修正した数字ではない。MSRCが非Microsoft CVEを再掲載した集合である。したがって「合計1,050件をMicrosoftが修正した」とする数え方も誤りになる。

現行CVRFでは622件のうち62件がCriticalに分類される。影響別では権限昇格が256件、リモートコード実行が166件、情報漏洩が109件に達する。ただし、ここでも一つのCVEが複数の影響を持つ場合がある。総数は規模を示すが、導入順を決める指標にはならない。

CVSSより先に、実悪用3件

7月17日時点のMSRCデータで「Exploited: Yes」となっているMicrosoft CVEは3件ある。米Cybersecurity and Infrastructure Security Agency（CISA）は3件すべてをKnown Exploited Vulnerabilities（KEV）カタログへ登録した。米連邦政府機関向けの期限は、SharePointのCVE-2026-56164が7月17日、CVE-2026-58644が7月19日、AD FSのCVE-2026-56155が7月28日である。

CVE-2026-56164はCVSS 5.3のModerateだが、認証を経ずにネットワーク経由でSharePointの権限を引き上げられ、すでに攻撃で使われている。Microsoftは緩和策として、SharePointとIISワーカープロセスでAntimalware Scan Interface（AMSI）を有効にし、Request Body ScanをFullに設定するよう案内した。CVSSの点数だけで並べれば、この脆弱性を62件のCriticalより後ろへ送る危険がある。

CVE-2026-58644は扱いがさらに複雑だ。Microsoftは、パッチをリリース済みだったのに2026年6月のPatch Tuesday一覧からCVEを誤って漏らしたと記している。7月15日にはExploitability Index、実悪用フラグ、CVSSベクトルを訂正し、翌16日にCISAがKEVへ追加した。これは7月14日に初めて修正されたゼロデイではなく、過去の修正と現在の攻撃状況を結び直す更新である。

同じCVE-2026-58644の攻撃条件には、Microsoftの記述内で食い違いも残る。説明文は「unauthorized attacker」とし、CVSSベクトルはPR:Nを置く一方、FAQは少なくともSite Ownerとして認証済みの攻撃者を前提にする。管理者は認証要件の表記を理由に対応を遅らせず、実悪用の確認とCISAの短い期限を優先すべきだ。

公開済みだが実悪用を確認していないCVE-2026-50661もある。物理アクセスした攻撃者がBitLocker Device Encryptionを回避し、システムドライブの暗号化データへ到達し得る。Microsoftの評価はImportant、CVSS 6.1で、悪用可能性は「低い」とされる。インターネットに公開したSharePointと、盗難や端末接触を脅威モデルへ含むPCでは、同じ導入順にならない。

AIが増やす発見量と、減らない検証工程

Microsoft Windows + Devices担当エグゼクティブ・バイスプレジデントのPavan Davuluriは7月9日、AIによって各セキュリティリリースの更新量が増えると予告した。WindowsではMicrosoft Securityのmulti-model agentic scanning harness「MDASH」などを使い、重要なバイナリを走査する。候補は複数モデルで検討した後、Windows向けの別工程で脆弱性を再現する。そこで残る誤検知を落とし、エンジニアへ渡すという。

これは「AIが622件すべてを見つけた」という説明ではない。MSRCは、報告量が数年かけて増え、自動化が成熟し、外部研究者の参加も広がった結果だとしている。AIは発見と検証を加速する一因であり、人間はリスク評価とコードレビューに残る。

今回の622件は、インターネットに公開したSharePointから、物理アクセスを前提とするBitLockerまで攻撃条件が大きく異なる。Microsoft自身も、件数ではなく露出範囲と被害の大きさでトリアージし、Exploitability Index、実悪用、公開済みコードを合わせて見るよう勧める。利用企業は資産台帳と外部公開状況を随時更新し、その条件に応じて配布リングを組み替えなければならない。

Dell配信停止、RC4強制移行、Secure Boot更新

更新を急ぐべき局面でも、Microsoftは一部Dell端末へのKB5101650配信を止めた。対象はIntel Innovation Platform Framework Processor Participantドライバーを使う一部のWindows 11 24H2/25H2端末である。6月23日のプレビュー更新が導入したWindows USB-C Connection ManagerとIntel側コンポーネントが衝突し、性能や消費電力、システム動作が変化する場合がある。Windows Serverは対象外だ。

対象端末には更新が提示されない。MicrosoftとDellは解決策を準備しており、7月15日時点では数日以内に提供する計画だと説明していたが、配信再開日は示していない。管理者は更新を手動で入れて停止措置を迂回せず、対象モデルと修正版の告知を待つ方がよい。

サーバー側ではKerberosの変更が待っている。CVE-2026-20833への対策は1月の監査導入、4月のAES既定化を経て、7月更新で最終強制段階へ入った。一時的なロールバック用レジストリ値RC4DefaultDisablementPhaseは削除される。AES鍵を持たないサービスアカウントやRC4に依存する非Windows機器が残れば、サービスチケットの発行が拒否され、認証障害として表に出る。

Secure Boot証明書の更新も同時に進む。2011年発行のMicrosoft Corporation KEK CAは6月24日、Microsoft UEFI CAは6月27日に失効した。未更新端末は起動でき、通常のWindows Updateも受け取れるが、Windows Boot ManagerやSecure Bootデータベース、失効リストなど、起動前段階の新しい防御を受け取れなくなる。7月更新は、新しい2023年版証明書を自動配信する端末を増やす。

7月更新を三つの配布リングへ分ける

最初のリングには、CISA KEVに入ったSharePointとAD FSを置く。外部公開されたSharePointはCVE-2026-56164とCVE-2026-58644の更新状況を確かめ、侵害痕跡の確認も並行して進める。AD FSではCVE-2026-56155を適用し、すでに得られた低権限アクセスが管理者権限へ広がる経路を閉じる。

二つ目のリングは互換性検証である。Dellの対象端末は配信停止を維持し、ドメインコントローラーではKDCSVCのイベント201〜209からRC4依存を洗い出す。更新の成否だけを見ず、認証失敗と電力・性能の変化まで監視する。

三つ目で残るWindows、Office、開発ツールの更新を段階展開し、Secure Boot証明書の状態を確認する。今回の更新は、実悪用、互換性、資産の露出を使って配布順を変えなければ安全に展開できない。次の確認点は、Dell向けKB5101650の配信再開と、CVE-2026-58644の認証要件をMicrosoftがどう訂正するかである。