ServiceNow AIプラットフォームの事前認証RCEが実害化——運用ハブからの横断侵害リスクがいま現実です

今日の深掘りポイント

• ID基盤やSSOをすり抜ける“事前認証RCE”は、ゼロトラストの外周で守ってもSaaS内部で破られる典型パターンです。運用ハブ（ServiceNow）を起点に統合先へ波及する“広域爆発半径”が実務上の焦点になります。
• 影響は単なるホスト乗っ取りにとどまらず、ワークフロー改ざん、権限ロール操作、統合用シークレットの窃取を介した二次侵害へと接続しやすい構造です。
• 技術的対処（即時パッチ、公開面の遮断、ログ・ハンティング）と、業務的対処（変更凍結、ロール・職務分離の見直し、統合シークレット一斉ローテーション）を“同時並行”で回すことが肝になります。

はじめに

ServiceNowのAIプラットフォームで、認証なしにコード実行を許す重大な脆弱性（CVE-2026-6875）が悪用されています。ベンダは6月にパッチを出しており、サンドボックスで走るコード制限の強化方針も示しています。問題は「どれだけ早く直せるか」だけではなく、「直るまで、そして直った後に、どれだけ被害半径を小さく抑えられるか」です。ITSM/ESMの“中枢”を押さえられる怖さを、運用・統制・検知の三層で具体化しておきたいタイミングです。

深掘り詳細

事実関係（確認できていること）

• 脆弱性はServiceNowのAIプラットフォーム要素に存在し、認証不要で任意コード実行が可能と報じられています。実際の悪用も観測されています。
  参考: The Hacker Newsの報道
• ベンダは6月に修正を出しており、今後はサンドボックス環境でのコード実行制限を強化する方針です。
• 攻撃者は特定のエンドポイントを狙い、ServiceNowインスタンス自体や、接続されたプロキシ/ゲートウェイを含む周辺要素の完全侵害に至る可能性があります。

インサイト（ここから読み解けること）

• 事前認証RCEはID境界（SSOやMFA）以前で破られるため、SaaSの「公開面に置いた機能」が直撃点になります。SaaS側のIP許可制や管理面の到達制御が効いていない組織は、守る順番を見直す必要があります。
• ITSM/ESMは、インシデント、変更、資産、ディスカバリ、オーケストレーションが密結合しやすく、統合アカウントやAPIトークンが“運用の血流”として流れています。ここでRCEが起きると、業務プロセス改ざん（例：チケット消去・優先度変更・承認フロー短絡化）と技術的エスカレーション（例：統合シークレット窃取→他システム横展開）が同時に走り得ます。
• メトリクス全体感からは、即応性と実務的な行動可能性が非常に高い領域にあると評価できます。すなわち「すぐ直せる」「直さなければ広く深く効く」タイプです。運用中枢の性質上、検知・復旧に時間がかかるほど被害の性質が“業務崩れ”に転じる点を重く見るべきです。

脅威シナリオと影響

以下は仮説ベースのシナリオですが、MITRE ATT&CKの観点で攻撃の道筋を整理します。自組織の統合・運用形態に合わせて当てはめ、ログ/痕跡の有無を検証することを勧めます。

• シナリオ1：無差別スキャンからの踏み台化

  • 初期侵入: Exploit Public-Facing Application（T1190）
  • 実行: Command and Scripting Interpreter（T1059）
  • 永続化/隠蔽: Server Software Component: Web Shell（T1505.003）［仮説：スクリプト/拡張機構の悪用］
  • 発見・横展開準備: System Information Discovery（T1082）、Network Service Scanning（T1046）
  • C2: Application Layer Protocol: Web Protocols（T1071.001）
  • 流出: Exfiltration Over C2 Channel（T1041）
  • 影響の勘所: 管理画面やスクリプティング機能が改変され、気づきにくい持続化が施される恐れがあります。

• シナリオ2：統合シークレットを狙う二次侵害

  • 初期侵入: T1190
  • 資格情報アクセス: Unsecured Credentials（T1552）［仮説：統合用APIキー/トークンが設定領域やファイル相当の保管に存在］
  • 横展開: Remote Services（T1021）［仮説：プロキシ/ゲートウェイ/連携サーバへ接続試行］
  • アカウント操作: Create Account（T1136）、Valid Accounts（T1078）
  • 影響の勘所: 連携の“鍵束”を奪われると、ITSMの外側（監視、資産、ID、ナレッジ、CI/CD等）へ侵害が拡張しやすいです。

• シナリオ3：業務プロセスの不可視化と長期潜伏

  • 初期侵入: T1190
  • 防御回避/発見妨害: Modify Cloud Service Configuration（T1578）もしくはAccess Token Manipulation（T1550）［仮説：監査/通知設定無効化やWebhook改変］
  • 収集: Data from Local System（T1005）［仮説：添付ファイル/チケットコメント/ナレッジの収集］
  • 影響の勘所: チケット改ざんにより痕跡を消されたり、承認フローがバイパスされ、業務側の“正常性バイアス”で被害が長期化します。

