ハッカーが2つのSharePoint脆弱性を連鎖させてサーバーを完全掌握

オンプレミスのMicrosoft SharePoint Serverに対する概念実証（PoC）エクスプロイトチェーンが、実際の攻撃で使用され始めています。「研究者が手法を公開」してから「攻撃者が武器化」するまでの期間はわずか1日でした。これは、最新のSharePoint悪用の中心となる認証バイパスCVE-2026-55040について、研究者Defusedが報告したタイムラインであり、BleepingComputerの報道によるものです。

このチェーンは2つの異なる脆弱性を組み合わせています。CVE-2026-55040はJWTトークン認証バイパスであり、認証されていない攻撃者が有効な認証情報を提示することなく、SharePointサイトのユーザーやサイト管理者として振る舞うことを可能にします。CVE-2026-63520は、SharePointのBusiness Connectivity Services（BCS）に存在する別の脆弱性で、攻撃者が認証をバイパスした後、未修正サーバー上でリモートコード実行（RCE）に連鎖させることができます。Rapid7のStephen FewerがCVE-2026-55040の概念実証コードを8月11日に公開し、VulnCheckのJonathan PetersonがCVE-2026-63520の概念実証コードを8月24日に公開しました。最初の公開から約2週間で、業界はSharePoint Server上でゼロアクセスからコード実行までの実用的なパスを手に入れたことになります。

機密データの交換、保存、共同作業のためにオンプレミスのSharePoint Serverを運用している組織にとって、これは単なる注意喚起ではありません。これは、プラットフォームが今も攻撃者にとって生きた標的であり、しかも多くの運用組織よりもその認証や統合レイヤーを深く理解している攻撃者に狙われていることの証明です。CVE-2026-55040自体は2026年7月14日に修正され、同時にCISA Known Exploited Vulnerabilitiesカタログにも5件のエントリーが追加されました。しかし、7月からパッチが存在していたにもかかわらず、今月の概念実証による悪用は止まりませんでした。なぜなら、未修正インスタンスが依然として到達可能であり、新たに公開されたBCSの脆弱性が、古いバイパスを完全な侵害へと変換する新たな手段を攻撃者に与えているからです。

本記事では、2つのCVEが実際に何を引き起こすのか、なぜ1日で武器化されたことがCVSSスコア以上に重要なのか、そしてこのパターンがKiteworksのようなセキュアデータ交換プラットフォームを利用するCISOやコンプライアンス責任者にとって、隣接インフラで何が起きても機密データのコントロールを証明できる体制の重要性を建築的観点から解説します。

主なポイント

1. オンプレミスSharePoint Server向けの実用的なエクスプロイトチェーンが存在

CVE-2026-55040（JWT認証バイパス）とCVE-2026-63520（Business Connectivity Servicesの脆弱性）は、未修正サーバー上でゼロアクセスからリモートコード実行まで連鎖可能です。

2. 武器化はほぼ1日で発生

研究者Defusedは、Rapid7がCVE-2026-55040の概念実証コードを公開した翌日には、すでに実際の攻撃でそのコードが使われていたことを記録しています。公開と悪用がほぼ同時に起きる時代です。

3. パッチ適用でCVEは塞げても、アーキテクチャの問題は残る

CVE-2026-55040は2026年7月14日に修正されましたが、認証バイパスからデシリアライズや統合レイヤーRCEへの連鎖という根本的なパターンは、プラットフォームの攻撃対象領域が構造的であるため、オンプレミスSharePoint Serverで繰り返し発生しています。

4. これはオンプレミスSharePoint Serverの話であり、SharePoint Onlineではない

両者を混同することは、組織が自らのリスク評価を誤る原因となります。SharePoint Onlineはこのエクスプロイトチェーンの対象ではありません。

5. コンプライアンスの観点も技術的観点と同じくらい重要

