ServiceNowにCVSS 10.0が3件、自己管理版は手動更新が必要

ServiceNowは2026年8月27日、ServiceNow AI Platformに影響するCVSS 4.0スコア10.0の脆弱性3件を公表した。同日公開の 8月分の公式アドバイザリ は、これらを含む計4件の修正情報を扱っている。

ServiceNowが管理するホスト版には修正が展開済みだが、自己管理版とパートナー管理環境には更新が提供された段階であり、各組織による適用が必要だ。8月31日付の SecurityWeekの報道 は、3件が認証や利用者操作なしに低い複雑度で悪用され得ること、攻撃結果が任意コード実行、権限昇格、任意SQL実行に分かれることを伝えている。

3件は異なる処理経路からインスタンスデータに到達する

CVE-2026-18885は、GraphQL Composite Data APIに存在するコードインジェクションの脆弱性である。一定の条件下で、未認証の攻撃者がServiceNowプラットフォーム上で任意コードを実行し、想定されていないインスタンスデータへアクセスしたり、内容を変更したりする可能性がある。

CVE-2026-18886は、システム構成用の画像アップロード処理における不適切なアクセス制御だ。未認証の攻撃者によるインスタンスデータの作成または変更を許し、権限昇格につながる恐れがある。問題の中心は画像の形式ではなく、アップロード処理へのアクセスを適切に制限できない点にある。

CVE-2026-74820は、動的スキーマのORDER BY句を経由するSQLインジェクションである。攻撃者が認証なしで、インスタンスの基盤データベースに対して任意のSQL文を実行できる可能性がある。前の2件がアプリケーションコードとアクセス制御を経路にするのに対し、この脆弱性はデータベースへの問い合わせを直接操作する。

CVSS 10.0でも、侵害が確認されたという意味ではない

3件には同じCVSS 4.0ベクトルが割り当てられている。ネットワークから到達でき、攻撃の複雑度が低く、追加条件、事前権限、利用者操作を必要としないという評価だ。機密性、完全性、可用性への影響はいずれも高く、認証画面の内側だけを保護する対策では攻撃経路を遮断できない可能性がある。

一方、CVSSは想定される技術的影響を示す尺度であり、実際の被害件数ではない。公表時点でServiceNowは4件の悪用を認識しておらず、最大深刻度の3件について公開された実証コードも確認されていなかった。深刻度が最大であることと、攻撃が観測済みであることは区別する必要がある。

同時に公表された4件目のCVE-2026-6876は、Now Platformのサンドボックス回避で、CVSS 4.0スコアは8.7だ。公開説明は未認証利用者によるコード実行の可能性を示す一方、割り当てられたベクトルは低い事前権限を要求しており、説明と評価条件が一致していない。このため、CVSS 10.0の3件とは分けて影響を判定すべきである。

修正境界はリリース系列とブランチで変わる

影響対象はXanadu、Yokohama、Zurich、Australiaの複数系列にまたがる。The Hacker Newsが確認した修正境界 では、XanaduはPatch 11 Hot Fix 7aより前、YokohamaはPatch 12 Hot Fix 3bまたはPatch 13 Hot Fix 4より前が対象となる。ZurichとAustraliaには複数のPatch、Hot Fix、標準ブランチ、mブランチがあり、単一の版番号だけでは修正済みか判断できない。

同じ系列でも、現在のブランチと対象CVEによって判定が変わる。特にCVE-2026-18886のAustralia Patch 5より前の扱いには、公開されたCVE記録とアドバイザリの整理に差があるため、一般化された一覧ではなく、対象インスタンスの正確なビルド番号とServiceNowの最新記録を照合する必要がある。

ホスト版は展開済み、自己管理版は適用作業が残る

ServiceNow管理下のホスト版では、同社が4件に対するセキュリティ更新を展開した。利用企業に残るのは、対象インスタンスが修正版へ移行していることを確認し、その結果を自社の変更管理や監査記録に反映する作業である。

自己管理版とパートナー管理環境では、更新ファイルが提供されても自動的に適用済みにはならない。管理者は運用主体、リリース系列、Patch、Hot Fix、標準またはmブランチを特定し、該当する修正版へ更新する必要がある。

1. 管理対象の各インスタンスについて、ホスト形態と現在のビルド番号を確認する。
2. CVEごとの影響範囲と修正境界を照合し、適用するHot Fixまたは修正版を決める。
3. 組織の変更管理手順に従って更新し、適用後のビルド番号を記録する。
4. GraphQL Composite Data API、画像アップロード処理、データベースを使用する主要ワークフローの動作を確認する。
5. 修正前後のアクセス記録と監査履歴を調べ、不審なデータ変更や権限変更の有無を確認する。

ログ確認は、今回の脆弱性が悪用されたと断定する作業ではない。未認証でデータの参照や変更に至り得るという評価を踏まえ、修正前の期間に異常がなかったかを確認するための調査となる。

業務データへの影響は各インスタンスの構成次第

今回の発表は、特定企業で情報漏えいが起きたという報告ではなく、ServiceNowのインスタンスデータへ不正に到達し得る製品脆弱性の公表である。実際に危険にさらされる情報は、各組織が同じインスタンスに保存するテーブル、構成情報、連携先、サービスアカウントの権限によって異なる。

人事申請、財務承認、取引先登録を対象インスタンスで処理している場合、それらのレコードやワークフロー設定は、任意コード実行、権限昇格、SQL実行の先でアクセスまたは変更され得る。ただし、HR、財務、取引先のデータが今回の3件によって実際に漏えい、改ざんされたとの発表はない。

現時点で確認されているのは、ホスト版への修正展開と、自己管理版およびパートナー向け更新の提供である。今後の焦点は、ServiceNowによる影響範囲や悪用状況の更新と、各自己管理環境で修正版への移行および適用後の確認が完了したかどうかに移る。