結論：パッチを当てても、マシンキーを替えていなければ侵入は続く
オンプレミス版Microsoft SharePoint Serverのリモートコード実行（RCE）脆弱性 CVE-2026-50522（CVSS 9.8）について、公開された実証コード（PoC）が出回った直後に実際の悪用が始まったと、2026年7月21日に報じられました（出典：The Hacker News「Critical SharePoint RCE CVE-2026-50522 Under Active Exploitation After Public PoC」、2026年7月21日）。この悪用の観測はセキュリティ研究者（watchTowr社）のハニーポット網での検知を報じた二次報道ベースであり、Microsoftや公的機関が公式に「日本国内での被害」を確認したものではありません。本稿でもその前提を守ります。
この脆弱性はMicrosoftの2026年7月のセキュリティ更新（Patch Tuesday）ですでに修正済みです。にもかかわらず経営として注意すべき点は、「パッチを当てたから安全」がこのケースでは通用しないことにあります。報道によれば、攻撃者はこの脆弱性を使ってSharePointサーバー（IIS）のマシンキーを1リクエストで窃取でき、窃取したキーで正規の認証トークンを偽造して利用者になりすませます。マシンキーはパッチを当てても自動では変わりません。つまりパッチ適用前に一度でもキーを抜かれていれば、パッチ後もそのキーを使って居座れる——これが今回の核心です。
なお本件は、米CISAが2026年7月22日に「悪用が確認された脆弱性カタログ（KEV）」へ追加しています。KEV入りは米連邦機関に是正期限を課す仕組みであり、日本企業に法的な義務が生じるわけではありませんが、「実際に悪用されていることを政府機関が認定した」という緊急度の目安として使えます。社内で優先順位を説明するとき、この一点は判断材料になります。
したがって、オンプレSharePointを運用している企業がやるべきことは、パッチ適用の確認だけでは足りません。「パッチ適用」「マシンキーのローテーション（再生成）」「すでに侵害されていないかの点検」の3点セットが必要です。さらに一歩引いて、ファイルサーバー代わりに古いオンプレSharePointを塩漬け運用しているなら、そのサーバーを持ち続けること自体が経営リスクになっていないかを今回を機に見直す価値があります。なお、クラウド版のSharePoint Online（Microsoft 365）は今回の対象製品には含まれていません。
EMERGENCY RESPONSE
この脆弱性、貴社システムは影響を受けますか？
影響範囲の一次評価を無料で実施。致命的脆弱性は24時間以内にアラートし、パッチ適用・恒久対応まで伴走します。
この記事を読むべき人
- 社内ポータルや文書共有のために**オンプレ版のSharePoint Server（2016 / 2019 / Subscription Edition）**を今も動かしている中堅・中小企業の経営者・役員
- 「数年前に構築したまま、ほぼ触っていない」SharePointがファイルサーバー代わりに残っている企業のIT責任者
- 情シスが0〜1名（あるいは兼任）で、脆弱性が出るたびに「パッチを当てれば大丈夫」で運用を回してきた実務決裁者
- 一度パッチを適用したものの、「本当にこれで安全なのか」「すでに入られていないか」に確信が持てない担当者
- 老朽化したオンプレ資産を持ち続けるべきか、クラウドやモダンな基盤へ移すべきかを判断したい経営層
何が起きたか：事実関係の整理
報道と一次情報（Microsoftの7月更新）を突き合わせると、今回のポイントは次の通りです。
横にスクロールして確認できます
| 項目 | 内容 |
|---|---|
| 脆弱性番号 | CVE-2026-50522 |
| 深刻度（CVSS） | 9.8（Critical） |
| CISA KEV登録 | 2026年7月22日に悪用確認済み脆弱性カタログへ追加（CISA） |
| 種別 | 信頼できないデータのデシリアライズによるRCE（リモートコード実行） |
| 対象製品 | SharePoint Enterprise Server 2016 / SharePoint Server 2019 / SharePoint Server Subscription Edition（いずれもオンプレミス） |
| 対象外 | SharePoint Online（Microsoft 365、クラウド版） |
| 修正 | Microsoftの2026年7月14日のセキュリティ更新で修正済み |
| 発見者 | DEVCOREの研究者（"splitline"）とされる |
| PoC公開 | 2026年7月20日ごろに実証コードが公開されたと報じられている |
| 悪用の観測 | watchTowr社が、PoC公開の数時間以内にハニーポット網で悪用試行を検知したと発表（二次報道ベース） |
| 位置づけ | 2026年7月更新後に悪用が確認されたSharePoint脆弱性としては3件目（先行はCVE-2026-56164、CVE-2026-58644。The Hacker News・SecurityWeekの集計による） |
技術的には、報道によれば、攻撃者はSharePointのサインインを扱うエンドポイント（/_trust/default.aspx）に、細工した.NETのデシリアライズ・ペイロードを送り込みます。処理系がこれを危険な経路でデシリアライズすると、サーバー上で任意のコードが実行され得ます。そしてこの入口を使って、攻撃者はサーバーのマシンキーを窃取します。
なお「3件目」という数え方は媒体によって異なり、別の集計では「1か月間で4件目」と報じる例もあります（出典：SecurityWeek「Fourth SharePoint Vulnerability Exploited in Past Month's Wave of Attacks」）。集計期間や対象の取り方で件数の表現は変わりますが、いずれにせよ短期間にオンプレSharePointを狙う攻撃が立て続けに起きているという趨勢は共通しています。
なぜ「マシンキー窃取」が厄介なのか
マシンキー（ASP.NETのmachineKey）は、SharePoint（IIS/ASP.NET）が認証トークンやViewStateなどの暗号化・署名に使う鍵です。ここが盗まれると、攻撃者は次のことができるようになります。
- 正規の認証トークンを自分で偽造できる。報道によれば、攻撃者は窃取したキーで有効な認証トークンを作り、利用者になりすまして、その権限でSharePointサイトや文書にアクセスできるとされています。
- パッチ後も入り直せる。脆弱性そのものはパッチで塞がれても、鍵が変わっていなければ偽造トークンは通り続けます。RCEの穴を塞ぐことと、盗まれた鍵を無効化することは別の作業です。
これが「パッチを当てたから安全」という思い込みの落とし穴です。今回のケースで研究者が繰り返し強調しているのも、**「パッチだけでは不十分（Patching is not enough）」「露出した可能性のある資産の認証情報はローテーションせよ」**という点です（出典：前掲The Hacker NewsおよびHelp Net Security「Another SharePoint RCE exploited: Patch, then rotate your machine keys」）。
補足として、SharePointのマシンキー窃取は今回が初めての手口ではありません。過去のSharePoint脆弱性の攻撃連鎖でも、マシンキーを抜いて永続化する動きが観測されてきました。裏を返せば、マシンキーのローテーションと侵害点検は「今回だけの特別対応」ではなく、オンプレSharePointを運用し続ける限り繰り返し必要になる保守作業だということです。ここに向き合えないなら、そもそも保有し続けるべきかという次の論点に進む必要があります。
既報との違い：本稿は「パッチを当てた後」を扱う
GXOではオンプレSharePointの脆弱性について、これまでにも角度を変えて記事を出してきました。今回のCVE-2026-50522は、それらとは扱う「フェーズ」が異なります。
- SharePoint脆弱性CVE-2026-45659がKEV入り｜修正期限7月4日｜こちらは別のCVEを扱い、「実悪用が確認され修正期限までにパッチを当てる」というパッチ適用の緊急性が主題でした。
- Copilot導入前のSharePoint権限棚卸し｜こちらは権限設計・棚卸し、つまり「誰が何を見られるか」の整理が主題でした。
本稿が扱うのは、それらの先にある**「パッチを当てた後」の対応**です。具体的には、パッチだけでは消えない痕跡（窃取されたキーによる永続アクセス）をどう潰すか、そして侵害の有無をどう点検するか。パッチ適用の話（前者）と権限整理の話（後者）を済ませていても、マシンキーのローテーションと侵害点検をやっていなければ、この観点は手つかずのままという点にご注意ください。
パッチ適用後にやるべきこと（点検チェックリスト）
「もうパッチは当てた」という企業ほど、次のチェックリストを一度なぞってみてください。抜けやすいのは太字の項目です。ここに挙げるのは一般的な対応の骨子であり、実際の手順は自社のバージョン・構成・Microsoftの最新ガイダンスに合わせて確認してください。
- 対象台数の把握：社内にオンプレSharePoint Server（2016 / 2019 / Subscription Edition）が何台あるかを即答できるか。「ファイルサーバー代わりに残っている1台」を見落としていないか。
- パッチ適用状況の確認：2026年7月のセキュリティ更新が全台に確実に適用されているか。テスト機・予備機・移行途中で放置された機体も含めて確認する。
- マシンキーのローテーション（最重要）：パッチ適用前にインターネットや社内から到達可能だった期間があるなら、マシンキーが窃取された前提でキーを再生成する。パッチだけで終えていないか。
- 侵害有無の点検：不審なアクセス、見覚えのないファイル（Webシェルなど）、異常な認証・アクセスログがないかを確認する。窃取されたキーでのなりすましは正規の認証に見えるため、「正常に見えるログ」こそ疑う視点が要る。
- 公開範囲の見直し：そもそもオンプレSharePointをインターネットに露出させる必要があるか。VPNや社内限定へ絞れないか。
- 記録と再発防止：今回の対応（適用日・キー再生成日・点検範囲）を記録し、次の脆弱性が出たときに同じ判断を素早く再現できるようにする。
このチェックリストで3番（キーローテーション）と4番（侵害点検）が空欄なら、「パッチを当てた」だけで安心してはいけない状態です。自社の情シスだけで4番の点検に確信が持てない場合は、後述の通り第三者の目を入れる判断が現実的です。
一歩引いた経営判断：オンプレSharePointを「持ち続けるか」
ここからは、目先の対応より一段上の論点です。今回のように、短期間で立て続けに緊急のパッチと追加対応（キー再生成・侵害点検）を迫られる資産を、情シス0〜1名の体制で持ち続けることが妥当なのか——という問いです。
塩漬け運用のオンプレSharePointには、次のような「見えにくいコスト」が積み上がっています。
- 保守負債：脆弱性が出るたびに緊急対応が発生し、そのたびに本業のIT投資が止まる。
- 属人化：構築時の担当者が退職・異動し、「触ると壊れそうで誰も手を出せない」状態になっている。
- 判断遅延：バージョンが古いほど、パッチ以外の対応（設定変更・回避策）の難度が上がり、対応が後手に回る。
こうした状態が続くなら、「毎回パッチと点検で消耗し続ける」道と、「クラウド移行やモダンな基盤へ載せ替えてこの種の緊急対応から降りる」道のどちらが安いかを、一度きちんと比べる価値があります。ファイル共有・社内ポータルの用途であれば、クラウド版（SharePoint Online / Microsoft 365）やその他のモダンな選択肢に移すことで、この記事で述べたような**「オンプレ特有の緊急パッチ地獄」から構造的に降りられる**可能性があります。老朽化した基盤をどう畳んで載せ替えるかは、レガシーシステムのモダナイゼーションとして検討できる領域です。
ここで大切なのは、「怖いから今すぐ全部クラウドに」と焦らないことです。判断すべきは、①その資産が今の事業にとってどれだけ重要か、②持ち続けた場合の保守負債はいくらか、③移す場合の移行コストとリスクはいくらか、を並べて比較すること。この比較を飛ばして「とりあえずパッチ」を繰り返すと、いつまでも同じ緊急対応に呼び戻され続けます。
ベンダー・支援先に確認すべき質問
外部の保守ベンダーや支援先にオンプレSharePointを任せている場合、今回の件を機に次を確認してください。「対応済みです」の一言で流されないための質問です。
- 「CVE-2026-50522のパッチは、当社の全台に適用済みですか。適用日はいつですか」
- 「パッチだけでなく、**マシンキーのローテーション（再生成）**は実施しましたか。していないなら、なぜ不要と判断したのですか」
- 「侵害の有無はどう点検しましたか。何のログを、どの期間、どんな観点で確認しましたか」
- 「今回のように立て続けに脆弱性が出る前提で、このオンプレSharePointを持ち続ける場合の年間保守負担と、クラウド移行した場合の比較を出せますか」
これらに具体的に答えられないベンダーに緊急対応を任せ続けるのは、リスクの高い選択です。逆に、ここまで踏み込んで説明してくれる相手なら、今後も付き合う価値があります。
よくある質問（FAQ）
Q. クラウド版のSharePoint（Microsoft 365 / SharePoint Online）を使っていますが、影響はありますか。 A. 報道によれば、今回のCVE-2026-50522の対象はオンプレミス版のSharePoint Server（2016 / 2019 / Subscription Edition）で、SharePoint Onlineは対象製品に含まれていません。ただし自社が「オンプレを1台も持っていない」と断言できるか、念のため棚卸しすることをおすすめします。
Q. 7月のパッチはもう当てました。これで対応は完了ですか。 A. パッチはRCEの穴を塞ぎますが、パッチ適用前にマシンキーを窃取されていた場合、そのキーは自動では無効化されません。研究者は「パッチだけでは不十分。露出した可能性のある資産の認証情報はローテーションせよ」と促しています。パッチ＋キーローテーション＋侵害点検の3点セットで考えてください。
Q. マシンキーを窃取されると、具体的に何が起きるのですか。 A. 報道によれば、攻撃者は窃取したキーで正規に見える認証トークンを偽造し、利用者になりすまして、その権限でSharePointのサイトや文書にアクセスできるとされています。パッチ後も偽造トークンが通り続けるため、キーを再生成しない限り居座られる恐れがあります。
Q. 実際に日本国内で被害は出ているのですか。 A. 現時点で公表されている悪用の観測は、海外のセキュリティ研究者（watchTowr社）がハニーポット網で検知した悪用試行を報じた二次報道が中心です。日本国内の具体的な被害を公的機関が確認したという情報は、本稿執筆時点では確認できていません。国内被害の有無を断定せず、自社の点検を進めることが現実的です。
Q. すでに侵害されているか、自社だけで判断できません。 A. 窃取されたキーによるなりすましは「正常な認証」に見えるため、通常のログ監視では気づきにくい性質があります。自社の情シスだけで侵害の有無に確信が持てない場合は、第三者による侵害調査（フォレンジック）を検討する段階です。
Q. この機会にオンプレSharePointをやめるべきですか。 A. 一概には言えません。判断材料は、その資産の事業上の重要度、持ち続けた場合の保守負債、移行コストとリスクの3点です。「怖いから今すぐ全部」ではなく、この3点を並べて比較したうえで、パッチ運用を続けるか載せ替えるかを決めるのが健全です。
GXOに相談すべきタイミング
最後に、GXOに第三者として声をかける価値がある「状態」を、判断基準の形で示します。当てはまるものが多いほど、社内だけで抱え込むより外の目を入れたほうが安全です。
- パッチは当てたが、マシンキーのローテーションと侵害点検が空欄のままで、それが何を意味するのか社内で答えが出ない——このように「パッチの先」で手が止まっているなら、セキュリティ診断で現状の抜けを棚卸しするところから整理できます。
- すでに侵害されていないかの確証が持てない、あるいは不審なアクセスの痕跡が見つかった——この段階は、セキュリティインシデント対応（フォレンジック調査）で、何がどこまで起きたのかを事実ベースで確認すべきサインです。「たぶん大丈夫」で進めるのが最も危険です。
- 毎回の緊急パッチと点検に情シスが消耗し続けている——目先の対応だけでなく、そのオンプレSharePointを持ち続けるべきか自体を見直す局面です。レガシーシステムのモダナイゼーションとして、保守負債と移行コストを並べて比較する検討ができます。
いずれの場合も、まずは「自社が今どの状態にあるか」を第三者と一緒に言語化するところからで構いません。緊急度や状況が読み切れないうちは、GXOへの相談窓口（お問い合わせ）から現状をそのままお伝えいただければ、パッチの先で何を優先すべきかの整理をお手伝いします。ベンダー言いなりでも、社内だけの手探りでもない「第三者の点検」を一度入れることが、この種の脆弱性に振り回され続けないための最短の一歩です。
参考文献
- The Hacker News「Critical SharePoint RCE CVE-2026-50522 Under Active Exploitation After Public PoC」
- Help Net Security「Another SharePoint RCE exploited: Patch, then rotate your machine keys (CVE-2026-50522)」
- BleepingComputer「Critical SharePoint RCE flaw exploited to steal machine keys」
- SecurityWeek「Fourth SharePoint Vulnerability Exploited in Past Month's Wave of Attacks」
- Microsoft Security Update Guide（2026年7月セキュリティ更新、CVE-2026-50522修正情報）
