結論から言う。今回ServiceNowで起きたのは、ソフトウェアの「脆弱性」ではなく「設定」の見落としだ。 業務システムの一部APIエンドポイントが、認証を要求しない状態(requires_authenticationが無効)になっており、条件が揃えば外部から特定のテーブル情報に到達できる状態だったことが、2026年6月9日に報じられた。CVE番号は付与されておらず、ServiceNow自身も「評価中」としている。パッチを当てれば終わる話ではなく、「自社のAPI公開設定を誰が・いつ・どう点検しているか」という運用面の問い直しが必要になる事案だ。
何が起きたか
- ServiceNowのREST APIエンドポインの一部で、認証を要求しない設定になっている状態が確認された。ServiceNowは2026年6月5日にセキュリティ更新を適用し、該当設定を無効化(認証必須化)した。
- 影響が疑われる不審なアクセスは、更新適用以前の数日間に観測されたと報じられている。
- アクセス可能だった情報の種類は正式には開示されていないが、一般にServiceNowインスタンスにはITヘルプデスクのチケット内容や従業員関連の記録、資産管理情報などが保存される。特定のプラットフォームリリースを使用し、なおかつ該当の設定変更を行っていた顧客が対象とされる。
- 重要な経緯として、ServiceNowは2026年4月22日に非公開のバグバウンティ報告としてこの脆弱な設定を把握していたが、パッチ適用は6月5日までかかった。この間の6月上旬、顧客インスタンスを狙ったとみられる活動が確認されたことが、更新適用のきっかけになったと報じられている。
- 加えて、ServiceNowは調査の結果、観測された挙動は「セキュリティ研究者またはバグバウンティ提出に関連した、顧客主導の調査活動」である可能性が高いと6月10日付で説明を更新している。悪意ある大規模な情報窃取が確定した事案ではない点には注意が必要だ。
一次報道としてBleepingComputerを参照した。ServiceNow公式のトラストポータル等での詳細開示内容は今後更新される可能性があるため、自社が対象顧客に該当するか懸念がある場合は、ServiceNowからの公式通知・トラストポータルを直接確認することを推奨する。
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
なぜ「脆弱性ではなく設定ミス」が厄介なのか
CVEが付与されるような脆弱性であれば、ベンダーのパッチを適用すれば対応が完了する。しかし今回のように「顧客側の設定・カスタマイズの組み合わせによって意図せず認証が外れる」というパターンは、ベンダーのパッチ配布だけでは解決しない。SaaSやノーコードプラットフォームは、標準機能に加えて顧客ごとにAPI連携やカスタムスクリプトを追加できる設計になっていることが多く、その追加設定こそが盲点になりやすい。
これはServiceNowに限った話ではない。Salesforceのカスタムオブジェクト共有設定、kintoneのAPIトークン権限、Microsoft 365のPower Automate連携など、「標準では安全でも、カスタム設定次第で意図せず公開範囲が広がる」構造を持つSaaSは多い。自社で使っているSaaSに同種の設定項目がないか、一度棚卸しする価値がある。
自社に関係あるか確認すべきポイント
- ServiceNowを利用している場合、対象プラットフォームリリース・設定変更の有無に該当するか、ベンダーからの通知やトラストポータルの情報を確認したか
- ServiceNow以外でも、Salesforce・kintone・Microsoft 365等でカスタムAPI連携やスクリプト拡張を行っている場合、認証設定を「意図的に緩めた」箇所が残っていないか
- 過去にPoCやテスト目的で一時的に認証を緩めた設定を、恒久設定に戻し忘れていないか
- 自社のSaaS環境で、誰がAPI・連携設定の変更権限を持ち、変更履歴がどこまで追跡できるか
誰が読むべき記事か
- ServiceNow・Salesforce・kintone等のSaaSを業務システムとして利用し、カスタムAPI連携や外部連携を行っている情報システム担当者
- SaaS導入・カスタマイズをベンダーやパートナーに委託しており、設定変更の中身を自社で把握しきれていない経営者・DX推進担当者
- 「脆弱性診断はしているが、SaaSの設定監査までは手が回っていない」企業の担当者
よくある質問
Q. 自社もServiceNowを使っていますが、どう対応すればよいですか。 A. まず、該当プラットフォームリリースや設定変更の有無について、ServiceNowからの通知やトラストポータルの情報を確認してください。不明な場合はベンダーサポート窓口、または第三者による設定監査の利用も選択肢です。
Q. 今回の件は情報漏えいと断定してよいのでしょうか。 A. ServiceNowは後日、観測された挙動がセキュリティ研究者やバグバウンティ関連の調査活動である可能性が高いとの見解を示しています。悪意ある大規模流出と断定する材料は現時点では確認できておらず、本記事でも断定は避けています。自社への影響有無は公式情報で確認してください。
Q. CVE番号がつかないインシデントは軽視してよいですか。 A. いいえ。CVE番号は主にソフトウェア自体の脆弱性に付与される仕組みであり、設定ミス起因のリスクには付与されないことがあります。CVEの有無と深刻度は必ずしも一致しないため、番号の有無で軽重を判断しないことをおすすめします。
GXOに相談すべきタイミング
- 自社で利用しているSaaS・ノーコードプラットフォームのAPI・連携設定を、誰も体系的に棚卸ししたことがない場合
- ベンダーやパートナーにSaaSカスタマイズを委託しており、設定変更の中身をブラックボックスのまま運用している場合
- 過去のPoCやテストで緩めた設定が、現在も残っていないか確認したい場合
- SaaS単体の設定監査にとどまらず、業務システム全体のアクセス制御・API連携方針を見直したい場合
自社のSaaS・業務システムのAPI公開設定に不安がある場合は、委託先ベンダーのセキュリティ評価やSaaS設定監査を含めた点検を検討したい。SaaS連携やカスタムAPIの設計そのものを見直したい場合は、DX・システム開発の観点から要件を整理することもできる。まずはセキュリティの全体像から、自社に必要な対策の優先順位を確認することも可能だ。
本記事のインシデント情報は2026年7月2日時点で確認できた報道に基づく。ServiceNow公式による続報・詳細開示が更新される可能性があるため、自社への影響が疑われる場合は公式情報を直接確認することを推奨する。
