Microsoft Exchange ServerのSSRF 脆弱性のPoC 公開-CVE-2026-45504|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年07月06日更新日時: 2026年07月06日

セキュリティ研究チームHawkTraceは、Microsoft Exchange Serverに存在するサーバーサイドリクエストフォージェリ(SSRF)の脆弱性CVE-2026-45504について、詳細な技術解析と概念実証コード(PoC)を公開しました。この脆弱性は2026年6月9日の月例セキュリティ更新プログラムで修正済みですが、公開された解析記事では、Exchangeが持つドキュメントプレビュー機能の実装不備を突くことで、通常は閲覧できないはずのサーバー内部のファイルを、権限の低い一般ユーザーが読み取れてしまう手口が明らかにされています。攻撃の核心にあるのはURLの断片識別子(フラグメント)を表すシャープ記号ひとつという、驚くほどシンプルな手法です。PoCが公開された以上、パッチを未適用のExchange Server 2016・2019環境は速やかな対応が必要です。

サマリー

CVE-2026-45504はMicrosoft Exchange Serverの権限昇格脆弱性。CVSSスコアは8.8(重要度High)で、CWE-918(サーバーサイドリクエストフォージェリ)に分類される
対象はオンプレミス版のExchange Server 2016・2019(Subscription Editionを含む)。Microsoftは2026年6月9日の月例パッチで修正版を提供済み
脆弱性の原因は、ExchangeがSharePointおよびWOPI(Web Application Open Platform Interface)と連携してドキュメントプレビューURLを生成する際、応答に含まれるURLのスキーム(httpやfileなど)を検証していなかったこと
攻撃者は自分が用意した不正なWOPIエンドポイントを指すEWS(Exchange Web Services)の添付ファイル参照を作成し、被害者がそのプレビューを開くタイミングでExchangeサーバーに不正なリクエストを発行させる
Exchangeが構築するリクエストURLにシャープ記号(#)を混入させることで、本来付与されるはずのアクセストークン等のパラメータをURIパーサーに無視させ、任意のローカルファイルパスをそのまま読み取らせることができる
低権限のメールボックスを持つ認証済みユーザーであれば悪用可能で、管理者権限は不要。PoCが一般公開されているため、未パッチ環境は速やかな対応が求められる

項目	内容
CVE番号	CVE-2026-45504
深刻度	CVSSスコア8.8(High)・Elevation of Privilege
脆弱性の分類	CWE-918(サーバーサイドリクエストフォージェリ)
影響を受ける製品	Exchange Server 2016(CU23)・Exchange Server 2019(CU14/CU15)・Exchange Server Subscription Edition
パッチ公開日	2026年6月9日(月例セキュリティ更新)
攻撃条件	低権限の認証済みユーザー(メールボックスを保有)。管理者権限は不要
悪用の起点	EWSのReferenceAttachment、不正なWOPIエンドポイント
悪用の鍵となる技術	URLスキーム未検証、フラグメント識別子(#)によるパラメータ無効化
想定される影響	サーバー内の任意ローカルファイルの読み取り、他ユーザーへのなりすまし
PoCの公開	公開済み(HawkTrace)

1 何が起きたか
2 原因-URLスキームを検証していなかった実装の穴
3 シャープ記号ひとつがもたらす任意ファイル読み取り
4 情報システム部門が確認すべき対応
5 出典

何が起きたか

HawkTraceの研究チームは、以前に発見していたMicrosoft Exchange Serverのサーバーサイドリクエストフォージェリの脆弱性について、詳しい技術解析記事を公開しました。この脆弱性は認証済みの一般ユーザーが、サーバー上のファイルシステムから権限外のファイルを読み取れてしまうというもので、攻撃の対象はExchange Server 2019を含むオンプレミス環境です。

Microsoftはすでに2026年6月9日の月例セキュリティ更新でこの問題に対応していますが、HawkTraceが技術詳細とPoCを公開したことで、パッチを適用していない環境がより現実的な攻撃対象になったといえます。

概要としては、Exchangeが持つドキュメントプレビュー機能(Officeファイルをブラウザ上でプレビュー表示するWAC連携機能)の実装に不備があり、攻撃者が用意した外部サーバーをExchangeに正規のプレビュー提供元だと信じ込ませることで、サーバー自身に不正なリクエストを発行させることができるというものです。この一連の流れの最終段階で、サーバー上の任意のローカルファイルをレスポンスとして読み出せてしまいます。

原因-URLスキームを検証していなかった実装の穴

この脆弱性の根本原因は、ExchangeがSharePointおよびWOPI(Web Application Open Platform Interface、Officeファイルをブラウザ上で編集・プレビューするための標準インターフェース)と連携してWACのドキュメントプレビューURLを生成する処理の内部にあります。

Exchangeの内部では、GetTokenRequestWebResponseやGetWacUrlといったヘルパー関数が使われており、これらはOneDriveProUtilities.TryTwiceという共通処理を通じて、攻撃者が影響を及ぼせるURLに対してHTTPリクエストを発行し、その応答であるOData形式のXMLからWebApplicationUrl・AccessToken・AccessTokenTtlという3つの値を取り出します。ここで問題になるのが、WOPIプロバイダーから返されたWebApplicationUrlフィールドの値について、そのURLスキーム(httpやhttpsといった接頭辞)がまったく検証されていなかった点です。攻撃者が用意したWOPIエンドポイントは、http以外の任意のスキーム(たとえばfile)を含むURLを平然と返すことができ、Exchangeはそれをそのまま最終的なWAC URLの構築に利用してしまいます。

HawkTraceが公開した攻撃手順を整理すると、まず攻撃者はEWS(Exchange Web Services)のReferenceAttachment(参照添付ファイル)を作成し、ProviderEndpointUrlというパラメータに自分が管理するサーバーのURLを設定します。被害者がこの添付ファイルのプレビューを開こうとすると、Exchangeは/_api/SP.Utilities.WOPIHostUtility.GetWopiTargetPropertiesByUrlというエンドポイントに対し、攻撃者のサーバーURLをパラメータとして含んだリクエストを送信します。攻撃者のサーバーはこのリクエストに応答し、WebApplicationUrlの値としてfile:///C:/windows/win.iniのようなローカルファイルパスを返します。

シャープ記号ひとつがもたらす任意ファイル読み取り

ここからがこの脆弱性の核心部分です。単純にfile:///c:/windows/win.iniというパスを返すだけでは、Exchangeはこの後にAccessToken等のクエリパラメータを付け加えようとするため、file:///c:/windows/win.ini?...&access_token=...のような形になり、ファイルパスとして正しく解釈されません。

そこでHawkTraceが用いた手法が、URLの末尾にシャープ記号(#)を付け加えるというものです。SQLインジェクションの世界でコメントアウト記号を使ってクエリの残りを無効化する手口と同じ発想で、URIの仕様上、シャープ記号以降の文字列は断片識別子(フラグメント)として扱われ、サーバーへの実際のリクエストには送信されません。攻撃者がfile:///C:/windows/win.ini#という値を返すと、Exchangeはその後ろにアクセストークンなどのパラメータを付け加えますが、URIパーサーはシャープ記号以降をすべてフラグメントとして無視するため、結果的にfile:///C:/windows/win.iniという正確なファイルパスだけが有効な形で処理されてしまいます。この結果、攻撃者が望むとおりのローカルファイルの中身が、レスポンスとしてそのまま返されることになります。

この手口が成立するために攻撃者に必要な権限は、Exchange上にメールボックスを持つ低権限の認証済みユーザーであることだけです。管理者権限やその他の昇格した権限は一切不要です。Microsoftのアドバイザリでも、低権限ユーザーがExchangeのリクエスト検証やIDトークンの取り扱いにおける弱点を悪用することで、他のユーザーになりすましてメールボックスへアクセスできる可能性があると説明されています。今回HawkTraceが示した任意ファイル読み取りの手口は、この権限昇格の土台となる技術的な実証といえます。

情報システム部門が確認すべき対応

まず最優先で確認すべきは、2026年6月9日の月例セキュリティ更新プログラムがすべてのオンプレミスExchangeサーバーに適用されているかどうかです。対象となるのはExchange Server 2016(CU23)・Exchange Server 2019(CU14およびCU15)・Exchange Server Subscription Editionです。Microsoftのサポート技術情報では、それぞれの累積更新に対応するKB番号が案内されており、適用後はExchange Server Health Checkerを実行して更新が正しく反映されているかを確認することが推奨されています。

パッチ適用が難しい環境が一時的に存在する場合は、WOPI連携・ドキュメントプレビュー機能に関連する通信を監視することが有効な暫定策になります。HawkTraceは検知の観点として、通常とは異なるWOPI・WACのトークンリクエストと、外部の未知のインフラへの送信通信、そしてExchangeホスト上での想定外のローカルファイルアクセスとの相関を確認することで、この脆弱性の悪用を検知できる可能性を示しています。SIEMやEDRのログにおいて、Exchangeサーバープロセスから普段見られないアウトバウンド接続が発生していないか、/_api/SP.Utilities.WOPIHostUtility.GetWopiTargetPropertiesByUrlのようなエンドポイントへの不審なリクエストがないかを確認することをおすすめします。

サーバサイドエンジニアとしてWebアプリケーションの開発に携わってきた経験からいうと、外部から取得したURLやレスポンス内の値を後続処理でそのまま利用してしまう実装は、SSRFに限らずさまざまな脆弱性の温床になりやすいパターンです。特に今回のように複数のコンポーネント(Exchange・SharePoint・WOPI)が連携する構成では、それぞれの境界でどこまで入力値を信頼してよいかの前提が曖昧になりがちです。自組織でカスタム開発を行っている場合も、外部サービスからの応答値を鵜呑みにせず、URLスキームやフォーマットを明示的に検証する実装になっているかを、この機会に改めて点検する価値があります。

以前にも当サイトで報じたExchange ServerのゼロデイCVE-2026-42897やOutlookとExchange環境でのゼロクリック攻撃リスクを伴うCVE-2026-40361など、オンプレミス版Exchangeを取り巻く脆弱性は継続的に発見されています。メールという業務の根幹を担うシステムだけに、パッチ管理のサイクルを他のシステムよりも優先度高く運用することが引き続き求められます。