SharePoint認証バイパスが悪用中 7月更新の確認を

【更新 2026-08-21】本記事を見直し、修正しました。主な修正点：Progress LoadMasterの事例を「公表から39日でKEV登録」としていた記述を訂正しました。39日は実証コードの公開・攻撃の観測（2026年6月29日）からKEV登録（8月7日）までの日数で、公表（6月4日）からKEV登録までは64日です。

オンプレミス版のMicrosoft SharePoint Serverに、認証を素通りできる脆弱性 CVE-2026-55040（CVSS基本値9.1・緊急）があります。米CISAは2026年8月18日、この脆弱性を悪用が確認された脆弱性カタログ（KEV）に追加しました。対応期限は8月21日です。

結論から言えば、修正は2026年7月14日のセキュリティ更新プログラムにすでに含まれています。7月分（または8月分）を適用済みのファームは、この脆弱性については塞がっています。逆に「7月の更新をまだ当てていない」ファームは、実証コードが公開済みで悪用も確認された状態のまま、インターネットに面していることになります。まずファームのビルド番号を確認してください。なお、クラウド版のSharePoint（Microsoft 365）は本件の対象外です。

この記事でわかること：

• CVE-2026-55040で何が起きるのか（JWTの署名が検証されないという中身）
• 「Security Feature Bypass」という影響ラベルが、実際の破壊力と釣り合っていないこと
• ビルド番号による該当判定（2016 / 2019 / Subscription Edition の一覧）
• 7月更新のKBに書かれた「既知の問題」で、情シスが記録しておくべき設定
• サポート終了したはずの2016 / 2019に、8月の更新が出ているという事実

SharePoint Serverとは何者か、そしてどこに潜んでいるか

SharePoint Serverとは、社内の文書共有・ポータルサイト・業務ワークフローを構築するためのMicrosoft製オンプレミスサーバ製品です。注意すべきは単体で立っていないことが多い点で、同じファーム上または隣接して次の製品が動いています。

• Project Server 2016 / 2019：SharePointファーム上で動作する
• Office Online Server：Officeファイルのブラウザ閲覧・編集を担う（今回の8月更新でも別KBが出ている）
• Workflow Manager：7月更新のKBは、Workflow Manager利用中のファームには先にKB5002799の適用が必要だと明記している
• SQL Server：コンテンツデータベースの土台

「うちは積極的に使っていない」と思っていても、業務部門が資料置き場として育ててきたサーバが残っている構図は珍しくありません。資産管理台帳よりも、IIS上で /_layouts/ を返しているホストがあるかから探すほうが早いことがあります。

何が起きたのか：7月に修正された脆弱性が、1か月後にKEV入りした

CVE-2026-55040は、2026年7月14日の月例更新でMicrosoftとRapid7が共同で公表した脆弱性です。その後の経緯を時系列で整理します。

公表から悪用確認（KEV追加）まで35日、実証コードの公開からは7日です。実証コードが世に出た週のうちに攻撃が始まる展開は、当サイトで以前に取り上げたProgress LoadMasterの事例（実証コードの公開と攻撃の観測がいずれも2026年6月29日で、KEV登録はその39日後）でも同じで、いまや例外ではありません。月例パッチを「翌月の定例メンテで当てる」運用は、この速度に負けます。

SharePointは2026年に入って7件目のKEV入り

KEVカタログを集計すると、SharePoint関連の登録は累計15件、そのうち7件が2026年の登録です。

注目したいのは種類の偏りが今回崩れたことです。2026年のSharePoint悪用は「デシリアライズによるコード実行」が主流で、ASPXのWebシェル書き込みなどを検知ルールに落とし込んだ組織も多いはずです。しかしCVE-2026-55040は認証の偽装で、攻撃者は「正規ユーザーとしてログインした」ように見える通信をします。デシリアライズ前提の検知では、この形をそのままでは拾えません。

脆弱性の中身：署名が検証されていないJWT

Rapid7のStephen Fewer氏が2026年8月11日に公開した解析によると、原因はSharePointのJWT（JSON Web Token）検証処理に4つの欠陥が連鎖していることです。SharePointのサーバ間認証（S2S）は、外側のトークンに「actortoken」という内側のトークンを入れ子にした構造をとり、内側は本来、信頼された証明書で署名されているはずのものです。解析で示された欠陥を要約します。