CISOやコンプライアンス担当者にとって、真のリスクはサーバーの乗っ取りだけではありません。影響を受けたプラットフォームを通過した機密コンテンツが、暴露期間中も正当に認可され、暗号化され、ログが残っていたことを、要求に応じて証明できないことがリスクとなります。

CVE-2026-55040とCVE-2026-63520の実際の影響

CVE-2026-55040は、オンプレミスSharePoint ServerがJWT（JSON Web Token）認証を検証する方法に存在します。適切に実装されたトークン検証パイプラインであれば、外部者が有効なセッションを偽造することは計算上不可能であるべきですが、この脆弱性はその前提を崩します。権限も認証情報も事前の足がかりも持たない攻撃者が、SharePoint Serverに正規ユーザー、最悪の場合はサイト管理者からのリクエストとして扱わせることが可能です。これは既存の低権限アカウントからの権限昇格ではなく、完全な認証バイパスです。

CVE-2026-63520は、VulnCheckの技術解説によるとCVSS 8.1（高）と評価されており、プラットフォームの別の部分、Business Connectivity Services（BCS）に存在します。BCSは、SharePointがデータベースやERPシステム、カスタムアプリケーションなど外部業務データソースと接続するための統合レイヤーです。根本原因は、System.Web.UI.LosFormatterクラスを利用したデシリアライズガジェットチェーンを悪用し、サーバー上で任意コード実行を可能にする.NET型の安全でないインスタンス化です。BCSは設計上強力であり、ユーザーの代理で外部システムのデータを読み書きできるように作られています。しかし、攻撃者が認証をバイパスした後は、その設計意図が危険性に変わります。外部システムへのアクセスを仲介するコンポーネントが、攻撃者制御の入力と組み合わさることで、サーバー自体へのリモートコード実行の経路となります。

どちらの脆弱性も単体では珍しいものではありません。認証バイパスや統合レイヤーのデシリアライズ／インジェクション脆弱性は、エンタープライズ向けコラボレーションプラットフォームで繰り返し発見されています。この2つの組み合わせが重要なのは、CVE-2026-55040が認証情報不要で攻撃者を内部に入れ、CVE-2026-63520が内部に入った攻撃者にコード実行の道を与えるからです。それぞれ単体でも重大な問題ですが、連鎖すると認証不要でサーバーを完全に侵害できる経路となり、まさに概念実証として現れ、数日以内に実際の悪用キャンペーンへと発展する典型例です。

概念実証から数日で実際の悪用へ

このストーリーで最も注目すべきは、個々のCVE番号ではなくタイムラインです。Rapid7のStephen FewerがCVE-2026-55040の概念実証コードを8月11日に公開し、研究者Defusedによれば、その翌日には実際の攻撃で武器化されたことが観測されています。VulnCheckのJonathan PetersonがCVE-2026-63520の概念実証コードを8月24日に公開し、約2週間後には攻撃者にチェーンの後半部分が提供されました。

この圧縮されたタイムラインは2026年に始まったものではありませんが、年々短縮されており、オンプレミスSharePoint Serverはその実証の場となっています。Microsoftのリリースカレンダーにパッチが存在していても、実際に適用されていなければ意味がなく、Patch Tuesdayのサイクルは同日悪用ウィンドウには対応できません。概念実証公開をパッチ計画開始の合図と捉えるセキュリティチームは、実際にはその時点で既に有効期限切れの合図を受け取っていることになります。

Palo Alto NetworksのUnit42による2025年のSharePoint「ToolShell」悪用キャンペーンの評価では、同じオンプレミスプラットフォームに対する認証バイパスからRCEへのチェーンについて、「パッチ適用だけでは脅威を完全に排除できない」と明言しています。この結論は、認証バイパスで侵入した攻撃者がラテラルムーブメントを行い、場合によってはIISマシンキーなどの認証情報を窃取し、それらがパッチやWebシェル削除後もローテーションされなかったために生き残った事例に基づいています。今月のチェーンも同じ教訓を示しています。今日サーバーが完全にパッチ適用されていても、以前の侵害で触れられた認証情報が無効化されていなければ、依然として危険です。パッチは「この脆弱性がまだ悪用可能か」には答えますが、「このサーバーや接続先すべてが信頼できるか」には答えません。

