ServiceNowのAI Platformに存在する脆弱性、複数のサンドボックス回避ルートで悪用が進行中
2026年7月21日 22:58
業務プロセスの自動化プラットフォームServiceNowの「AI Platform」に存在する重大な脆弱性（CVE-2026-6875）について、公開された概念実証（PoC）とは異なる手法を用いた攻撃が進行していることが確認された。クラウド版は自動更新されているが、セルフホスト版を利用する組織は直ちに修正パッチを適用する必要がある。既知の攻撃手法をネットワーク層でブロックするだけでは防御として不十分であり、根本的な脆弱性の修正が急務となっている。
■複数の回避ルートによる悪用が進行中
脅威インテリジェンス企業Defusedは週末にかけて、ServiceNowのAI Platformに存在する重大な脆弱性を攻撃者が積極的に悪用していることを確認した。さらに、公開されている概念実証（PoC）が示すよりも、悪用の状況はすでに広範に及んでいる。実際に観測されたペイロードは、Searchlight Cyberが文書化したものとは異なるサンドボックス回避ルートを通じて、同じコード実行のプリミティブに到達している。つまり、根本的な欠陥にパッチを当てるのではなく、既知の手法をブロックしようとした組織は保護されていないことを意味する。最初の悪意あるペイロードは、ServiceNowが7月13日にパッチをリリースしてから5日後の7月18日（金）に出現し、現在も悪用が続いている。
ServiceNowのAI Platform（旧称：Now Platform）は、年間1,000億件以上のエンタープライズワークフローを処理し、Fortune 500企業の85%で10万以上のエンタープライズAIアプリケーションを稼働させている。脆弱なインスタンスへのネットワークアクセスを持つ非認証の攻撃者は、認証情報やフィッシング、組織内での事前の足場を一切必要とせずに、この欠陥をトリガーできる。この広範な導入状況とゼロ認証での悪用可能性の組み合わせにより、CVE-2026-6875は予定されたパッチ適用項目ではなく、即時の緊急事態となっている。
土曜日にX（旧Twitter）に投稿されたDefusedの脅威インテリジェンスは、攻撃者がSearchlight Cyberが文書化したのと同じ認証前のエントリポイント（/assessment_thanks.do）を攻撃しているが、同じコード実行プリミティブに到達するために異なるガジェットチェーンを使用していることを確認した。この違いが現在のリスク状況の核心である。つまり、構造的な脆弱性は単一の悪用経路にとどまらないということだ。
■サンドボックス回避の脆弱性の仕組み
ServiceNowのAI Platformは、2層のサンドボックスアーキテクチャでJavaScriptを実行する。外側の層（主要な実行環境）は、スクリプトにプラットフォーム管理者と同等の機能を提供するが、基盤となるオペレーティングシステムからは隔離している。スクリプトサンドボックスまたはフィルターサンドボックスと呼ばれる内側の層は、認証前の入力を含むユーザー提供の入力に追加の制限を適用する。Searchlight Cyberの技術解説で詳述されているように、eval、new Function、関数宣言、およびほとんどのJavaクラスへのアクセスをブロックする。
CVE-2026-6875として追跡され、CVSSスコア9.5と評価されたこの欠陥は、ServiceNowのアドバイザリKB3137947によると、これら2つの層の間の隙間に存在する。ServiceNowのGlideRecordクエリAPIは、addQuery()呼び出しでjavascript:プレフィックスを受け入れ、プラットフォームが結果をクエリ引数として使用する前にJavaScript式を評価するようにする。認証前のエンドポイントassessment_thanks.doは、ユーザーが提供した入力をこれらの呼び出しの1つに直接受け入れ、非認証の攻撃者に内側のサンドボックスへの経路を提供する。
追加のサンドボックスは直接のコード実行をブロックするが、ServiceNowの組み込みスクリプトライブラリを読み込む関数であるgs.include()はブロックしない。この関数は、読み込んだコードを外側の制限の緩い実行コンテキストで実行する。2つのコンテキスト間で共有されるグローバルスコープが構造的な隙間となっている。内側のサンドボックス内で実行されている攻撃者のコードは、Object.cloneのようなグローバルJavaScriptオブジェクトを変更でき、読み込まれたライブラリコードはそれをサンドボックス外で実行してしまう。Searchlight Cyberの傘下で活動するAssetnoteのAdam Kues氏は、特定のガジェットチェーンを文書化した。Object.cloneをFunctionコンストラクタで上書きし、AbstractAjaxProcessor.prototypeを攻撃者のペイロードに設定し、gs.include('ItemViewElementsProvider')を呼び出してサンドボックス外で実行をトリガーするというものだ。その結果、プラットフォームへの完全なアクセスを伴う任意のコード実行が可能になる。Kues氏は、このエクスプロイトによって任意のテーブルデータの読み取り、管理者ユーザーの作成、接続されたプロキシサーバーでのシェルコマンドの実行が可能になることを確認した。
■既知の悪用ルートのブロックだけでは不十分な理由
Defusedのテレメトリは、7月13日のパッチ適用以来、最も重大な新たな進展である。同社が観測した攻撃者は、Searchlight Cyberが文書化したのと同じ認証前のエントリポイント（/assessment_thanks.do）を攻撃していたが、コード実行プリミティブに到達するために使用したサンドボックス回避のガジェットチェーンは、Searchlight Cyberが公開した解説のものとは異なっていた。
これは戦術的だけでなく、構造的にも重要である。根本的な悪用可能なプリミティブ（gs.include()ブリッジを介してサンドボックス外のコード実行に影響を与える能力）は、インクルードされたライブラリの実行コンテキスト内でFunctionコンストラクタを呼び出すことができる任意のガジェットを通じて到達可能である。Searchlight Cyberが公開したチェーンはそのようなガジェットの1つだった。Defusedは今回、2つ目のガジェットを確認した。複数の独立したガジェットパスが存在するということは、PoCで文書化された特定の操作シーケンスを標的とする防御（特定のプロパティの上書きに調整されたWAFルールや、既知のペイロード構造に一致するネットワークパターン）は、代替ルートを使用する攻撃者に対しては失敗することを意味する。すべてのルートを同時に塞ぐ唯一の防御策は、根本的な脆弱性にパッチを当てることである。なぜなら、パッチ（およびGuarded Scriptのアーキテクチャ変更）により、あらゆるガジェットチェーンを成立させる前提条件が排除されるからだ。
ネットワーク層のシグネチャがパッチの代わりになると想定してパッチ適用を遅らせている組織は、直ちにその方針を再考すべきである。
■ServiceNowの対応とアドバイザリの遅れ
最初の開示に対するServiceNowの対応は著しく迅速だった。Kues氏が2026年4月1日に脆弱性を報告した際、同社は24時間以内にクラウド側での緩和策を展開し、重要なJavaScript関数の変更を防いだ。Searchlight Cyberが文書化しているように、これは攻撃者を導くような公開情報が存在する前に行われた。根本的なサンドボックスの弱点に対処するより広範なパッチはその後数週間にわたって提供され、アドバイザリによると、セルフホスト顧客向けのパッチとともに、公式アドバイザリKB3137947が7月13日に公開された。
BleepingComputerが報じたように、2026年7月20日午前の時点でServiceNowが行っていないのは、Defusedが確認した悪用を反映させるためのアドバイザリの更新である。アドバイザリには依然として、同社は「現在、ServiceNowインスタンスに対する悪用を認識していない」と記載されている。BleepingComputerの記者Sergiu Gatlan氏が週末に問い合わせたところ、ServiceNowの広報担当者はDefusedの調査結果について即座にコメントできなかった。
このアドバイザリの遅れは、以前から記録されているパターンである。TechTimesの2026年6月の報道によると、2026年6月に攻撃者が非認証のAPIの欠陥を通じて顧客データを照会した際、ServiceNowは6月5日に修復を適用したが、6月9日までアドバイザリを公開しなかった。さらに、その掲示板にアクセスするにはカスタマーサポートポータルへのログインが必要だった。パッチ適用の緊急性を判断するためにServiceNow自身のコミュニケーションに依存しているセキュリティチームは、システム的な遅れを抱えた状態で作業していることになる。
■継続して狙われるプラットフォーム
CVE-2026-6875はServiceNowにとって初の重大な非認証の脆弱性ではなく、開示後に悪用されるパターンも新しいものではない。BleepingComputerによるResecurityの調査結果の報道によると、2024年7月には、同じくAssetnoteによって発見された入力検証の欠陥であるCVE-2024-4879が、技術解説が公開されてから数日以内に、政府機関、エネルギー企業、ソフトウェア開発会社を含む105以上の組織に対して悪用された。盗まれたデータはサイバー犯罪フォーラムに出回った。CISAは、この2024年の脆弱性を「既知の悪用された脆弱性（KEV）」カタログに追加し、連邦政府機関に義務的な修復期限を設けた。
2026年1月と2月にパッチが適用された重大なサンドボックスバイパスであるCVE-2026-0542と、AppOmniの研究者Aaron Costello氏によって「BodySnatcher」と名付けられCVSS 9.3と評価されたCVE-2025-12420は、いずれも悪用が確認される前に修正された。CVE-2026-6875はそのパターンを打ち破った。攻撃者はパッチの普及サイクルよりも速く動いたのだ。2024年の悪用の手口（技術解説を公開し、攻撃者が数日以内にそれを一括スキャンツールに適応させるのを見る）が、加速して再び実行されているようだ。
■構造的な修正「Guarded Script」
ServiceNowは、CVE-2026-6875のパッチとともに新しい「Guarded Script」保護モデルを導入した。KB2944435に詳細が記載されているように、これは単なるポイント修正ではなく、意味のあるアーキテクチャの変更を表している。Guarded Scriptの下では、内側のサンドボックスは単一の単純な式のみを受け入れる。変数宣言、制御フロー（if、switch、for、while）、関数宣言、代入演算子、および複数ステートメントのスクリプトはすべてブロックされる。このクラスの脆弱性に対する既知のすべてのガジェットチェーンは、複数ステップのコード操作（グローバル関数の上書き、プロパティの設定、インクルードの呼び出し）を必要とするため、Guarded Scriptの制限は、文書化されたものだけでなく、あらゆるガジェットチェーンの前提条件を排除する。
セキュリティチームにとっての実用的な意味合いは肯定的である。Guarded Scriptは、このアーキテクチャにおける将来の認証前サンドボックス回避の試みに対するハードルを大幅に引き上げるはずだ。開発者にとっての実用的な意味合いは、移行の必要性である。ServiceNowのGuarded Scriptドキュメントによると、サンドボックスコンテキスト内で複雑なJavaScriptを使用する既存のカスタムスクリプトは、Script Includesとして再構築する必要があるかもしれない。
■影響を受けるバージョンとセルフホスト版の対応
ホスト型（クラウド）のServiceNowインスタンスは自動更新を受け取った。パッチが適用されていない主要な層であるセルフホスト型の顧客は、自社のインスタンスが以下の修正済みリリースのいずれかを実行していることを確認する必要がある。
ServiceNowのアドバイザリKB3137947で確認されているように、Brazil EAおよびBrazil GA、Australia Patch 2、Zurich Patch 7bおよびZurich Patch 9、Yokohama Patch 12 Hot Fix 1bおよびYokohama Patch 13である。各ファミリの修正済みリリースより前のバージョンはすべて脆弱なままである。Cryptikaやその他のアドバイザリアグリゲーターは、アドバイザリと照らし合わせてこれらのバージョン文字列を確認している。
パッチ適用に加えて、セキュリティチームはいくつかの並行した手順を踏むべきである。/assessment_thanks.doエンドポイントで、特に外部のIP範囲や異常な時間帯からの異常なトラフィックを監視する。Defusedのテレメトリは、これがアクティブな攻撃のエントリポイントであることを確認している。予期しないワークフロー自動化の変更、新しいユーザーやロールの変更、異常なAPI呼び出し、Web向けサービスからの予期しないスクリプト実行など、エクスプロイト後の活動の痕跡がないかログを確認する。すぐにパッチを適用できない場合、ServiceNowインスタンスに到達できるIP範囲を制限するネットワーク層の制御により露出を減らすことができるが、完全に排除するものではなく、パッチ適用の代わりにはならない。また、新しい単一式の制限が既存のカスタムスクリプトに影響を与える可能性があるため、アップグレード後に互換性のないGuarded Scriptのリストを監査する必要がある。
■注目ポイントQ&A
●組織がセルフホスト型ではなくホスト型（クラウド）インスタンスを使用している場合、ServiceNowインスタンスは危険にさらされていますか？
ホスト型インスタンスはServiceNowから自動パッチを受け取っていますが、チームは更新が適用され、カスタマイズによってロールバックされていないことを確認する必要があります。Defusedによって確認されたアクティブな悪用は、展開タイプに関係なく同じ認証前のエントリポイントを標的にしています。パッチが正しく適用されたことを確認することは、オプションではなく最小限の確認手順です。
●公開されたエクスプロイト手法をブロックするだけでは、CVE-2026-6875から保護されないのはなぜですか？
Searchlight Cyberの解説では、ServiceNowの内側と外側のJavaScript実行コンテキスト間の構造的な隙間を横断する1つのガジェットチェーンについて説明しています。Defusedは、同じコード実行プリミティブに到達する2つ目の異なるチェーンを確認しました。制限されたサンドボックス内からサンドボックス外の実行に影響を与えることを可能にするgs.include()ブリッジという悪用可能な隙間は、複数の独立したコードパスを介して到達可能であるため、特定の既知のチェーンを標的とする防御は、代替ルートを使用する攻撃者によって回避されます。パッチ適用は構造的な隙間自体を塞ぎますが、既知のガジェットシーケンスのシグネチャマッチングでは塞ぐことはできません。
●影響を受けるServiceNowのバージョンはどれですか？また、正確なパッチ文字列はどこで確認できますか？
修正されたリリースは、Brazil EAおよびBrazil GA、Australia Patch 2、Zurich Patch 7bおよびZurich Patch 9、Yokohama Patch 12 Hot Fix 1bおよびYokohama Patch 13です。正確なバージョン文字列は、ServiceNowのアドバイザリKB3137947で直接確認してください。リリースファミリ間でパッチの命名規則が異なる場合があり、ソースと照合することで不一致を防ぐことができます。
●悪用が確認されたかどうかを知るために、ServiceNowのアドバイザリを信頼すべきですか？
Defusedが前日にアクティブな攻撃を確認したにもかかわらず、現在のアドバイザリには2026年7月20日時点でServiceNowは「現在、悪用を認識していない」と記載されています。ServiceNowの2026年6月のデータ侵害アドバイザリは、修復の4日後に公開され、アクセスにはカスタマーポータルへのログインが必要でした。セキュリティチームは、ServiceNowが公式掲示板を更新するのを待つのではなく、/assessment_thanks.doエンドポイントのベンダー中立な監視を含む、独立した脅威インテリジェンスソースを主要なシグナルとして扱うべきです。
元記事: Attackers Exploit ServiceNow CVE-2026-6875 via Multiple Sandbox-Escape Routes