まず、いま何が確定している事実なのかを3行でまとめます。

そして、多くの読者にとっていちばん大事な切り分けがこれです。

影響製品の範囲は NVD および Microsoft のセキュリティ更新ガイドに記載された「影響を受ける製品」リストで確認したものです。そこに含まれるのは SharePoint Enterprise Server 2016 / SharePoint Server 2019 / SharePoint Server Subscription Edition の3つのみで、SharePoint Online（Microsoft 365）は含まれていません。

第1章 おわり — 次は第2章

SharePoint を一言で言えば、会社の共有ファイル置き場と社内ポータルを兼ねたシステムです。

この図が、そのまま「なぜ狙われるのか」の答えになっています。攻撃者から見た SharePoint は、1か所を破れば会社の資料が丸ごと手に入る、非常に効率のいい標的です。加えて、社内の他のシステムと連携するために強い権限を持たされていることが多く、そこを足がかりに Active Directory やデータベースへ横に広がっていけるという性質もあります。

「SharePoint Online」と「SharePoint Server」は別物です

今回の件でもっとも誤解が多いのがここです。名前が似ていますが、誰がお守りをするのかが根本的に違います。

第2章 おわり — 次は第3章

攻撃の流れ自体は、教科書どおりです。まずはそこを押さえます。

ここまでは、よくある「サーバーの脆弱性が悪用された」という話です。今回が厄介なのは、この先です。

攻撃者が狙っているのは、データではなく「鍵」

実際の攻撃で観測されているのは、IIS machine key（マシンキー）の窃取です。これが今回の件の中心にあります。順を追って説明します。

この3つが揃うと、次のことが起きます。攻撃者が machine key を手に入れると、正規の署名が付いた ViewState を自分のパソコン上で自由に作れるようになります。そして ViewState はサーバー側でプログラム部品に復元される（＝デシリアライズされる）ため、そこにコードを実行させる仕掛けを紛れ込ませることができます。

これが、「パッチを当てました」という報告が安全の証明にならない理由です。脆弱性を修正しても、盗まれた鍵は自動的に無効になりません。攻撃者は以後、脆弱性を使う必要すらなく、正規の機能として堂々と入ってこられます。ログにも「正しい署名の付いた普通のリクエスト」として記録されるため、気づくのも簡単ではありません。

ちなみに、この「鍵を盗んで居座る」という手口は今回が初めてではありません。2025年7月に「ToolShell」と呼ばれた一連の SharePoint 攻撃でも、まったく同じ発想が使われていました。詳しくは第8章で比較します。

第3章 おわり — 次は第4章

2026年7月にオンプレミス版 SharePoint Server をめぐって問題になっている脆弱性は、実は7月に公開されたものだけではありません。4月・5月に公開されていた脆弱性が、7月になって悪用され続けているという構図が混ざっています。まとめて一覧にします。

最終確認日：2026年7月27日。CVSSはMicrosoftのセキュリティ更新ガイドおよびNVDの公開値、KEV追加日と是正期限はCISAのKEVカタログ、EPSSはFIRSTのAPI（2026年7月25日基準）で確認した値です。EPSSは「今後30日以内に悪用される確率の推定値」で、1.0が100%にあたります。この表の数字、とくにEPSSは日々変動します。CVE-2026-55040 の「未登録」も、今後KEVに追加される可能性があります。

この表には、初心者の方にも実務担当者にも役立つ3つの読みどころがあります。順に見ていきます。

読みどころ1：同じCVEに「5.3」と「9.8」の2つの点数が付いている

表の CVE-2026-56164 の行をご覧ください。Microsoft は 5.3（中程度）、NVD（米国政府の脆弱性データベース）は 9.8（緊急）と評価しています。約4.5ポイントの差です。これは誤報ではありません。同じ脆弱性に対して、2つの機関が独立に採点した結果、本当にこれだけ違ったのです。

読みどころ2：CVSS 9.8 が2件あるが、危険度は11倍違う

CVE-2026-50522 と CVE-2026-58644 は、どちらも CVSS 9.8 です。CVSSだけを見れば同じ危険度です。ところが EPSS を見ると、0.571 と 0.051 で約11倍の差があります。

