未認証RCEで「AIの箱庭」が破られたら——ServiceNow AIプラットフォームのサンドボックス脱出脆弱性

今日の深掘りポイント

• AIサンドボックスを脱出できる未認証リモートコード実行（RCE）の可能性が示された時点で、SaaSに寄りかかった業務オペレーションは「境界の外で実行されるコード」を前提に守り直す段階に入っています。
• ServiceNowは修正を展開済みとされ、現時点で悪用確認はないとの報ですが、ITSM/ESMが担う承認・支払い・ID発行・自動化フローへの“横展開”は現実的な懸念です。
• 迅速な適用確認と、IntegrationHub/MID Serverの外向き通信制御、APIトークンの強制ローテーション、ログの可視化強化を同時に進める必要があります。
• メトリクスが示す全体像は「緊急度・実行可能性が高い一方、ポジティブ要素が乏しい典型的なサプライチェーン型SaaSリスク」です。パッチに依存し過ぎず、SaaS実行環境の“越境”をいかに抑え込むかが勝負どころです。

はじめに

ServiceNowのAIプラットフォームで、未認証の攻撃者がサンドボックスを脱出し、対象インスタンス上でコード実行に至る可能性が指摘されました（CVE-2026-6875）という報です。現時点で悪用の確認はなく、ベンダーは修正を展開しているとされています。けれど、ITワークフローの自動化とAI導入が進むほど、SaaSの一段外にある実行環境が組織の中核データや業務フローに触れられる距離は近づきます。今回の示唆は、SaaSの“箱庭”が一度破られた際の横展開の速さと深さを、私たちにもう一度考えさせてくれる出来事です。

深掘り詳細

事実整理（公開情報ベース）

• 脆弱性の性質: ServiceNowのAIプラットフォームにサンドボックス脱出を許す欠陥があり、条件次第で認証なしにRCEに至る可能性が指摘されています。修正は展開済みで、現時点で悪用は確認されていないと報じられています。
• 影響リスク: 機密データへの不正アクセス、ワークフロー（承認・払い出し・チケット）の改ざん、APIトークン窃取などが想定されます。
• 運用面: 影響を受けるリリースへのセキュリティ更新が展開され、自己ホスト構成の顧客向けにも修正が提供されているとされています（本点はベンダー公式情報での最終確認が望まれます）。
• 出典: 現時点で一般公開情報としては以下が確認できます。詳細は必ず公式のセキュリティ通知で突き合わせてください。
  • GBHackers: Critical ServiceNow AI Platform Flaw

注: 本件の技術詳細（攻撃前提条件、影響範囲、回避策の細部）は今後更新される可能性が高く、公式アドバイザリでの確認が不可欠です。

編集部の視点（インサイト）

• サンドボックスは“安全に錯覚しがちな層”です。AIやスクリプト実行基盤の箱庭が破られると、SaaSの論理境界の外にあったはずの権限・データ・自動化トリガーへと、一気に触手が届きます。これは「パッチ適用＝終了」では済まない種類の構造的リスクです。
• ServiceNowは統合の中枢です。IntegrationHub、MID Server、各種コネクタ、そして組織横断の承認フローが密に結びつくため、AI実行域からの横展開は「薄く広く」ではなく「深く速く」なりがちです。
• メトリクスの印象は、攻撃者の実利（未認証・高到達・高価値データ）と、防御側の取りうる即応策（修正適用・通信制御・資格情報ローテーション）が拮抗する局面です。つまり、動いた組織は守れますが、動きが遅いほど“業務の中核”が先に掴まれます。
• 監視の盲点が出やすいのもSaaS特有です。攻撃はSaaS内部の実行環境で完結し、従来のネットワーク境界では観測できないことが多いです。よって、アプリ層（フロー・スクリプト・OAuthプロファイル・RESTメッセージ・更新セット）の差分監視と外向き通信の強制的な制御が、オンプレ以上に効きます。

脅威シナリオと影響

以下は公開情報を前提に、編集部が仮説として整理した想定シナリオです（MITRE ATT&CKは仮説マッピングです）。

• シナリオ1: APIトークンの回収からクラウド横展開へ
  仮説: 未認証RCEでAI実行域に侵入し、ServiceNowに保存・参照可能なOAuthクレデンシャルやAPIトークンを窃取。これを用いてAWS/Azure/Google Workspace、GitHub、Slackなど外部SaaS/クラウドへ横展開し、データ持ち出しや設定改ざんに波及します。

  • ATT&CK例:
    • 初期侵入: Exploit Public-Facing Application（T1190）
    • 実行: Command and Scripting Interpreter（T1059）
    • 資格情報アクセス: Unsecured Credentials（T1552）
    • 発見・横展開: Discovery（TA0007）/ Use of Valid Accounts（T1078）
    • 流出: Exfiltration Over Web Services（T1567）

• シナリオ2: ワークフロー改ざんによる不正承認・支払い誘導
  仮説: 承認フローやビジネスルール、スクリプトインクルードを改ざんし、支払先や承認者をすり替え、資金や在庫の移動を誘導します。メール・チャット連携を使う通知を抑止すれば発覚までのラグも作れます。

  • ATT&CK例:
    • 防御回避: Impair Defenses（T1562）
    • 影響: Data Manipulation – Stored Data（T1565.001）/ Transaction Manipulation（関連する業務改ざんのアナロジー）

