セキュリティ

Microsoft 4月パッチ165件、史上2位の異常規模

Microsoftが4月のPatch Tuesdayで165件のCVEを修正した。月例として同社史上2番目の規模で、背景にはAI支援によるバグ発見の急増と、研究者がDefenderゼロデイを公開した事件があった。

情報の灯台

2026年4月15日

月例としては異例の165件

今月のPatch Tuesdayは、平月の倍近い数字を叩き出した。ZDI(Zero Day Initiative)のDustin Childsによれば、Microsoftの月例リリースとしては歴代2位の規模だという。1位は昨年10月の167件なので、まさに僅差での2位である。

普通なら「Microsoftが頑張ってパッチを出した」で済ませてよい話だ。しかしこの165件という数字は、単なる頑張りの結果ではない。Childsは「多くの脆弱性プログラムでAIツールによって発見された報告が急増している」と指摘し、自身のZDIでも受信レートが 基本的に3倍 になり、トリアージが課題になっていると述べた。

つまり、AIがバグを見つけすぎて、修正側が追いつかなくなりつつある。

Microsoft自身もこの流れを認めている。同社は本誌(The Register)の取材に対し、今回のリリースが「AI駆動の発見が大幅に増加したことを反映しているわけではない」としつつも、 Anthropicの研究者 がClaudeを使って発見した脆弱性1件をクレジットしたと明かした。

MSRCは毎年、社内外の研究者から数千件の脆弱性報告を処理している。そのため各月のリリース件数は変動する。ーMicrosoftはThe Registerの取材にこう補足している。

1件だけ、と言い切ったのは慎重な言い回しだ。裏を返せば、残り164件の中にAI支援で見つかった報告がどれだけ混ざっているかは、Microsoft自身もはっきり線引きできていないということだろう。

攻撃に使われていたSharePointのゼロデイ

今月唯一「攻撃に使われている」と明記されたのが、CVE-2026-32201だ。

SharePoint Serverの入力検証に不備があり、 CVSSスコアは6.5 、攻撃者はネットワーク越しに スプーフィング (なりすまし)を実行できる。しかもMicrosoftは、誰が報告したのか、どう悪用されていたのか、具体的な情報を出していない。

数字だけ見れば6.5は中程度で、派手な緊急度ではない。だが影響範囲を考えると話は違ってくる。Computer Weeklyの報道によると、Automoxのシニアセキュリティエンジニアは、このCVSSスコアがユーザーへのリスクを過小評価していると述べている。認証も特殊な権限も不要で、インターネットに公開されたオンプレミスのSharePoint サーバーが最も高いリスクにさらされるからだ。

SharePointは社内コラボレーションの中枢として、バックエンドのストレージやディレクトリサービスと接続されているケースが多い。そこに認証不要でなりすませるとなれば、フィッシングのリンクを正規URLに偽装する、改ざんした文書を正規文書に見せかける、といった応用が一気に開ける。

「スプーフィング」と言われると軽く聞こえるが、信頼そのものを偽造できる脆弱性は、ランサムウェアや標的型攻撃の入口として極めて有用だ。パッチ適用は急いだほうがいい。

公表済みのもう一つのゼロデイ、Defenderの「BlueHammer」

もう一つ、今月のリストで注目すべきなのがCVE-2026-33825、Microsoft Defenderの権限昇格の脆弱性だ。こちらは攻撃こそ観測されていないが、パッチより先に公表されていた。

Microsoftの公式アドバイザリでは触れられていないが、複数のセキュリティ企業が指摘している通り、この脆弱性は「BlueHammer」として知られるゼロデイと一致する。コードは今月初めにGitHubに投稿され、「Chaotic Eclipse」を名乗る不満を抱いた研究者が公開したものだ。

BlueHammerの技術的な中身は、単なる実装バグではない。Windows Defender、Volume Shadow Copy Service、Cloud Files API、opportunistic lock。それぞれ正規の機能であり、単体ではバグではない。問題は、これらを特定のタイミングで連鎖させたときにだけ現れる。いわば アーキテクチャレベルの歪み だ。

研究者とMSRCの決裂

このゼロデイが公開された経緯が興味深い。

Chaotic Eclipseは4月2日の個人ブログで、Microsoft Security Response Center(MSRC)の対応に業を煮やしてコードを放流したと明かした。本人の言葉によると「ブログとGitHubアカウントを新しく開いてコードを投下するつもりなんてなかった。でも誰かが我々の合意を破って、何もない状態で俺を放り出した」という。

彼の不満の核心は、MSRCの手続き上の要求にある。cryptika.comの報道では、研究者は脆弱性報告の一環として、エクスプロイトの動画提出を求められたと言及している。これは多くのセキュリティコミュニティにとって異例で負担の大きい要求とされる。MSRCはこの要求をあえて摩擦として使い、結果的に案件を解決させずに停止・クローズに持ち込んだのではないかと研究者は示唆している。

さらに踏み込んだ指摘もある。Chaotic Eclipseによれば、MSRCの品質は近年著しく低下している。原因は、Microsoftが経験あるセキュリティ人員を解雇し、代わりに手順書どおりに動くスタッフを据えたことにあるという。

これはただの愚痴ではない。コードにも皮肉が仕込まれている。PoCコードに埋め込まれたCloud FilesプロバイダとパスワードはそれぞれIHATEMICROSOFTと$PWNed666!!!WDFAILで、研究者のベンダーへの姿勢を隠すつもりが全くないことを示している。怒れるソースコードというのも、そうそう見られる光景ではない。

BlueHammerの技術的な本質は「どれか一つのコンポーネントにバグがある」ではなく、「複数の正規機能が想定外の順序で連鎖したときに生まれる権限昇格」である。部品ではなく、設計全体の問題だ。だから署名ベースの検出では根治できない。

実際、Microsoftは既存PoCバイナリをDefenderの定義に追加したが、研究者はX上で「コード更新はバグを直していない、検出をやや難しくしているだけだ」と投稿した。署名検出は、要するにモグラ叩きでしかない。

他にもクリティカル級が複数

SharePointとDefenderばかりが注目されがちだが、今月のリリースにはクリティカル評価のものも混ざっている。

Tenableの分析によれば、Windows Internet Key Exchange(IKE) Service ExtensionsのRCE(CVE-2026-33824)は CVSS 9.8 でクリティカル。IKE version 2が有効な対象に細工したパケットを送ることで、認証なしの攻撃者が悪用できる。即時パッチが難しい場合の緩和策として、UDPポート500と4500に対するファイアウォールルールが案内されている。

さらにBitLockerのSecure Bootバイパス(CVE-2026-27913)もある。現時点で悪用は観測されていないが、Microsoft自身が「悪用される可能性が高い」と評価した脆弱性だ。管理者にとっては、優先順位をつけること自体が作業になる規模である。