1. 署名の必須化が無効：署名の要求がオフにされており、「アルゴリズムなし（alg: none）」のトークンが通る
2. 署名鍵の解決が無検証：内側トークンのヘッダにある証明書のフィンガープリント（x5t）で鍵を引くが、その時点で署名は検証されていない
3. 発行者の検証が緩い：信頼済みトークンサービスの一覧に該当証明書が無いと、発行者が無条件で受け入れられる
4. 署名の確認が「空でないこと」だけ：暗号的な検証は行われない

この4つが重なると、攻撃者は正しい鍵を一切持たずに、有効と判定されるトークンを組み立てられます。しかも鍵の手がかりになる署名証明書は、認証不要で読める /_layouts/15/metadata/json/1 というエンドポイントから取得できます。Rapid7の検証では、偽造したトークンで /_api/web/currentuser にアクセスすると、サイト管理者権限（IsSiteAdmin が true）を持つアカウントとして応答が返っています。

結果として、認証情報を一切持たない攻撃者がサイトの利用者や管理者になりすまし、コンテンツ閲覧・設定変更・権限変更・ファイル投入まで行えます。CVSSベクタは CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N で、機密性・完全性が「高」、可用性への影響は無し。サービスは落ちないので障害としては表面化しません。

「Security Feature Bypass」という影響ラベルの落とし穴

ここが今回いちばん実務に効く論点です。MSRC（Microsoft セキュリティ レスポンス センター）におけるこの脆弱性の影響区分は「Security Feature Bypass（セキュリティ機能のバイパス）」です。深刻度は Critical ですが、月例パッチの一覧を見慣れた担当者ほど、この文字列を「リモートコード実行より一段下」と読みがちではないでしょうか。

実際にはこれは完全な認証バイパスで、到達点はサイト管理者です。MSRCのFAQも「バイパスされうるセキュリティ機能は何か」という問いに対して、なりすましを許すため認証機能がバイパスされうる、と回答しています。名前の穏やかさと破壊力が釣り合っていません。

さらに厄介なのは、CVE-2026-55040の修正を含むKB5002882が、1本で36件のCVEを塞ぐ累積更新だったことです。KBの説明文には「情報漏えい」「リモートコード実行」「なりすまし」「セキュリティ機能のバイパス」「権限昇格」が並列に列挙されているだけで、どれが後に悪用されるかは書かれていません。月例パッチの件数から自社対象を絞り込む考え方は別記事に譲りますが、KBのタイトルや影響ラベルによるトリアージには限界があるというのが今回の教訓です。

MSRCの「悪用の有無」は執筆時点でも「No」のまま

2026年8月20日時点でMSRCのAPIを参照すると、CVE-2026-55040の exploited は「No」、公開情報の最終更新日は2026年7月14日（版数1）のままです。CVSSの時間評価値も E:U（実証コードの成熟度：未実証）が付いた7.9のままで、実証コードが公開され、CISAが悪用を確認した後の状態が反映されていません。

ベンダーの悪用フラグを優先度判定の唯一の入口にしていると、この脆弱性は「悪用されていない緊急」として棚に残ります。悪用の判断材料は、ベンダー・CISA KEV・JPCERT/CCを重ねて見る必要があります。同じ構図は7月のCVE-2026-50522でも起きており、前回の記事でも指摘しました。1回きりの例外ではなく、SharePointでは繰り返し起きているパターンだと捉えるべきです。

自社は該当するか：ビルド番号で判定する

SharePointは累積更新なので、判定はビルド番号1本で済みます。SharePoint 管理シェルで次を実行してください。

(Get-SPFarm).BuildVersion

サーバーの全体管理 →「アップグレードと移行」→「サーバーの製品とパッチのインストール状況の確認」でも確認できます。複数台構成では全サーバーで揃っているかを必ず見てください。1台だけ更新に失敗して古いまま残るのは、現場でよくある事故です。

8月のKBは7月のKBを置き換える扱いなので、右列のビルドに達していればCVE-2026-55040は塞がっています。目指すべきは右列です。なお2016と2019は「言語非依存」「言語依存」の2本立てで、両方の適用が必要になります。

