CVE-2026-6875 ServiceNow AI Platformの事前認証コード実行。スクリプトサンドボックス脱出が生む影響を読む

ServiceNow AI Platformに、認証を持たない攻撃者が特定の条件下でコードを実行できる脆弱性CVE-2026-6875が見つかりました。分類はコードインジェクション(CWE-94)で、深刻度はServiceNow評価のCVSS 4.0で9.5(Critical)とされています。制限されたスクリプト実行環境から、より強い権限のコード実行へ抜け出すサンドボックス脱出が経路になると研究者が報告しており、認証前に到達できる入力からプラットフォーム内部のスクリプトエンジンへ届きうる点が重く見られています。ServiceNowはSaaSとして多くの業務を束ねる基盤であり、そこでの未認証コード実行は影響が広がりやすいため、優先度を上げて扱う対象です。

対象読者は、ServiceNowを運用する情報システムの担当者と、SaaS基盤の実務を担う技術者です。攻撃の再現手順やペイロードは示しません。記述はNVD、ServiceNowのアドバイザリ(KB3137947)、CWE-94の定義、および実悪用を報じた記事にもとづき、事実は執筆時点(2026年7月22日)で確認できた範囲に限ります。検証は自組織が管理するインスタンスや許可された環境に対してのみ行う前提です。

CVE-2026-6875の基本情報#

CVE-2026-6875は、ServiceNow AI Platformに存在するコードインジェクションの脆弱性です。原因の分類はCWE-94(Improper Control of Generation of Code)で、外部から渡された入力が、生成されて実行されるコードの一部として扱われてしまうことに起因します。深刻度は、CNAであるServiceNowの評価でCVSS 4.0が9.5(Critical)とされ、ベクトルはCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:Hです。

ベクトルを読み解くと、攻撃はネットワーク経由(AV:N)で行え、事前の権限(PR:N)も利用者の操作(UI:N)も要りません。一方で攻撃条件の複雑さは高(AC:H)とされ、成立にはいくつかの前提がそろう必要があることを示しています。注目したいのは後半で、脆弱なシステム自身の機密性と完全性と可用性(VC:H/VI:H/VA:H)に加え、後続システムへの影響(SC:H/SI:H/SA:H)もすべて高く評価されている点です。これは、この脆弱性が悪用された場合に、当該プラットフォームの内側だけでなく、そこから連なる別のシステムにまで影響が及びうると見積もられていることを意味します。SaaS基盤のように多くの業務が集約される環境では、この後続影響の重みが実運用のリスクを押し上げます。

NVDはCVE-2026-6875を、特定の状況下で認証されていない利用者がServiceNowプラットフォーム内でコードを実行しうるリモートコード実行の脆弱性として記載し、ServiceNowが対処したことを示しています。

サンドボックス脱出が未認証コード実行に至る機構#

CWE-94が示すのは、プログラムが実行するコードの生成を適切に制御できず、外部の入力がそのコードの構造そのものを左右してしまう状態です。攻撃者が渡した文字列が、単なるデータとしてではなく実行される命令として解釈されると、本来意図しない処理が動きます。ServiceNowは業務ロジックをスクリプトとして扱う仕組みを持つため、入力がスクリプトエンジンへ届く経路が問題になります。

ここから先は、公開された技術情報や研究者の報告にもとづく概略で、ServiceNowの公式アドバイザリが実装の詳細まで確認したものではありません。研究者の報告によれば、この脆弱性の経路は、制限されたスクリプト実行環境、すなわちサンドボックスから、より強い権限のコード実行へ抜け出すサンドボックス脱出だとされています。公開研究では、認証前に到達できる入力箇所(sink)が指摘され、そこからプラットフォーム内部のスクリプトエンジンへ届きうると説明されています。研究者はGlideRecordやRhino engineといった固有の要素にも触れていますが、これらは研究者が指摘する範囲の情報であり、内部実装の詳細は公式アドバイザリに記載がありません。したがって機構は概略にとどめ、断定はしないのが妥当です。

公式が確認しているのは、特定の状況下で未認証の利用者がServiceNowプラットフォーム内でコードを実行できる、という点までです。研究者が説明する脱出の詳しい仕組みと、公式が明言している事実とは切り分けて受け止める必要があります。運用側にとって確実なのは、認証前に到達しうる入力からコード実行に至る経路が存在し、それが修正されたという事実です。

MITREのCWE-94は、外部からの入力によって生成されるコードの制御が不適切な場合に、意図しないコードが実行されうる弱点として定義しています。

SaaS基盤で未認証コード実行が持つ重み#

ServiceNowは、ITサービス管理や業務ワークフローを一元的に扱うSaaS基盤として、多くの部門の業務データと処理を集約します。こうした基盤で未認証のコード実行が成立すると、影響は単一のアプリケーションにとどまりません。プラットフォーム内で動くコードは、そこに集まった業務データや連携先のシステムへ手を伸ばせる位置にあるため、CVSSベクトルが後続システムへの影響(SC:H/SI:H/SA:H)を高く見積もっているのは、この集約の性質を反映しています。