これはパターンであり、単発のインシデントではない

これら2つのCVEから視野を広げると、オンプレミスSharePoint Serverの近年の歴史には明確なパターンが見えてきます。認証や統合レイヤーの脆弱性が連鎖し、認証不要のリモートコード実行を生み出し、概念実証の武器化が急速に進むという流れです。2026年7月のCVE-2026-55040修正の波では、CISAの2026年7月14日SharePoint強化アラートや、CISA Known Exploited Vulnerabilitiesカタログへの複数エントリー（いずれも対策期限は数日単位）が発生しました。Resecurityによるその攻撃チェーンの分析では、初期の認証不要アクセスからコード実行、Webシェル設置、認証情報窃取、ドメイン侵害へのラテラルムーブメントまでの進行が記録されています。

CVE-2026-63520は、その構造的なストーリーを新たな統合面に拡張します。7月に記録されたデシリアライズ脆弱性とは異なるコードパスですが、同じメカニズムで同じ結果をもたらします。すなわち、バイパス可能な認証レイヤーが、認証済みリクエストを信頼するよう設計された別コンポーネントに攻撃者制御の入力を送り込み、サーバー侵害に至るという流れです。Tenableによる関連SharePoint Server CVEのFAQでも同様の指摘があり、これは単なるコーディングミスではなく、認証・デシリアライズ・統合コンポーネントがそれぞれ独立した攻撃対象領域を持ち、いずれかの脆弱性が他と組み合わさることで完全な侵害を引き起こすプラットフォームの構造的な問題だと述べています。

CISOにとって有用な問いは「CVE-2026-55040とCVE-2026-63520にパッチを当てたか」ではなく、「このプラットフォームの他にいくつのコンポーネントが同じリスクカテゴリを抱えており、次の概念実証が現れる前にどう把握できるか」です。これはアーキテクチャの問題であり、パッチ管理の問題ではありません。

パッチ適用だけではギャップは埋まらない理由

3つの事実が同時に成り立ちますが、最初の1つだけに固執する組織ほど、数か月後も依然として危険にさらされています。第一に、Microsoftは2026年7月14日にCVE-2026-55040のパッチをリリースしており、それを適用した組織はそのバイパス自体にはもはや脆弱ではありません。第二に、1日で武器化されたことは、概念実証コードが公開される前にパッチを適用していなければ、ほぼ即座に実際の悪用にさらされることを意味し、「理論上悪用可能」から「実際に悪用されている」までの猶予期間がほぼゼロであることを示します。第三に、そして最も議論されていない点ですが、パッチを適用しても、過去の侵害ウィンドウで攻撃者がアクセス・コピー・永続化したものを遡及的に無効化することはできません。

このため、コンプライアンスや監査の観点では、セキュリティエンジニアリングとは異なる、むしろより緊急性の高い問いが生じます。セキュリティの問いは「サーバーはパッチ済みか」ですが、コンプライアンスの問いは「暴露期間中にこのサーバーが扱ったすべての機密コンテンツが、正規のIDだけにアクセスされていた証拠を提出できるか。できない場合、何が暴露されたかを証拠レベルで記録しているか」です。HIPAA、CMMC、ITARはいずれも「パッチを怠ったために侵害された」と「パッチが理論上利用可能になった翌日に侵害された」とを区別しません。規制当局や監査人、訴訟時の相手方は、プラットフォーム上にどんなデータがあり、誰がアクセスでき、監査証跡が何を示すかを問います。こうした問いに答えるためにカスタム計測が必要なオンプレミスSharePoint Server環境は、インシデント発生時点で既に不利な立場に立たされます。

コンプライアンスとセキュリティリーダーが問うべきアーキテクチャの課題