なお、SharePointがHTTPレスポンスヘッダで返す MicrosoftSharePointTeamServices の値は 16.0.0.19725 のような形式で、4桁目のパッチレベルを含みません。外部スキャンでは適用状況を判定できないので、確認は必ずファーム側で行ってください。

あわせて確認したい露出：認証なしで応答するエンドポイント

攻撃の起点になる /_layouts/15/metadata/json/1 は認証なしで応答します。自社のSharePointがインターネットから直接叩ける状態になっていないかを確認する材料になります。VPNやリバースプロキシの内側に置く、アクセス元を絞るといった露出低減は、次のSharePoint脆弱性が来たときの猶予にもなります。

7月更新のKBに書かれた「既知の問題」を記録しておく

7月更新のKB（KB5002882など）の「Known issues in this update（このアップデートの既知の問題）」には、PSConfig実行後に次のPowerShellを実行するよう記載されています。見落としやすいので独立して書きます。

$farm = Get-SPFarm
$farm.DisableActorTokenAudienceValidation = $true
$farm.update()

Microsoftはこの設定について、開発中の多層防御機能を無効化するものであり、回帰（不具合）を起こす可能性があるためと説明したうえで、「既存のactorトークン検証は引き続き有効である」と明記しています。つまりCVE-2026-55040の修正そのものを無効化するものではありません。ここは誤解しないでください。

とはいえ、この設定が対象とする領域（actorトークンの受信者検証）は今回の脆弱性が突いた箇所と地続きです。押さえるべきは次の2点です。

• 自社ファームでこのフラグが $true になっているかを確認し、変更履歴として記録しておく。導入担当者がKBの指示どおりに実行したまま、誰も覚えていない、という状態が一番まずいところです
• Microsoftが後続の製品更新で修正すると書いている以上、いずれ元に戻す作業が発生する。運用手順書に「戻す条件」を書いておく

もう一点、同じ「既知の問題」に、複数フロントエンド構成でTrusted ProviderまたはFormsベースの認証を使っている場合に認証プロンプトが繰り返し出るという記載があります（Windows認証のファームには影響しないとされ、回避策はリバースプロキシでのスティッキーセッション設定）。重要なのは、MicrosoftがSessionCookieTransformProtectionEnabled の無効化は回避できるように見えても推奨しない、この設定は認証を保護するものだと明示している点です。目の前の不具合を消すために設定を落とす判断は現場で起こりがちなので、手順書に禁止事項として書いておく価値があります。

率直に言えば、「更新を当てたら認証がおかしくなった」は適用をためらわせる最大の要因です。7月更新の適用が遅れているファームがあるとすれば、この既知の問題が背景にある可能性は十分にあります。そして遅れている間に、その更新に含まれていた脆弱性が悪用段階に入ったのが今回の構図です。

サポート終了したはずの2016 / 2019に、8月の更新が出ている

前提が変わった話なので、はっきり書いておきます。Microsoftのライフサイクル情報では、SharePoint Server 2016と2019の延長サポート終了日はいずれも2026年7月15日 6:59:59（太平洋時間）＝実質2026年7月14日で、当サイトも7月の記事で「7月14日の更新が最後の1本」と書きました。ところが実際には、2026年8月11日に2016向けKB5002905 / KB5002906、2019向けKB5002894 / KB5002896が公開されています。KB5002894のページには「SharePoint Server 2019: August 11, 2026」と明記され、7月のKB5002883を置き換えると書かれています。

執筆時点で、サポート期間の延長を告げる公式アナウンスや、SharePoint Server向けのESU（有償の延長セキュリティ更新）提供は確認できていません。したがってこの8月更新が今後も続く保証はありません。実務上は次のように考えるのが安全です。

• 出ている更新は当てる。「サポートが切れたから当てても無駄」ではなく、8月分が現に出ている以上、適用対象として管理する
• 移行計画は緩めない。延長のアナウンスがない以上、次の月に更新が出ない前提で予算・スケジュールを組む
• 「更新が出ているからまだ大丈夫」を稟議の根拠にしない。根拠にできるのは公式のライフサイクル情報だけです

移行の全体像と、同じ日にサポート終了した周辺製品（Project Server、SQL Server 2016、InfoPath 2013など）については、SharePoint 2016/2019サポート終了の記事で整理しています。

