Windowsサーバーをブラウザでまとめて管理できるWindows Admin Center（WAC）に、**一般ユーザー権限からSYSTEMまで到達し得るローカル権限昇格（Local Privilege Escalation）脆弱性「CVE-2025-64669」**が確認されました。共有サーバーや踏み台（ジャンプ）運用、運用担当と一般ユーザーが同居する端末では、これが“想定外の近道”になりえます。いま自分の環境が対象か、どう塞ぐか、現場で揉めやすいポイントまで一気に整理します。 (nvd.nist.gov)
- 発生日時と何が「クリティカル」なのか
- 影響を受けるバージョン
- 原因は「フォルダが書ける」ただそれだけ…に見えて危険
- 攻撃の筋道（研究で語られた2パターン）
- 公式対応状況：まずはアップデートが正攻法
- 今すぐの回避策（アップデートまでの“つなぎ”）
- 監視と検知：攻撃の“気配”を拾えるか
- 他ユーザーの報告：温度感はどんな感じ？
- で、あなたはどう動く？（コメント欄が盛り上がる質問）
発生日時と何が「クリティカル」なのか
CVE-2025-64669は2025年12月11日にCVEとして公開され、CVSS 7.8（High）で評価されています。 (nvd.nist.gov)
ポイントは「外部からいきなり侵入」ではなく、いったん標準ユーザー（PR:L＝低い権限）として箱の中に入れた攻撃者が、WACの“管理用の仕組み”を踏み台にしてSYSTEMへ登れるところです。横展開の起点になったり、監視の目が薄い管理サーバーで決まると被害がでかい。 (nvd.nist.gov)
影響を受けるバージョン
影響範囲は「Windows Admin Center 1809.0 以降、2511未満（別表現では 2.6.2.6 未満）」が目安です。 (app.opencve.io)
ややこしいのが、WACは「2411」「2511」みたいな年月系の表記と、内部の2.x系バージョンが混ざって語られる点。NVD側ではCPEの観点から「2511未満が影響」と整理されています。 (nvd.nist.gov)
一方、発見元の研究では「特定版（例：2.4.2.1）で再現し、フォルダ権限の設計が根っこ」と説明されています。 (Cymulate)
あなたの環境、WACの表示は「2410/2411/2511」のどれですか？ コメント欄で型番（というか表記）だけでも置いていくと、同じ人が助かります。
原因は「フォルダが書ける」ただそれだけ…に見えて危険
根本原因はC:\ProgramData\WindowsAdminCenterが標準ユーザーでも書き込み可能（writable＝書き込み可）になり、そこで高権限プロセスがファイルを扱うことです。 (Cymulate)
脆弱性名の説明はNVDだと「Improper access control（不適切なアクセス制御）」で短いのですが、現場目線では「低権限が触れる場所に、SYSTEMで動く部品が荷物を置きっぱなし」みたいな状態です。置きっぱなしの荷物が“実行される側”だったから、事故が起きる。 (nvd.nist.gov)
攻撃の筋道（研究で語られた2パターン）
研究報告では、拡張機能のアンインストール悪用とアップデータのDLLハイジャック（DLL hijacking＝DLL差し替え誘導）の2経路が示されています。 (Cymulate)
1つ目は、拡張機能（Extension）のアンインストール処理の流れを利用して、署名済みスクリプト実行の“器”に乗っかる発想。2つ目は、更新プロセスが参照する場所に悪性DLLを置けることで、特権側がそれを読み込む形に誘導するものです。細部は環境で変わるけど、「書ける場所」と「特権で読む/実行する処理」が噛み合うと一気にSYSTEMまで届く、そこが本質。 (Cymulate)
公式対応状況：まずはアップデートが正攻法
Microsoft起点でCVEが発行され、修正は「WAC 2511以降（または 2.6.2.6 以降）」へ更新が軸になります。 (nvd.nist.gov)
MSRCの詳細ページ自体は閲覧にJavaScriptが必要な形式ですが、NVDとCVEレコード側に「2511未満が影響」「2.6.2.6未満が影響」という整理が出ています。 (nvd.nist.gov)
さらにMicrosoftのコミュニティ投稿でも、2511リリース前後でCVEへの言及が出ていて、現場が“パッチ待ち”になっていた空気が見えます。 (TECHCOMMUNITY.MICROSOFT.COM)
ここ、ちょい注意。海外記事の中には「2411以降へ」みたいな書き方もありますが、一次情報に寄せるなら「2511境界」を基準に考えるのが安全です。 (redhotcyber.com)
今すぐの回避策（アップデートまでの“つなぎ”）
更新できない事情があるなら、まず“低権限ユーザーが当該フォルダへ書けない”状態に戻すのが筋です。 (Cymulate)
やることは難しくなく、順番が大事です。
(1) WACが入っているサーバーで、C:\ProgramData\WindowsAdminCenter のアクセス許可を確認します。
(2) Users（一般ユーザー）やAuthenticated Users（認証済みユーザー）に書き込み権限が付いていないか見ます。
(3) 付いていたら、運用要件を満たす範囲で書き込み権限を外します（継承も要チェック）。
(4) 変更後、WACの更新・拡張機能追加・アンインストール等の運用手順が壊れていないか、管理者だけで一連を軽く通します。
(5) 可能なら最終的にWACを2511以降へ更新して、権限を“いじって耐える運用”から卒業します。 (Cymulate)
「権限いじるとWACが動かなくなるんじゃ？」という心配はわかります。だから(4)の確認が大事。ここで詰まった人、どこが壊れたかコメントで共有して…don’t be shy（遠慮しないで）。
監視と検知：攻撃の“気配”を拾えるか
Microsoft Defenderの検知名にCVE-2025-64669由来と思われるシグネチャが追加されています。 (Microsoft)
もちろん「検知がある＝安心」ではないです。けれど、管理サーバーで不審なPowerShell動作や、WAC関連ディレクトリ配下への不自然なファイル生成が見えた時、ラベルが付くのは助かる。SOCがいる組織なら、WACサーバーだけでもログ転送とアラートの優先度を上げておくと“寝てる間に終わってた”を減らせます。 (Cymulate)
他ユーザーの報告：温度感はどんな感じ？
Redditでは「修正が出た」「低権限→SYSTEMが成立する」といった共有が既に回っています。 (Reddit)
Xでも日本語で概要が回覧されていて、国内でも“WAC使ってる人”には刺さっている印象。 (X (formerly Twitter))
さらにMicrosoft Tech Communityのコメント欄では、CVEレコードへのリンク付きで「旧版にも修正を」みたいな声が出ていました。こういうの、現場の事情が透けて見えてリアルです。 (TECHCOMMUNITY.MICROSOFT.COM)
で、あなたはどう動く？（コメント欄が盛り上がる質問）
結論はシンプルで「2511以降へ更新」か「書き込み権限の是正＋監視強化」を今すぐやる、です。 (nvd.nist.gov)
ここから先は、環境の事情で答えが割れます。だから、雑談でもいいので教えてください。
あなたのWACは共有サーバーに入ってます？ それとも管理者だけの専用箱？
WACを踏み台にしているなら、その踏み台に“標準ユーザーがログオンできる設計”になってない？ そこ、実は一番危ない。
あと、更新作業が止まりがちな理由も知りたい。HA構成（高可用性）や手順の追従で詰まる、という声も見えてます。たぶｎ同じ沼が各社にあるはず。 (TECHCOMMUNITY.MICROSOFT.COM)
最後に一言だけ。WACは便利だからこそ、守りも“便利な前提”で組まれがちです。今回みたいな権限の穴は、攻撃者から見ると派手じゃないけど、刺さると速い。あなたの現場では、どんな手順で塞ぎますか？