この差の理由は明確です。CVE-2026-50522 は攻撃コード（PoC）が公開され、その数時間後に実際の悪用の成功が観測されました。セキュリティ企業 watchTowr のおとりサーバー（ハニーポット）が、7月20日のPoC公開後まもなく悪用の成功を記録しています。

さらに注意すべき点があります。PoCが公開される前の7月17日から、すでに悪用の試行そのものは観測されていました（セキュリティ企業 Defused の観測）。つまり「PoCが公開されたから攻撃が始まった」のではなく、先に攻撃が始まっていて、PoC公開が攻撃の規模を一気に押し上げたという順序です。パーセンタイルで見ると、この脆弱性は全CVEの上位1.03%に入る「今まさに使われている」脆弱性です。

読みどころ3：ならばどの順番で直すのが正しいのか

実務では「全部当てる」が正解ですが、テスト環境の検証や停止調整の都合で順番を決めなければならない場面は必ずあります。上の3ステップで並べ替えると、CVSS順とは違う結果になります。

第4章 おわり — 次は第5章

KEV は Known Exploited Vulnerabilities Catalog の略で、日本語にすると「悪用が確認された脆弱性のカタログ」です。米国のサイバーセキュリティ・インフラセキュリティ庁（CISA）が運用しています。

KEVが強い意味を持つのは、これが単なる情報提供ではなく命令の根拠になっている点です。米国の連邦政府機関は、KEVに載った脆弱性を定められた期限までに修正する義務を負います。

ここで注意したいのは、期限は一律ではないことです。CISA は2026年6月10日に運用指令 BOD 26-04 を発出し、「インターネットへの露出」「KEV該当」「自動化して悪用できるか」「技術的影響の大きさ」という4つの変数に応じて、期限を3日・14日・60日の3段階に分ける仕組みへ改めました。かつては2〜3週間の猶予が一般的でしたが、最上位の区分では3日しかありません。

今回のSharePointの5件を見ると、この違いがはっきり出ています。

4月に登録された CVE-2026-32201 だけが14日で、7月分の4件はすべて3日です。同じ製品の脆弱性でも、登録された時期と評価によって猶予が変わることが分かります。

CVSS・EPSS・KEV は、何がどう違うのか

脆弱性の「危険度」を表す指標は複数あり、混同されがちです。役割がまったく違うので、一度整理しておくと今後どんな脆弱性が出てきても迷いません。

第5章 おわり — 次は第6章

ここまでで「何が起きているか」は分かりました。次はあなたの組織が対象なのか、対象ならどれくらい急ぐべきなのかです。まず、危険な条件を並べます。

ただ、この一覧を見ても「自分がどれに当てはまるのか分からない」という方が多いはずです。そこで、6問の質問に答えるだけで、判定と期限、やるべきことが出てくる診断を用意しました。

第6章 おわり — 次は第7章

ここからは実際の作業手順です。ステップの順番には意味があります。特にステップ4・5とステップ6は、入れ替えると対策そのものが無効になります。上から順に進めてください。

1. 更新プログラムを適用し、適用が成功したことを検証する今すぐ

   2026年7月の累積更新プログラム（CU）を適用します。OSのWindows Updateだけでは終わりません。SharePoint の更新は製品固有の更新として提供され、適用後に製品構成ウィザードの実行が必要な場合があります。

   そして、ここがCISAがわざわざ念を押している点です。「適用したつもりで失敗している」ケースが実際に多いため、適用後にビルド番号を確認し、更新が本当に反映されたことを検証してください。ファーム構成（複数のサーバーを束ねて1つのSharePointとして動かす構成のこと）の場合は、全サーバーに適用されているかも確認します。