更新を当てたあと、何を確認すべきか

未適用の期間があった場合、パッチ適用は入口を塞ぐだけで後始末にはなりません。今回の脆弱性はサイト管理者としての操作を許すものなので、確認の軸はコード実行系の侵害とは変わります。

• サイトコレクション管理者・サイト所有者グループの棚卸し：身に覚えのないアカウントが追加されていないか
• 権限の変更履歴：匿名アクセスや外部共有が有効化されていないか
• ファイルの追加・改変：ASPXなど実行可能な形式のファイルが投入されていないか
• 認証ログの見方に注意：偽造トークンによるアクセスは「正規ユーザーの正常なアクセス」として記録されます。失敗ログではなく、利用実態と合わない成功ログ（深夜帯、想定外の送信元IP、普段使わないAPIエンドポイント）を探すことになります

なお、SharePointではマシンキーの窃取が絡む攻撃も観測されており、その場合はパッチ適用後も正規に見えるリクエストを作られます。この論点は7月のKEV追加を扱った記事で詳しく整理しているので、そちらもあわせて確認してください。

現場目線：ラベルを読む仕事が増えている

正直なところ、今回いちばん気が重いのは「7月の更新を当てていれば終わっていた話」だという点です。作業自体は難しくない。難しいのは、月に数百件出るCVEの中から「これは後で悪用される」を見抜くことで、しかも影響ラベルが「Security Feature Bypass」だと優先順位は下がりやすい。そこへ「当てると認証まわりが不安定になるかもしれない」という既知の問題が重なります。少人数で回している情シスにとって「当てて壊れたら誰が対応するのか」は現実的な問いです。だからこそ判断を個人の目利きに委ねず、「KEVに載ったら期限内に当てる」という機械的なルールを先に決めておくほうが、結果として現場は楽になると感じます。目利きの精度を上げるより、目利きしなくていい領域を増やすほうが、続けられる運用ではないでしょうか。

情シスはどうすべきか

個別のチェックリストを自前で組むより、公的機関の指針を土台にしたほうが早く、社内説明にも使えます。

• 中小企業の情報セキュリティ対策ガイドライン（IPA）：資産の把握と、更新適用を運用に組み込む考え方。「そもそもSharePointが何台あるか」から始める組織はここから
• セキュリティインシデント対応 机上演習教材（IPA）：社内ポータルが乗っ取られた場合の連絡・判断の流れを、事前に一度なぞっておくための教材
• 対策のしおり（IPA）：SharePointに機密文書を置く利用部門向けの啓発資料として使えます

SharePointは情シスが主導して入れたとは限らず、利用部門が資料置き場として育ててきたケースが多い製品です。「どのサイトに何が置かれているか」を知っているのは情シスではない、という前提で棚卸しを進めるのが結局は一番効きます。

まとめ

1. CVE-2026-55040は認証を丸ごと素通りできる脆弱性で、CISAが8月18日にKEVへ追加した（対応期限8月21日）。修正は7月14日の更新に含まれており、8月11日の更新にも引き継がれている。まず (Get-SPFarm).BuildVersion で全サーバのビルドを確認する
2. 影響ラベル「Security Feature Bypass」とMSRCの「悪用: No」表示を、優先度判定の根拠にしない。実態は未認証でのサイト管理者なりすましで、ベンダー情報は執筆時点でも7月14日版のまま更新されていない
3. 7月更新のKBにある既知の問題（actorトークン検証の一時無効化・認証プロンプトの多発）は、設定変更として記録し、戻す条件まで手順書に残す。不具合回避のために SessionCookieTransformProtectionEnabled を無効化することはMicrosoftが推奨していない

出典

• Microsoft Security Response Center — CVE-2026-55040
• NVD — CVE-2026-55040
• CISA — Known Exploited Vulnerabilities Catalog
• Rapid7 — Microsoft SharePoint JWT Token Authentication Bypass (CVE-2026-55040)（2026年8月11日）
• KB5002882 — SharePoint Server Subscription Edition: July 14, 2026
• KB5002894 — SharePoint Server 2019: August 11, 2026
• Microsoft Lifecycle — SharePoint Server 2019
• Microsoft Lifecycle — SharePoint Server 2016