Kiteworksは今回のインシデントのデータパス上には存在していません。オンプレミスSharePoint ServerはMicrosoft純正のプラットフォームであり、Kiteworksが前段に配置されるものではなく、ここで述べているのはKiteworksがこの攻撃チェーンを防げたという主張ではありません。論点はアーキテクチャ上の違いです。

Kiteworksのセキュアデータ交換は、CVE-2026-55040で悪用されたようなJWTトークン検証パイプラインを持たず、データアクセスにBusiness Connectivity Services型の統合レイヤーも利用していません。すべてのコンテンツリクエスト（人・機械問わず）は、Kiteworks Control Planeを通じて、リクエスト単位でポリシーが適用されます。これは、トークン提示者に持続的なセッションベースの信頼を与えるのではなく、ゼロトラスト原則で都度検証する仕組みです。この違いが重要なのは、まさに今月の悪用チェーンを可能にしたのがトークン偽造やセッショントラストの脆弱性だったからです。

このアーキテクチャの下支えとなるコンプライアンスレイヤーも同様に重要です。KiteworksはFedRAMP High In-Process指定を受けており、FedRAMP Moderate認証も2017年から継続しています。これは、オンプレミスや顧客管理型ソフトウェアでは独自に実現できない、9年連続の第三者コントロール検証です。FedRAMP認証はマネージドサービスに付与され、組織が独自に導入・運用するソフトウェアには適用されません。Kiteworksはまた、CMMCレベル2要件の90%を標準でサポートし、FIPS 140-3認証暗号化を使用、SOC2 Type IIやISO 27001認証、ITAR、HIPAA BAA、GDPR、CCPAにも対応しています。これはKiteworksがすべての脆弱性カテゴリに無敵だという主張ではなく、認証不要のJWTバイパスや統合レイヤーRCEのような、汎用コラボレーションプラットフォーム特有の攻撃対象領域がKiteworksの設計には当てはまらないという説明です。

オンプレミスSharePoint Server上で機密ワークフローを運用し続けるか検討している組織にとって、実務的な問いは「SharePointを完全にやめるべきか」ではありません。むしろ、「どのワークフローが規制対象または機密性の高いコンテンツを扱っており、それらをアクセス制御やRBAC、証拠レベルのログ記録がアーキテクチャに組み込まれているプラットフォームに移行すべきか」を見極めることです。

規制対象組織が今すぐ取るべき対応

オンプレミスSharePoint Server 2016、2019、またはサブスクリプションエディションを運用している場合、CVE-2026-55040とCVE-2026-63520のパッチ適用状況を直ちに確認してください（SharePoint Onlineは対象外です）。パッチ適用確認だけで終わらず、Palo Alto Unit42の「パッチ適用だけでは脅威を完全に排除できない」という指摘通り、IISマシンキーやサーバーがアクセスできた認証情報をローテーションしてください。初回公開からパッチ適用までの暴露期間について、認証およびBusiness Connectivity Servicesのログを確認し、その間のログ欠損は単なる技術的な不便ではなく、独立した「ファインディング」として扱ってください。最後に、オンプレミスSharePoint Server上で運用されている機密または規制対象ワークフローを棚卸しし、それぞれが今後もこのプラットフォームのインシデント対応や証拠提出責任を負うべきか、あるいは最初からガバナンス・規制データ交換のために設計されたインフラに移行すべきかを評価してください。

ゼロトラストControl Planeで全データリクエストを仲介する仕組みについて詳しく知りたい方は、カスタムデモを今すぐご予約ください。

追加リソース

• ブログ記事 ゼロトラスト・アーキテクチャ：信じるな、常に検証せよ
• 動画 Microsoft GCC High：防衛請負業者をよりスマートな優位性へと導く理由
• ブログ記事 DSPMで機密データが検出された後のセキュリティ対策
• ブログ記事 ゼロトラストアプローチで生成AIの信頼性を高める方法
• 動画 ITリーダーのための機密データ安全保管ガイド