2. インターネットへの公開状況を確認する今すぐ

   今回の攻撃で最も危険なのは、インターネットから直接アクセスできる SharePoint です。CISAの推奨は明確で（以下は原文の要旨です）、「直接公開を避け、必要な場合は認証を行う L7 リバースプロキシの背後に置く」「Central Administration（管理画面）への外部アクセスをブロックする」です。ここでいう L7（レイヤー7）リバースプロキシとは、通信の中身（HTTP）まで見て振り分けを行う中継サーバーのことで、「認証を行う」とは、その中継サーバーの段階でログインを要求してから SharePoint に通す、という意味です。

   自組織の資産が外からどう見えているかは、Censys や Shodan で確認できます。自社のIP範囲やASNに限定して調べてください。

   # Censys ── 自組織のASNに限定して SharePoint Server を探す

   # 「自組織のASN」の部分は自社の値に置き換えてください
   # web.software 側も併記しないと、Webサービスとして認識された分を取りこぼします
   (host.services.software:(vendor:"microsoft" and product:"sharepoint_server")
     or web.software:(vendor:"microsoft" and product:"sharepoint_server"))
     and host.autonomous_system.asn = 自組織のASN

   # Shodan ── 自社のIP範囲・組織名に限定して探す

   # net: に自社のCIDR、または org: に自社の登録組織名を入れる
   "MicrosoftSharePointTeamServices" net:203.0.113.0/24
   "MicrosoftSharePointTeamServices" org:"自社の登録組織名"

   💡

   ASN とは

   AS番号（Autonomous System Number）は、インターネット上でIPアドレスの塊を管理している組織に割り当てられた識別番号です。自社でIPアドレスを保有していればその番号、そうでなければ契約しているISPやクラウド事業者の番号になります。自社のASNが分からない場合は、Censys や Shodan で自社の代表的なIPアドレスを1つ調べれば表示されます。クラウド事業者のASNで検索すると他社のサーバーも大量に出てくるため、その場合は自社のIP範囲（CIDR）で絞ってください。

   🚨 重要

   これらの検索は自組織が管理する資産の確認のみに使ってください。他組織の脆弱なサーバーを探す行為は、目的によっては不正アクセス禁止法などに触れる可能性があります。使い方の詳細はCensysの解説記事およびShodanのリファレンスをご確認ください。

3. AMSI と Microsoft Defender の状態を確認する今日中

   AMSI（Antimalware Scan Interface）は、Windows のマルウェアスキャン連携の仕組みです。SharePoint ではHTTPリクエスト自体を検査できるため、今回の種類の攻撃に対する非常に有効な緩和策になります。

   CISAは「AMSI連携が各Webアプリケーションで有効になっているか確認せよ」「可能ならリクエストボディのスキャンを Full Mode に」と推奨しています。「各Webアプリケーションで」という表現が重要です。設定はWebアプリケーションごとに個別なので、1つ有効でも他が無効という状態が起こりえます。

   # リクエストボディのスキャンを Full Mode にする（Subscription Edition 25H1 以降）

   $webApp = Get-SPWebApplication -Identity "http://（対象のURL）"
   $webApp.AMSIBodyScanMode = 2   # 0=Off, 1=Balanced（既定）, 2=Full
   $webApp.Update()
   # モードを切り替えたときは iisreset、またはアプリプールの再利用が
   # 必要になる場合があります（Microsoft公式のコード例にも同じ注記あり）

   なお、ボディスキャンは Subscription Edition のみで使えます（Early Release リングで先行提供され、Standard リングでは2025年9月の更新プログラム以降）。2019 / 2016 ではヘッダー等の検査までとなります。また、2025年9月の更新プログラム以降、AMSI連携は無効化できない必須コンポーネントになりましたが、それ以前から運用している環境では過去に無効化されたままの可能性があります。必ず実際の状態を確認してください。

   Microsoft Defender ウイルス対策側では、今回の攻撃に対応する検知名として以下が確認されています。これらの検知履歴がないかを確認してください。

   検知名	何を捉えるか
   Exploit:Script/ToolPaneAuthBypass.A	ToolPane系の認証バイパス（リクエストヘッダーの検査。全バージョン）
   Exploit:Script/ToolPaneAuthBypass.C	同系統のコード実行までをカバーする検知
   Exploit:Script/SuspSignoutReqBody.A	疑わしいサインアウトリクエストのボディ（ボディスキャン。Subscription Edition のみ）
   Backdoor:MSIL/LeakFang.A!dha	侵害後の署名鍵へのアクセス＝鍵収集ツールに対応する検知。この記事の核心にあたる部分なので、最も注意して確認してください

   あわせてCISAは、SharePointサーバーとデータベースの間の通信、およびファーム内の通信を必要な範囲に制限することも求めています。侵入されたあとの横展開を狭めるための措置です。

