Microsoft DefenderのRedSunとUnDefendにCVEが付き実際の悪用も確認された

TL;DR

対象 Microsoft Defender / Microsoft Malware Protection Engine / Microsoft Defender Antimalware Platform

悪用確認 CVE-2026-41091 と CVE-2026-45498 は Microsoft が Exploited: Yes として公開。CISA KEVにも2026-05-20追加、連邦機関の期限は2026-06-03

修正バージョン Malware Protection Engine 1.1.26040.8 以降、Defender Antimalware Platform 4.18.26040.7 以降

確認箇所 Windows Security の保護更新、または PowerShell の Get-MpComputerStatus で AMEngineVersion と AMProductVersion

同時修正 CVE-2026-45584 はDefenderのRCE、CVSS 8.1。悪用確認はないが、同じエンジン更新で塞がれる

Microsoft DefenderのRedSunとUnDefendに、CVE番号と公式の悪用確認が付いた。
4月時点では、BlueHammerを含むDefender系PoCのうち、BlueHammerだけがCVE-2026-33825として4月Patch Tuesdayで塞がれていた。
残っていた2件が、今回それぞれCVE-2026-41091とCVE-2026-45498になった。

変わったのは「研究者のPoCとHuntressの観測」から「MicrosoftのアドバイザリとCISA KEV」に移った点だ。
CISA KEV（Known Exploited Vulnerabilities、実際の攻撃で悪用されたことが確認された脆弱性のカタログ）に入ったので、連邦民間行政機関では2026年6月3日までに対応する扱いになる。

RedSunはSYSTEM昇格、UnDefendはDefenderを止める側

今回の2件は、どちらもDefenderの問題だが性質が違う。

CVE	通称	種別	CVSS	修正対象
CVE-2026-41091	RedSun	ローカル特権昇格	7.8	Malware Protection Engine 1.1.26040.8
CVE-2026-45498	UnDefend	サービス拒否	4.0	Defender Antimalware Platform 4.18.26040.7
CVE-2026-45584	なし	リモートコード実行	8.1	Malware Protection Engine 1.1.26040.8

種別の略語ごとに、何ができる攻撃かを並べておく。

略語	何ができる攻撃か
LPE（ローカル特権昇格）	すでに端末に入った攻撃者が、一般ユーザー権限からSYSTEM権限へ上げる。単体では侵入の入口にならず、侵入後に足して使う
DoS（サービス拒否）	対象のサービスやプロセスを止める・応答不能にする。ここではDefender本体を機能停止・劣化させる用途
RCE（リモートコード実行）	攻撃者の用意したコードを端末上で実行させる。ネットワーク経由で、ユーザー操作なしに成立しうる

CVE-2026-41091は、Microsoftの説明では「ファイルアクセス前のリンク解決」の不備だ。
攻撃者はローカルで認証済みの状態から、Defenderの処理を経由してSYSTEM権限へ上げる。
NVDではCWE-59（リンク追跡、つまりシンボリックリンクやジャンクションのような参照先解決を誤る弱点）として扱われている。

Vectra AIとHuntressの解析だと、RedSunはTieringEngineService.exeを狙う。
攻撃者はファイル内にEICARテスト文字列（アンチウイルスの動作確認用に使われる無害な検出シグネチャ）を仕込んでDefenderのリアルタイム保護を誘発し、Defenderがファイルを書き換える瞬間のレースに勝って、保護対象のシステムパスへ攻撃者のバイナリを送り込む。
Huntressは、4月のPatch Tuesday適用後のWindows 10 / Windows 11 / Windows Server 2019以降でもこのRedSunが成立すると報告している。
つまり「OSは最新」でもDefender側のエンジンが古ければ残る。

CVE-2026-45498はDoSだ。
Microsoft側のCVSSは4.0で、単体では「端末を乗っ取る」脆弱性ではない。
ただし4月の観測では、BlueHammerやRedSunのようなSYSTEM昇格のあとにUnDefendを使い、Defenderの定義更新を妨害して検知精度を時間をかけて落とす流れが見えていた。
派手なクラッシュではなく、アラートを出さずにじわじわ保護を削るのがUnDefendの使われ方になる。
CVSSだけ見ると低く見えるが、侵入後にDefenderを鈍らせる用途なら影響は端末クラッシュより重い。

同じ更新でCVE-2026-45584も塞がれる。
こちらはMalware Protection Engineのヒープベースバッファオーバーフローで、CVSS 8.1のRCEだ。
MicrosoftとNVD上では悪用確認なしだが、Defenderが受け取ったファイルを自動スキャンする性質を考えると、エンジン更新が止まっている端末では別の攻撃経路として残る。

自動更新でもバージョン確認まで見る

MicrosoftはDefenderのマルウェア定義、エンジン、プラットフォームが既定で自動更新されるため、通常は追加操作なしで修正されるとしている。
この説明は家庭用PCや通常の企業端末ではだいたい正しい。

注意したいのは、Defenderの更新が三層に分かれている点だ。
それぞれ配信頻度も経路も違うので、「Windows Updateが当たっている」ことと「エンジンが新しい」ことは同じではない。

層	何が入っているか	更新頻度の目安
セキュリティインテリジェンス（定義）	マルウェアのシグネチャ	1日数回
Malware Protection Engine（エンジン）	スキャンの実行コード本体（今回のRedSun/RCEの修正先）	月1回程度
Antimalware Platform（プラットフォーム）	Defenderのサービス基盤（今回のUnDefendの修正先）	月1回程度

今回の修正は下の2層、つまりエンジンとプラットフォームに入る。
定義だけが頻繁に更新されていても、エンジンとプラットフォームが古いままなら今回の3件は塞がれない。

