TL;DR
業務システムに「データを返す API」があるのは普通のことだ。だが 2026 年 6 月、ServiceNow の一部 REST エンドポイントが、セッションもトークンも資格情報の検査もないまま、顧客インスタンスのテーブルを照会できる状態で出荷されていたことが開示された。認証を必須化するフラグ（requires_authentication）が外れたまま提供され、未認証の要求でも内部データに到達できた（該当エンドポイント・観測 IP・是正と通知のタイムラインは後述）。攻撃が成立した本質は、エンドポイントが「認証を担保しているはず」という設定上の信頼に依存し、要求者がそのデータ照会を行う認可を持つかが、応答の前に独立検証されていなかった点にある。本事案を、Pillar 03（エージェント権限証明）を「アクター一般の権限・ID の証明」として読む観点から、信頼が”設定”に基づき行動ごとに証明されていない構造として構造的に分析する。検出側・ベンダーの役割は、否定ではなく役割分担として描く。Brief 006・033・029・013 に連なる。
事案概要
- 対象: ServiceNow のホスト型顧客インスタンス（Australia プラットフォームリリース、または旧リリースで特定の構成変更を行った顧客）
- 開示: 2026-06-09、ServiceNow がサポートポータル内のバルティン（顧客ログインの内側）と個別サポートケースで影響顧客に通知。6-10 に Trust ポータルで追加アドバイザリを公開
- 欠陥の所在: Scripted REST リソースが
requires_authentication=falseで出荷され、セッション・トークン・資格情報の検査なしに要求を受理した。該当エンドポイントは/api/now/related_list_edit/create - 観測された活動: ServiceNow は本件に関連する「異常な活動」を検知し、一部顧客でインスタンステーブルへの照会が成功した証跡を確認。活動は 6 月 2〜3 日に遡り、外部 IP
51.159.98.241が当該エンドポイントへ到達していた - 是正: 2026-06-05、ServiceNow がエンドポイント構成を変更し、認証済みユーザーのみにアクセスを限定（
requires_authenticationをtrueへ） - 想定影響データ: ServiceNow インスタンスは IT サポートチケット・従業員記録・資産インベントリ・セキュリティインシデント記録・ワークフローデータに加え、チケット本文に埋め込まれた API キーや認証情報を保持し得る。どのデータが参照されたかは未開示
- 核心: 認証を担保するはずの設定が外れていたこと自体ではなく、「この要求者は、このデータ照会を行う認可を持つか」がエンドポイントの応答前に独立検証されていなかったこと
タイムライン
- 2026-04-22: ServiceNow が、類似の問題を記述した秘匿のバグバウンティ報告を受領
- 2026-06-02〜03: 当該エンドポイントへの不審アクセスを観測（外部 IP
51.159.98.241）。一部顧客でインスタンステーブルの照会成功を確認 - 2026-06-05: ServiceNow がエンドポイント構成を認証必須へ変更する更新をホスト型インスタンスに適用
- 2026-06-09: 影響顧客へサポートバルティン／個別ケースで通知。BleepingComputer が報道
- 2026-06-10: ServiceNow が Trust ポータルでアドバイザリを更新。観測された活動はバグバウンティに関連する研究者・顧客主導の調査に由来する可能性が高く、悪性アクターによるものとは限らないと表明。CVE 発行は検討中とした
注: ServiceNow は CVE 発行を検討中であり、活動主体の特定・参照データの範囲は調査の進行に依存するため、本文では断定しない。
攻撃ベクター
本事象は、エンドポイントが要求者の認可を応答の前に独立検証しない構造に起因する。失敗がデータ照会へ伝播する経路は以下の通り。
- 認証フラグの欠落: Scripted REST リソースが
requires_authentication=falseで出荷され、セッション・トークン・資格情報の検査なしに要求を受理する状態だった - 未認証要求の受理: 攻撃者（または研究者）が
/api/now/related_list_edit/createへ未認証で到達。エンドポイントは「呼び出された＝処理してよい」として応答した - インスタンステーブルの照会: 認証境界を経ずに顧客インスタンスのテーブルへクエリが通り、内部データに到達し得る状態が生じた
- 保存秘密への波及可能性: ServiceNow のチケット・ワークフローには API キーや認証情報が混入し得るため、参照されたデータ次第で二次的な認証情報露出に連鎖し得る
- 事後の是正: 異常検知の後に構成を認証必須へ変更。ただしこれはエンドポイントが未認証で応答し得た後に作動する事後の措置である
構造的論点
本事案は Pillar 03（エージェント権限証明）を「AI エージェントに限らないアクター一般の権限・ID の証明」として読む観点に属する。中心的な失敗 primitive は、エンドポイントへの要求が、その要求者の認可を行動ごとに証明させるのではなく、「認証を担保しているはず」という設定上の前提に依存して受理された点にある。secondary に agent-infrastructure（API という基盤層）と attribute-proof-bypass（認証済みという属性が真正性検証なく前提化された）を併記する。
API の認可モデルが核心である。requires_authentication のような設定は、エンドポイントを呼び出すアクターが正規に認可されているかを「設定が担保している」という前提に置き換える。その設定がひとつ外れただけで、認可の検査そのものが消える。本事案は、認証を「フラグの状態」に委ねた結果、要求者がどのデータを・誰の認可で照会してよいかを、応答の前に独立検証する層が存在しなかったことを示す。
Brief 006（Google API キーの失効という属性が独立検証されず、削除後も有効だった）と同系で、認証・認可の状態が信頼の前提にされるのに独立検証されない構造である。Brief 033（エッジ機器の位置的信頼と保存資格情報で横展開が受理された）とも、「いったん成立した信頼前提が、行動の範囲に縛られず通用する」点で同根。Brief 029（OAuth トークンが操作対象にスコープされず全リポジトリに有効）とも、認可が行動の範囲へ縛られていない点で連なる。本事案は、その primitive がエンタープライズ SaaS の API 境界で、顧客インスタンス全体の照会可能性へ波及した実地事例である。
検出と証明の落差
ServiceNow による異常検知、構成更新の適用、影響顧客への通知、外部研究者・報道による可視化は、被害把握・封じ込め・再発防止に不可欠であり、本 Brief がその役割を否定するものではない。露出したエンドポイントの特定とログ精査、チケットに混入した認証情報のローテーションは最優先の実務対応である。
一方で、検出は「この要求者が、このデータ照会を行ってよいか」自体を変えない。本事案の照会は、正規の REST エンドポイントを通じて進み、各要求は単体ではプロトコル上正常に見える。設定の欠落は外形的には正常な応答として現れ、検知された時点では未認証要求が既に処理され得る状態にあった。欠けていたのは「この要求者は、この照会を・この範囲で行う認可と来歴を持つか」という応答時点の独立検証であり、これは異常検知や事後のログ追跡とは別系統である。設定フラグの状態が認可の証明と同一視される限り、検出は露出の後追いにならざるを得ない。
事前証明（pre-execution attestation）は、認証を「設定が認証を担保しているか」から「この要求が、スコープされた認可と来歴を持つかの応答前検証」へと反転させる設計を採る。エンドポイントの設定状態に依存する代わりに、要求ごとに検証可能でスコープされ再利用不能な proof を提示させることで、設定がひとつ外れても、proof が「この照会は正規の認可・来歴を欠く」と告げれば応答は事前に block される。異常の検出（detection 的な「この要求は普段と違うか」）と要求の事前証明（「この照会は認可・来歴を持つか」）は代替ではなく 補完 の関係にある。設定や保存資格情報に依存しない認証の考え方は 「Proof-as-Auth: 鍵を一度も送らずにサインインする」（Lemma、2026-05）、検出と事前証明の thesis は 「AI 時代のサイバー防衛に残された、最後の層」（Lemma、2026-05）を参照。
対応経緯と業界動向
- ServiceNow: 異常検知の後、当該エンドポイントを認証必須へ変更する更新を 6-05 に適用。6-09〜10 に影響顧客へ通知し、Trust ポータルでアドバイザリを更新。観測された活動はバグバウンティに関連する研究者・顧客主導の調査に由来する可能性が高いと表明し、CVE 発行は検討中とした
- 開示の論点: 当初のバルティンが顧客ログインの内側に置かれ、広く可視化されなかった点や、4-22 のバグバウンティ報告から 6-05 の更新適用まで時間を要した点が、外部から論点として挙げられている
- 業界横断の論点: SaaS の API において、認証・認可を「エンドポイント設定が担保する」前提に置く構成が、設定の一点欠落で認可検査そのものを失わせる増幅器になる。設定状態を認可の証明と同一視せず、要求ごとにスコープされた認可・来歴を検証する（proof-as-auth / per-request attestation）方向へ、API のアイデンティティ設計の重心を移す議論が進んでいる。チケットやワークフローに認証情報を保存しない運用、構成ドリフトの継続検査も実務上の論点
Lemma による分析
本事案で露呈した構造（エンドポイントへの要求が、要求者の認可を行動ごとに証明させるのではなく、設定上の前提に依存して受理される）に対して、Lemma は、認証を「設定が認証を担保しているか」から「要求ごとのスコープされた認可・来歴の応答前証明」へ反転させる設計を提示している。設定状態や長期資格情報に依存せず proof を提示する proof-as-auth の考え方では、エンドポイントの設定がひとつ外れても、正規の認可・来歴の proof が成立しなければ照会は事前に reject される。エンドポイントの応答を「呼び出された」ではなく「この要求は認可・来歴を持つ」という事前証明に紐付けることで、設定ドリフトや未認証要求があっても、認可されていない照会を実行前に区別できる。設計思想は Pillar 03 — エージェント権限証明（Lemma）および 「Proof-as-Auth: 鍵を一度も送らずにサインインする」（Lemma、2026-05）を参照のこと。
Sources
- ServiceNow Trust（一次）: セキュリティ通知（2026-06、未認証アクセスに関するアドバイザリ・観測された活動とバグバウンティ報告） — https://trust.servicenow.com/notifications/1205429e-fea3-4cbf-b37b-8cd3a4e07aef
- BleepingComputer: “ServiceNow discloses security incident exposing customer data”（2026-06-09／6-10 更新、エンドポイント・構成・タイムライン） — https://www.bleepingcomputer.com/news/security/servicenow-discloses-security-incident-exposing-customer-data/
- SOCRadar: “ServiceNow Breach: Customer Data Exposed Through Unauthenticated API Access”（2026-06、影響範囲・対応） — https://socradar.io/blog/servicenow-breach-customer-api-access/
Brief 配布について
Lemma Critical Brief は Lemma が発行する脅威インテリジェンス・ブリーフです。本資料は公開情報の構造化分析であり、特定の組織への監査・診断・推奨ではありません。意思決定の参考として用いる場合は、貴組織の Lemma Critical 担当に直接ご相談ください。
Discovery Call → ホワイトペーパー → ✉️ ニュースレター →
(c) 2026 FRAME00, INC. — Built for decisions that matter.