4. ログを確認し、侵害の痕跡を探す今日中

   パッチを当てたから調査は不要、ではありません。すでに侵入されていた場合、パッチは何も解決していません。以下を確認します。

   見る場所	探すもの
   IISログ C:\inetpub\logs\LogFiles\W3SVC（サイトID）\	/_layouts/15/ToolPane.aspx または /_layouts/16/ToolPane.aspx へのPOSTリクエスト。Referer が SignOut.aspx に偽装されているもの。_layouts 配下への異常に長いURIや見慣れないUser-Agent
   Webシェルの捜索 Webルート配下および ...\Web Server Extensions\16\TEMPLATE\LAYOUTS\	覚えのない新規・更新された .aspx ファイル。作成日時が攻撃時期と重なるもの
   設定ファイルの改変	web.config の machineKey セクションの変更、applicationHost.config への見慣れないIISモジュールの登録
   プロセスの振る舞い 最も信頼できる手がかり	w3wp.exe（IISのワーカープロセス）が cmd.exe / powershell.exe / csc.exe（C#のコンパイラ。攻撃コードをその場で組み立てるのに使われます）を子プロセスとして起動している形跡。SharePointの通常運用でこれが起きることはほぼありません
   永続化の仕掛け	新規のスケジュールタスク・サービス・レジストリのRunキー、覚えのないローカル／ドメインアカウント
   横展開の兆候	SharePointサーバーからの外向きのSMB / RDP / WinRM 通信、ファームアカウントの異常な利用

   ⚠ 注意：特定のファイル名を探すだけでは不十分です

   ネット上には spinstall0.aspx などのファイル名が「SharePoint攻撃の痕跡」として流通していますが、これは2025年の別の攻撃キャンペーンで使われたものです。2026年7月の攻撃については、Rapid7 が「公開されているネットワークベースのIOC（侵害指標）は存在しない」と明記しています。ファイル名の一致に頼らず、上記の「振る舞い」で探してください。

   なお、上の表に挙げた ToolPane.aspx へのPOSTや SignOut.aspx への Referer 偽装も、2025年に観測されたパターンと、Defender の検知名に「ToolPaneAuthBypass」が含まれることから「同系統と推定される振る舞い」です。2026年の攻撃について確定した公開IOCとして示されているものではありません。それでも探す価値は十分にありますが、これに一致しなかったことを「侵害なし」の証明にはしないでください。

5. 管理者権限と追加アカウントを棚卸しする今日中

   攻撃者が最初にやることの一つが、自分用の管理者アカウントを作ることです。以下を確認してください。

   ● SharePoint のファーム管理者・サイトコレクション管理者（サイトの集まりごとに置かれる管理権限）に覚えのないアカウントが追加されていないか
   ● サーバーのローカル管理者グループ、およびドメインの特権グループに予定外のメンバーがいないか
   ● サービスアカウントの権限がいつのまにか強くなっていないか
   ● 退職者・異動者のアカウントが残ったまま有効になっていないか

   ログ調査の具体的な進め方は、Windowsイベントログ・Sysmonの読み方で詳しく解説しています。