管理下のWindowsではここがずれやすい。
VDIのゴールデンイメージ、長期間オフラインの端末、閉域ネットワーク、プロキシ越しの更新、EDR移行中の端末では、Windows Update本体とDefenderのエンジン更新が同じタイミングで揃わないことがある。

VDIのゴールデンイメージは、固めた時点のエンジン・プラットフォームが大量の派生端末にそのまま展開される。イメージを焼き直さない限り古いまま増える
閉域・オフライン端末は、外向きの更新経路がないと定義もエンジンも止まる。WSUSやMicrosoft Defender for Endpointのフォールバック順を見ておく
プロキシ越しの環境では、定義更新（軽い）は通っていてもエンジン更新（重い・別配信）だけ落ちていることがある
EDR移行中で別製品をアクティブにしている端末は、Defenderが受動モードに落ちて更新が止まっていることがある

今回確認する値はOSビルドではなく、Defender側のエンジンとプラットフォームだ。
PowerShellなら次で確認できる。

Get-MpComputerStatus |
  Select-Object AMEngineVersion, AMProductVersion, AntispywareSignatureVersion, AntivirusSignatureLastUpdated

AMEngineVersion が 1.1.26040.8 以上なら、CVE-2026-41091とCVE-2026-45584側のエンジン更新を受けている。
AMProductVersion が 4.18.26040.7 以上なら、CVE-2026-45498側のプラットフォーム更新を受けている。

古い場合は、Update-MpSignature で更新を手動でトリガーできる。
それでも上がらないときは、MpCmdRun.exe -SignatureUpdate を直接叩くか、プロキシ・WSUS・配信経路の設定を疑う。
VDIのゴールデンイメージは端末側で叩いても次回展開で戻るので、イメージ自体を更新する。

Windows Securityアプリから見る場合は、ウイルスと脅威の防止 から 保護の更新 を開き、更新確認後に 設定 の バージョン情報 でAntimalware ClientVersionを確認する。

Defenderを無効化している端末は別扱いになる

The Hacker Newsが引用したMicrosoftの説明では、Microsoft Defenderを無効化しているシステムは今回の脆弱性の影響を受けない。
これはDefenderの該当コンポーネントが動いていないなら、RedSunやUnDefendの攻撃経路も成立しない、という意味だ。

ただし、それを緩和策として扱うのは違う。
Defenderを止めている端末は、別のEDRやアンチマルウェア製品で同等の保護を持っているか、Microsoft Defender for Endpointの状態管理上で意図通りのモードになっているかを確認する対象になる。
「脆弱なDefenderではない」ことと「端末保護がある」ことは別の確認だ。

特に今回のようなローカル特権昇格は、初期侵入のあとに踏まれる。
FortiGate VPN、ブラウザ、Office添付、開発ツール、npmやVS Code拡張など、入口は別にあって、Defender側は権限昇格と防御低下の段で使われる。
5月Patch Tuesdayで扱ったNetlogonやDNS ClientのRCEとは攻撃経路が違い、更新確認の単位もOS更新ではなくDefender更新になる。

PoC公開からKEV入りまでの時系列

RedSunとUnDefendは、いきなりCVEとして出てきたわけではない。
4月に研究者がPoC（概念実証コード、攻撃が成立することを示す実証用コード）を先に公開し、現実の侵入で使われ、その後にCVE採番とKEV入りが追いついた。
Vectra AI、Huntress、Help Net Securityの記事をつなぐと、おおよそ次の流れになる。

flowchart TD
    A["4/3 BlueHammer PoC公開<br/>研究者がMSRC無反応への抗議として投下"] --> B["4/10 BlueHammerの実環境悪用を観測"]
    B --> C["4/14 BlueHammerをCVE-2026-33825として修正"]
    C --> D["4/16 RedSun と UnDefend のPoC公開<br/>同日に実環境悪用も観測"]
    D --> E["RedSun と UnDefend は未修正のまま残る"]
    E --> F["5/20 CISA KEVに両CVEを追加<br/>連邦機関の期限 6/3"]
    F --> G["5/21 RedSun=CVE-2026-41091<br/>UnDefend=CVE-2026-45498 として修正"]

PoCを公開したのは、GitHub上でChaotic Eclipse（別名Nightmare Eclipse）を名乗る匿名の研究者だ。
Help Net Securityによれば、Microsoft Security Response Centerへの報告が進まなかったことへの抗議として、パッチなしでPoCを出したとされる。
BlueHammerはこの流れで4月14日にCVE-2026-33825として塞がれたが、RedSunとUnDefendはパッチが追いつかず、4月16日の公開と同時に悪用が観測された。

その後の5月20日にCISAが両方をKEVへ入れ、翌21日にMicrosoftがRedSunをCVE-2026-41091、UnDefendをCVE-2026-45498として修正した。
公開時点では「PoCはあるが番号もパッチもない」状態だったものが、KEV入りと採番でようやく公式の扱いになった。

4月から5月で見え方が変わった

4月時点のBlueHammer記事では、Defenderを起点にしたCloud Files APIやVSSまわりの悪用が中心だった。
そこから5月に入り、YellowKey、GreenPlasma、MiniPlasmaとChaotic Eclipse系のWindowsゼロデイ公開が続いた。
今回のRedSunとUnDefendのCVE化は、その流れのうちDefender部分が公式アドバイザリへ回収された形になる。

PoC公開後にCVEが付き、CISA KEVへ入り、修正がDefenderの自動更新経路で配られる。
この流れだと、管理者側で最後に残るのは「Microsoftが配ったか」ではなく「自分の端末群に届いたか」になる。