ServiceNow（NYSE: NOW）は2026年6月9日、APIエンドポイントの認証設定不備を悪用したセキュリティインシデントを公表した。攻撃者は認証なしでアクセス可能な状態になっていたREST APIを通じて、複数の顧客インスタンスからデータを取得したことが確認されている。

何が起きたのか

問題の核心は、APIエンドポイント /api/now/related_list_edit/create の設定にある。このエンドポイントが requires_authentication=false の状態で公開されており、認証なしで顧客インスタンスのデータを照会できる状態になっていた。

ServiceNowは「異常なアクティビティ」を検出後、2026年6月5日にホスト型顧客インスタンスへのセキュリティアップデートを適用。該当エンドポイントの設定を修正し、認証済みユーザーのみがアクセスできる状態にした。

本インシデントはServiceNowのカスタマーサポートポータル（ログイン必須）の掲示板と、直接のサポートケースを通じて該当顧客に通知された。サポートケースを受け取っていない顧客は影響を受けていないとみなされるとのことだ。

影響を受ける環境

ServiceNowによると、影響範囲は以下の通り：

  • Australiaプラットフォームリリースを使用している顧客
  • Australia以前のリリースを使用しており、特定の構成変更を行った顧客

CVEの採番については現時点で検討中とのことで、技術的詳細の公開も限定的な状態が続いている。

侵害の痕跡（IoC）

RedditのServiceNow管理者コミュニティでは、以下のIoCが共有されている：

  • 不審なIPアドレス: 51.159.98.241
  • 対象エンドポイント: /api/now/related_list_edit

今すぐ実施すべき対応

ServiceNow管理者は以下を速やかに確認・実施すること：

  • ログの精査: /api/now/related_list_edit へのリクエスト履歴を確認。特にIPアドレス 51.159.98.241 からのアクセスを重点的に調査する
  • 認証情報のローテーション: サポートチケット等のワークフロー経由で共有された資格情報やAPIトークンを刷新する
  • 漏洩データの特定: 不正アクセスを受けた可能性のあるチケットやレコードの内容を確認する
  • APIログの有効化: ログ収集が有効になっているかを確認・徹底する

ServiceNowインスタンスにはITサポートチケット、従業員レコード、内部ドキュメント、資産インベントリ、セキュリティインシデントレポート、業務システムの構成情報など、機密性の高いエンタープライズ情報が集約されている。こうしたデータが外部に漏洩した場合の被害は甚大だ。

日本のIT管理者への影響

ServiceNowは日本のエンタープライズでも広く使われるITSMプラットフォームだ。特に大手企業では業務フロー全体が集約されているケースも少なくない。今回のような「認証設定の見落とし」は決して対岸の火事ではない。

日本においてはServiceNow導入後のカスタマイズ過程でAPI設定が変更されるケースが珍しくなく、自社環境がAustraliaリリース以前かどうかに関わらず、APIエンドポイントの認証設定を棚卸しする好機として捉えるべきだ。

筆者の見解

今回の件で注目すべきは、攻撃手法の巧妙さよりも、認証設定という基本中の基本が見落とされていた事実だ。

requires_authentication=false という設定がホストされた顧客インスタンスに適用可能な状態で放置されていたこと——これはゼロトラストの観点から見て、最も根本的な設計の穴に分類される。「認証がなければアクセスさせない」は前提条件であり、議論の余地がない。

筆者は常日頃からNHI（Non-Human Identities）の管理が業務自動化のボトルネック解消に直結すると主張しているが、今回の件はその裏返しでもある。APIによるシステム間連携を推進すればするほど、認証・認可の設計が甘い箇所がリスクの集積点になる。「今動いているから大丈夫」という発想で放置された設定が、静かに脅威の入口になるのだ。

自動化を進めるならば、APIレベルの認証設定の監査を定期的なプロセスとして組み込むことは不可欠だ。エンタープライズプラットフォームのベンダーには、デフォルト設定を安全側に振り切る責任もある。その点でServiceNowには、今回の素早いパッチ対応は評価しつつも、設定のデフォルト値の設計について今一度見直してほしい——そう率直に申し上げたい。

出典: この記事は ServiceNow discloses security incident exposing customer data の内容をもとに、筆者の見解を加えて独自に執筆したものです。