6. machine key をローテーションする ── ステップ4・5の駆除が終わってから駆除後すぐ

   第3章で説明したとおり、盗まれた署名鍵は、パッチを当てても無効になりません。無効化するには鍵そのものを作り替える（ローテーションする）必要があります。Microsoft が公式に手順を示しています。

   # machine key のローテーション（PowerShell・Microsoft公式手順）

   # 1) 新しい鍵を生成・設定する（鍵を省略するとランダム生成される）
   #    -Local を付けなければ、既定でファーム内の全サーバーへ配布される
   Set-SPMachineKey -WebApplication （対象のWebアプリケーション）
   
   # 2) 1) で -Local を付けて局所適用した場合のみ、他サーバーへ配布する
   Update-SPMachineKey -WebApplication （対象のWebアプリケーション）
   
   # 3) 全SharePointサーバーでIISを再起動する
   iisreset.exe

   1) と 2) は Microsoft Learn「Improved ASP.NET view state security and key management」に記載された手順です。3) の iisreset は同ページには記載がなく、2025年に Microsoft が出した緊急ガイダンス由来の手順です。

   画面から実行したい場合は、サーバーの全体管理 → 監視 → ジョブ定義の管理 → Machine Key Rotation Job → 今すぐ実行でも同じことができます。日本語UIでは「監視」ページの「タイマー ジョブ」グループの中にあります。

   🚨 重要：順序を間違えると、この作業は無意味になります

   CISAは「侵害痕跡（鍵を収集するツールを含む）を先に捜索・駆除してから、鍵をローテーションせよ」と順序を明示しています。攻撃者が鍵収集ツールを残したまま新しい鍵を作れば、その新しい鍵も生成された瞬間に盗まれます。合鍵を作り直しても、泥棒が家の中にいたままなら意味がないのと同じです。

   また、-Local オプションはローカルサーバーだけに反映されます。ファーム構成で負荷分散している環境では全台で鍵が揃っていないとセッションが失敗するため、原則として全台へ配布してください。

   なお、Subscription Edition の 25H1 および 2019 / 2016 の2025年9月更新プログラム以降は、毎週日曜に鍵を自動ローテーションするタイマージョブが標準で用意されています。ただし「侵害されたと分かった直後」は自動を待たず手動で実行してください。また Subscription Edition は web.config の machineKey セクションを既定で暗号化しており、設定ファイルを読まれても鍵が露出しにくくなっています。この保護は 2019 / 2016 にはありません。

7. バックアップの健全性を確かめ、必要ならパスワードを変更する今週中

   ここまでの調査で侵害の可能性が出てきた場合、あるいは念のための備えとして、次を確認します。

   ● バックアップが実際に復元できるかを検証する（取得しているだけで復元テストをしていない組織が非常に多いです）
   ● バックアップが攻撃者から書き換えられない場所にあるか（ネットワークから切り離したオフライン保管、または一度書いたら変更・削除ができない「イミュータブル保管」）
   ● ランサムウェアに展開された場合の初動手順が用意されているか

   パスワードの変更は侵害が疑われる場合に限って実施します。対象は SharePoint のファームアカウント・サービスアカウント、そしてそのサーバーで認証情報を扱っていた特権アカウントです。侵害が確認された環境では、パスワードだけでなくKerberosのkrbtgtアカウントやトークン類の扱いまで含めた本格的な封じ込めが必要になります。ここは自組織だけで判断せず、専門のインシデント対応を検討する段階です。

第7章 おわり — 次は第8章

SharePoint Server（オンプレミス）は、日本では一般に官公庁・地方自治体・大手製造業・医療機関・金融といった、外部クラウドへの移行に慎重な組織で使われていると言われています。機密資料や個人情報を自社の管理下に置きたいという要請があるためです。ただし、日本国内でのオンプレミス版 SharePoint の利用実態を示す統計は、本記事執筆時点では見つけられませんでしたので、以下は業種の傾向についての一般的な指摘としてお読みください。

ところがそれは同時に、攻撃が成功した場合にもっとも影響の大きい種類の組織が、もっとも影響を受ける構成を選んでいるという意味になります。到達点は情報漏えい・業務停止・ランサムウェアです。

日米で、警戒レベルが明確に違っています

ここは、この記事でお伝えしたい重要な点です。日本語の情報源だけを見ていると、今回の件は「月例のセキュリティ更新に含まれる、悪用確認済みの脆弱性が1件」という見え方になります。しかし米国側の扱いは、まったく違います。

JPCERT/CC・IPA の対応状況は、2026年4月と7月の月例注意喚起（JPCERT/CC「2026年4月／7月マイクロソフトセキュリティ更新プログラムに関する注意喚起」および IPA「Microsoft製品の脆弱性対策について(2026年7月)」）と、JPCERT/CC の2025年・2026年の注意喚起一覧を確認した結果です。比較期間は両列とも2026年4月〜7月にそろえてあります。両機関は Fortinet・Ivanti・Citrix などについては専用の注意喚起を出しており、SharePoint に出していないこと自体が特定の意図を示すものではありませんが、結果として日本語で得られる情報量に差が生じています。

露出台数は、調査機関によって大きく違います

「世界で何台が危険なのか」という数字を見かけますが、これは調べ方によって桁が変わります。正直に併記します。