• シナリオ3: MID Server経由で社内ネットワークに着地
  仮説: ServiceNowからMID Serverのジョブやコマンド連携に手を伸ばし、オンプレADや資産管理、パッチ/構成ツールへ横展開します。Egressが緩い環境ほど実行パスが増えます。

  • ATT&CK例:
    • 横展開: Remote Services（T1021）
    • 権限昇格/持続化: Modify System Processes/Services（T1543）
    • 発見: Network Service Discovery（T1046）

影響評価（共通）

• データ: チケット/ケース/HR/資産/ナレッジ/添付ファイルの大量流出、サプライヤー情報や個人情報の二次被害が生じます。
• 業務: 承認・支払い・ユーザープロビジョニングの改ざんで、直接的な金銭・供給網・BCP影響が発生します。
• コンプライアンス: 個人情報保護・内部統制・サードパーティ管理の違反に直結します。報告・監査・対外説明コストが大きく膨らみます。

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

即応と構造対策を並走させるのが得策です。以下は編集部の提言です。

• 0. 事実確認と適用状況の可視化
  • ベンダーの公式セキュリティ通知で対象バージョンと対策を確認し、自組織の全インスタンス（本番・検証・サンドボックス）で適用済みかを棚卸しします。マネージド更新の場合も「適用完了時刻」を記録に残します。
  • 自己ホスト/専用構成がある場合は、適用手順・再起動・互換性影響を事前に検証します。
• 1. 一時的なリスク低減（境界外実行の遮断）
  • IntegrationHubやカスタムRESTメッセージの外向き通信をプロキシ/ファイアウォールで許可制（ドメイン/URI単位のallowlist）にします。未知ドメイン宛のPOST/PUT/DELETEは一時遮断します。
  • 不要なAI実行機能やスクリプト実行権限（特にGuest/匿名到達面）を一時的に無効化・縮退運転します（ベンダー推奨に従います）。
• 2. ログと証跡の確保（SaaSならではの観測設計）
  • 以下の差分・イベントをSIEMに集約し、90日以上の保持を確保します。
    • 新規/変更: Script Include、Business Rule、ACL、UI Action、Flow/Action/Integration、REST Message、OAuth Entity/Profile、Scheduled Job、Update Set
    • 外向き通信: IntegrationHubやMID Serverの宛先、HTTPメソッド、ボリュームの急変
    • アカウント: 権限昇格、ロール付与、APIキー/トークン作成
  • データエクスポート量・添付ファイルDLのしきい値アラートを設定します。
• 3. ハンティング仮説（インジケータの方向性）
  • 「短時間に作成→即削除された」スクリプト/フロー/RESTメッセージの痕跡を洗います。
  • 知らないクライアントからのOAuthクライアント登録やリダイレクトURI変更を抽出します。
  • 新規MID Server登録・信頼設定の変更、既存MIDのジョブ内容変更のスパイクを確認します。
• 4. 資格情報・シークレットの衛生管理
  • ServiceNowに格納されたOAuth/ベーシック認証・アクセストークンを全件洗い出し、優先度順に強制ローテーションします（特にクラウド基盤・IDaaS・決済連携）。
  • シークレットの平文格納（プロパティ/スクリプト内）を排除し、Secret Manager連携やKMS暗号化へ移行します。
• 5. 最小権限と変更統制
  • スクリプト実行権限やフロー開発ロールを最小化し、変更はPR/レビュー必須・署名付き更新セット等でワークフロー化します。
  • ゲスト/匿名アクセスのエンドポイント露出を棚卸しし、不要な公開を閉じます。
• 6. ネットワーク設計の見直し（SaaSでも“境界”を作る）
  • Egressを「既知先のみ許可」へ。プロキシでSNI/HTTP Host/メソッドを評価し、異常時は即遮断できるようにします。
  • MID Serverは分離ネットワークに配置し、到達先（AD/管理基盤）を細分化します。
• 7. 卓上演習と連絡網
  • 想定インシデント「SaaS実行環境での未認証RCE」を題材に、検知→一時遮断→資格情報ローテーション→対外公表の流れを卓上演習します。サプライヤ・主要部門・法務・広報との連絡網を前提整備します。
• 8. 中長期の構造対策
  • SaaS Security Posture Management（SSPM）やSaaS監査ログの常時取り込みを強化し、アプリ層の差分監視を標準運用にします。
  • 「AI/スクリプト実行＝信頼境界の外」を前提に、ゼロトラストの原則で通信・認可・証跡の三点を固めます。

参考情報

• GBHackers: Critical ServiceNow AI Platform Flaw

最後に。今回の論点は、単に“脆弱性が危険”という話ではありません。AIや自動化が業務の血流になった以上、実行がどこで起きるかを意識し、その越境を常に観測・制御・最小化しておくこと自体がリスク削減策です。パッチは出ています。だからこそ、次に破られたときの横展開をどう抑え込むか——そこまでを含めて、今日から環境を前に進めたいです。