さらに、認証を必要としない点が露出面の広さに直結します。認証後のみ悪用できる脆弱性であれば、正規の資格情報という関門が攻撃の前提になりますが、事前認証で到達できる場合はその関門がありません。SaaSの多くはネットワーク経由でのアクセスを前提に公開されているため、到達性の高さと未認証という条件が重なると、悪用の敷居が下がります。同じく認証を経ずに到達される経路が実悪用につながった事例として、SharePoint Serverの認証欠落による権限昇格の分析が参考になります。

あわせて読みたい

CVE-2026-56164 SharePoint Serverの認証欠落による権限昇格。CVSSは低いのに実悪用される理由を機構から読む

影響を受けるバージョンと修正#

ServiceNowはリリーストレインごとに修正を提供しています。ホスティング型(SaaS)インスタンスには速やかに修正が適用され、自己ホスト型(self-hosted)の顧客とパートナー向けには2026年6月にかけて修正が提供されました。自己ホスト型で運用している組織は、該当するパッチの適用が必要です。修正が入ったバージョンは次のとおりです。

ホスティング型はServiceNow側で既に修正が適用されているため、利用組織による個別のパッチ適用は不要です。一方で自己ホスト型は、運用中のトレインに応じて上記のいずれかへ更新する必要があります。まず自組織のインスタンスがホスティング型か自己ホスト型かを確認し、自己ホスト型であれば現行バージョンと該当パッチの差分を把握することが対応の起点になります。

ServiceNowのアドバイザリ(KB3137947)は、ServiceNow AIプラットフォームで見つかったリモートコード実行に対処したこと、特定の状況下で未認証の利用者がコードを実行しうることを示し、修正が入ったリリーストレインとバージョンを案内しています。

発見から公開、実悪用までの時系列#

時系列を整理すると、脆弱性の扱いが段階的に進んだことがわかります。Searchlight Cyberの研究者が2026年4月初旬にServiceNowへ報告し、ServiceNowはまずホスティング型インスタンスへ修正を適用しました。自己ホスト型の顧客とパートナー向けの修正は2026年6月にかけて提供され、脆弱性の存在は2026年7月13日に公開されました。

公開後の展開は速く進みました。公開に前後してPoC(概念実証)が出回り、複数の報道と脅威情報企業が2026年7月17日ごろから実際の悪用(in-the-wild)を確認したと報じています。加えて、公開されたPoCに合わせた防御を回避するための、別のサンドボックス脱出の手口も観測されたと報じられています。NVD公開時点の注記には「公開時点で既知の悪用なし」とありますが、これは公開直後の記載であり、その後に実悪用が報告された点を時系列として押さえておく必要があります。研究者からの非公開報告を経て修正が提供され、公開後に悪用が広がるという流れは、ゼロデイと修正のタイミングを理解する上での典型例です。ゼロデイという言葉の意味と、公開から悪用までの時間差の考え方は次の記事で整理しています。

あわせて読みたい

ゼロデイ脆弱性とは。検知が難しい攻撃にどう備えるか

Help Net Securityは、CVE-2026-6875が公開後に実際の攻撃で悪用されたこと、公開されたPoCに合わせた防御を回避する別のサンドボックス脱出も観測されたと報じています。

優先順位づけの考え方#

多数の脆弱性を前に対応の順番を決めるとき、実際の悪用が確認されているかどうかは強い判断材料になります。CVE-2026-6875は、公開後に実悪用が報じられ、PoCも出回っている状況です。こうした条件がそろう脆弱性は、CVSSの数値だけでなく、悪用の観測という事実を軸に優先度を引き上げるのが現実的です。

なお、CISAのKEV(Known Exploited Vulnerabilities)への収録有無は、執筆時点では確認できていません。KEVに収録されているかどうかを断定はできないため、収録の有無を判断材料に加える場合は、CISAのカタログを直接確認する必要があります。KEVやEPSSといった指標を使って優先順位を組み立てる考え方は次の記事で整理しています。実悪用の有無を中心に据えた選別が、対応を回す助けになります。

あわせて読みたい

脆弱性対応の優先順位付け。CVSSだけに頼らないEPSSとCISA KEVの使い方

自組織のServiceNowを確認する手順#

運用中のServiceNowが影響対象かどうかと、必要な対応を順に確認します。以下は影響判定から適用までの流れです。

自己ホスト型の更新では、事前に検証環境で影響を確認してから本番へ適用するのが安全です。ホスティング型であっても、自インスタンスの状態と公開範囲の確認は運用側の責任として残ります。露出面の見直しでは、業務に必要な発信元へアクセスを絞り、想定外の経路からプラットフォームへ到達できる構成になっていないかを点検します。

確認チェックリスト#

対応の抜けを防ぐための確認項目を整理します。

CVE-2026-6875は、ServiceNow AI Platformのコードインジェクションで、CVSS 4.0で9.5(Critical)という高い評価がつけられています。公式が確認しているのは、特定の状況下で未認証の利用者がプラットフォーム内でコードを実行しうる点までで、サンドボックス脱出という機構の詳細は研究者の公開情報にもとづく概略です。ホスティング型は修正適用済み、自己ホスト型は該当パッチの適用が必要という切り分けを押さえ、実悪用が報じられている事実を軸に優先度を決めることが、この脆弱性への現実的な向き合い方になります。