日本の官公庁・重要インフラでは、外部委託や多層の運用ベンダが関与するケースが多く、アカウント・ロールの委任が複雑です。委任の鎖のどこかで強権トークンが使い回されていれば、影響は地政学的サプライチェーンの弱点にもなり得ます。権限とシークレットの“分離・最小化・ローテーション”を改めて再点検するべき局面です。

セキュリティ担当者のアクション

優先度順に、技術・運用の両面で即実行を意図したチェックリストです。ベンダ仕様や自組織の設定差異があるため、該当しない項目は読み替えてください。

• 0. 体制とリスク受容の明確化
  • 重要度の高い運用中枢であることを踏まえ、緊急変更プロセスを発動します。影響評価、承認、ロールバック計画を“短いサイクル”で回せる体制に切り替えます。
• 1. パッチ適用と公開面の遮断
  • ベンダ提供の最新修正を適用します。適用可否が直ちに判断できない場合は、対象エンドポイントへの到達制御（SaaS側のIP許可制、ZTNA/CASB経由の限定、管理系パスの到達制御）を強化します。事前認証RCEゆえ、認証前の経路を物理的に閉じる/絞ることが効きます。
  • 可能ならば、AI関連機能のうち不要な実行パスを一時的に停止/制限します（仮説的措置）。可用性より機密性・完全性を優先する短期判断が妥当です。
• 2. 侵害有無のスプリント調査（72時間目安の集中ハンティングを推奨）
  • 直近数週間のアプリ/監査ログを精査し、以下の痕跡を確認します（仮説ベースの観点）:
    • 不審なスクリプト実行・スクリプト定義の新規/更新（UI Scripts、Script Includes、Business Rules、Scheduled Jobs等）
    • 管理ロール付与・新規アカウント作成・APIキー/トークンの新規発行や権限昇格
    • Webhook/通知/監査設定の無効化・変更
    • 短時間に高ボリュームの添付・ナレッジ・インシデントデータ読み出し
    • 外向き通信の異常（C2様パターン、未知ドメイン、通常業務時間外の連続アクセス）
  • 「更新者がsystem/自動化アカウント」「変更理由・チケット紐付け欠落」といった“説明のつかない変更”に注目します。
• 3. 統合シークレットの一斉ローテーションと分離
  • ServiceNowから他システムへ接続する統合用資格情報（APIキー、OAuthクライアント、ベーシック認証、接続プロファイル）を棚卸しし、緊急ローテーションを実施します。用途単位で“最小権限・個別キー”化し、共有トークンの排除を進めます。
  • 連携プロキシ/ゲートウェイの到達制御を見直し、“ServiceNow発の接続元”を明示的に制限します。
• 4. 業務プロセスと可視化の防御
  • 重要ワークフロー（承認・変更・例外申請）の強制二重承認や独立監査通知を一時強化し、プロセス改ざんで痕跡を消されるリスクを抑えます。
  • 「ServiceNow自体のログ」を外部SIEMへリアルタイム転送し、改ざんから独立した監査線を確保します。
• 5. 検知ルール（初期セット）
  • ルール例（仮説）:
    • 短時間に“スクリプト関連オブジェクト”の連続更新
    • 新規の管理ロール付与/剥奪と同時期のAPIキー発行
    • 通常とは異なるASN/ジオロケーションからの管理操作
    • 大量のレコード閲覧直後の外部送信増加（相関ルール）
  • 既知のIoCが公開されれば直ちに組み込み、周辺資産（プロキシ/ゲートウェイ/統合先）にも横断適用します。
• 6. ベンダ・委託先との連携
  • ベンダの追加ガイダンスが出次第、設定変更や緩和策をフォローします。
  • 運用委託・MSP・SIerと、権限・鍵・運用区画の見直しを短期完了目標で合意します。
• 7. 中長期の教訓化
  • “SaaS中枢のRCE”を前提にした年次リスクシナリオへ格上げし、IP許可制・職務分離・鍵管理・ログ二重化（SaaS外部保存）を標準化します。
  • AI/自動化系サンドボックスの安全策は、デフォルト拒否・許可リスト型へ寄せ、運用の利便性は段階的に回復するアプローチが現実的です。

参考情報

• 報道: Critical ServiceNow AI Platform Flaw Exploited (The Hacker News)

本件は「パッチを当てた」で終わらず、統合された業務とセキュリティの継ぎ目を丁寧に縫い直す仕事が求められます。中枢を守るのは、技術と運用の小さな意思決定の積み重ねです。今日の一手を、明日の平時化につなげていきたいところです。