約7倍の差があります。これは「どちらかが間違っている」というより、SharePointだと判定する条件の厳しさが違うためと考えられます（この理由を明言した一次情報は見つけられませんでした）。いずれにしても、数千台規模のサーバーが外から見える状態にあり、その一部にパッチが当たっていないという点は共通しています。

Censys の観測では、露出しているサーバーの最も大きな集中は Microsoft 自身のインフラ上にあり、次に AWS・Google Cloud・OVH・DigitalOcean・Hetzner が続きます。国別では米国が最多で、ドイツ・フランス・カナダ・イラン・オーストラリアが挙げられています。日本は上位国として挙げられていません。日本国内の被害事例が公表されたという情報も、執筆時点では確認できていません。

2025年と2026年、同じ手口が2年連続で通用してしまった

SharePoint のオンプレミス版が大規模に狙われたのは、今回が初めてではありません。ちょうど1年前の2025年7月にも「ToolShell」と呼ばれる一連の攻撃が起きています。並べると、構造の連続性がはっきり見えます。

そして、この記事でいちばん見落とされている事実

ここまで脆弱性の話をしてきましたが、実は2026年7月14日という日付には、もう一つの意味があります。

この数字が意味しているのは、「あと何日で危なくなる」ではなく「すでに何日、修理してもらえない状態が続いているか」です。半年後にこの記事を読んだ方の画面には、もっと大きな数字が表示されます。時間が経つほど状況が悪化する種類のリスクであることを、数字で確認しておいてください。

この表を見ると、Subscription Edition だけが全ての防御機能を備えていることが分かります。特に「machineKey が既定で暗号化されている」は今回の攻撃に直接効く保護であり、2019 / 2016 には存在しません。移行を検討する技術的な根拠になります。

第8章 おわり — 次は第9章

第9章 おわり — 次は第10章

🧩 理解度チェック（全3問）

この記事の内容が身についたか、3問だけ確認してみてください。答えをクリックすると解説が開きます。

Q1. CVSS 9.1 の脆弱性Aと、CVSS 5.3 だがKEVに登録済みの脆弱性B。先に対処すべきなのはどちら？

答え：B（CVSS 5.3 のほう）

KEVに載っているということは、実際にその脆弱性を使った攻撃が観測されているという意味です。一方、CVSS 9.1 は「悪用された場合に深刻」という予測にすぎません。今回の実例では、CVSS 5.3 の CVE-2026-56164 は公開当日にKEV登録され3日以内の修正を求められた一方、CVSS 9.1 の CVE-2026-55040 は本記事執筆時点（2026年7月27日）で悪用が確認されておらず、EPSSも 0.013 と極めて低い値でした。「点数の高いものから直す」運用は、最も危険なものを後回しにします。

※ CVE-2026-55040 は今後KEVに追加される可能性があります。この問題の要点は特定のCVEではなく、「悪用が確認されている脆弱性」を「スコアが高い脆弱性」より先に直すという考え方そのものです。

Q2. パッチを適用しました。次にやるべきことは？ ①署名鍵をローテーションする ②侵害の痕跡を調査して駆除する ③サーバーを再起動する

答え：②（侵害の痕跡を調査して駆除する）

署名鍵のローテーションは必要な作業ですが、順番が先だと無意味になります。攻撃者が「鍵を収集するツール」を仕込んだままだと、新しく生成した鍵もその場で盗まれてしまうためです。CISAは「侵害痕跡（鍵収集ツールを含む）を捜索・駆除してから鍵をローテーションせよ」と、明確に順序を指定しています。掃除をしてから鍵を替える、が正解です。

Q3. SharePoint Server 2019 を使っています。次のセキュリティパッチはいつ出ますか？

答え：出ません（2026年7月14日で延長サポート終了）

SharePoint Server 2019 と 2016 の延長サポートは、今回の Patch Tuesday とまったく同じ2026年7月14日に終了しました。今回配布された更新プログラムが、この2バージョンにとって最後のセキュリティ更新です。有償の延長セキュリティ更新（ESU）も提供されていません。これから新しい脆弱性が見つかっても、修正されることはありません。取るべき行動は「待つ」ではなく「露出を止める」と「移行を計画する」です。

第10章 おわり — この記事は以上です