ServiceNow、admin権限でホストOSに届く脆弱性 版の確認を

9月のパッチは、自社のServiceNowに当たっていますか。同社のクラウド（ホスト型）で使っていて、9月のパッチ適用プログラムどおりに当たっていれば、10月29日（米国時間）に公表された脆弱性のうち、重い2件は修正済みです。告知によれば、9月のプログラム（ServiceNow Patching Program）に参加した顧客には、更新が届きました。

ただ、プログラムの外にいるインスタンスは、自分で版を上げるまで残ります。

3件の中身と、修正済みの版

3件のうち2件はServiceNow AI Platform、つまり基盤そのものの脆弱性です。残る1件はストアのアプリ「SR - CSM - Task Plan Templates」にあります。告知の時点で悪用は確認されていません。見つかったきっかけは、社内の検査や顧客の診断、バグバウンティの報告だといいます。

基盤の2件の修正版は、ファミリーごとに次のとおりです。告知が挙げる版は2通り。9月のプログラムで届けた版と、同じ修正を含む少し前の版で、どちらかになっていれば2件ともやることはないという書き方です。

サンドボックスを抜ける脆弱性は今年3件目、今度は管理者から

ServiceNow AI Platformでサンドボックスを抜ける脆弱性は、今年に入ってこれで3件目。¹ CVEの記録を並べると、前の2件とは攻撃の入口も行き先も違うことが分かります。

数字だけなら、今回は前の2件より軽く見えます。認証が要るうえに、adminという強いロールが前提だからです。

ただ、行き先が違います。前の2件の説明は「プラットフォームの中でコードを実行」でしたが、今回は「その下のホストOSで任意のコードを実行し、さらに意図しないアクセスにつながりうる」とあります。adminは、もともとインスタンスの中でほとんどの操作ができるロールです。つまり、その手がインスタンスの外まで伸びる。そこが今回の新しさでしょう。

版が届くまでの危なさを左右するのは、adminを持つアカウントの数と守り方だと編集部はみています。

10月20日に紹介したSophosの事例では、攻撃者が電話でSMSの確認コードを聞き出し、1つのアカウントを乗っ取りました。そこからシングルサインオンでServiceNowに入り、sys_userから約2,500件を書き出しました（Sophos、GraphとServiceNowの侵入分析 復旧手順も点検を）。同じ入られ方でも、奪われたのがadminを持つアカウントで、インスタンスが今回の版に届いていなければ、手はインスタンスの外、サーバーそのものにまで届きえます。セルフホストなら、そのサーバーは自社のネットワークの中にあります。

前の例もあります。2024年7月10日に公表されたCVE-2024-4879は認証なしでコードを実行できる脆弱性でした。このときもServiceNowは、ホスト型に更新を当ててから公表しました。それでも公表から19日後の7月29日、米国のCISAが、悪用が確認された脆弱性の一覧（KEV）へ加えています。公表のあとに狙われるのは、更新の外に残ったインスタンスだとみるのが自然です。あのときは認証が要りませんでしたが、今回はadminが前提なので、同じ広がり方にはなりにくいでしょう。10月30日の時点で、今年の3件はどれもKEVに入っていません。

パスワードが平文で残る件は、更新のあとが気になる

CVE-2026-103094について、告知は「利用者のパスワードが平文のままシステムのテーブルに保存され、見る権限のない人に見えうる」と書きます。一方でCVEの記録の題は「OAuthの認証情報を平文で保存」。告知は利用者のパスワード、CVEの記録はOAuthの認証情報と、何が残るのかの書き方が食い違っています。評価では、ServiceNowの外にあるシステムへの影響も高いとされました。漏れたパスワードが、ほかのシステムでも使えてしまう場面を見ているのでしょう。

どのテーブルのどの連携なのか、更新の前にテーブルへ残った値を更新が消すのかは、告知からは分かりません。

ここからは推測です。題の「OAuth」と告知の「パスワード」を合わせて読むと、OAuthの手続きの中でパスワードを渡す連携が当たる見込みがあります。外からServiceNowに入る側なら、外部のツールがServiceNowのトークンをもらうときに、利用者名とパスワードを送る形の連携です。ServiceNowから外へ出る側なら、外部のサービスへのOAuthの設定をServiceNowに登録し、そこにパスワードを持たせている連携が考えられます。だから、どちらかに当たるアカウントがあれば、更新のあとにパスワードを変える価値があると考えます。値が消えたかどうかを、利用者の側から確かめる方法が告知にないからです。

影響するのは、パッチ適用プログラムの外にいるインスタンス

ホスト型のインスタンスにとって、ServiceNowのパッチ適用プログラムは抜けられない決まりです。四半期の最初の月にはその四半期で目標とする版を、2か月目と3か月目には月ごとに目標とする版を、ServiceNowが日程を組んで当てます。重い問題があれば、週ごとのセキュリティの修正（Weekly Security Hot Fix）も重なります。今回の告知にある「W35」「W38」の版が、9月のプログラムで届いた版です。

FAQの記述から拾うと、外れうるのは次の場合です。プログラムどおりの場合と並べました。

Xanaduは、この表の「サポートの終わったファミリー」に当たるとみています。²

見落としやすいのは2行目、先に自分でパッチを当てたインスタンスだと編集部はみています。告知の表はAustraliaのPatch 5のように「W38」の付かない版も修正済みに挙げており、それより新しいパッチなら修正を含む見込みは高いはずです。自分の版が表にないと、比べても答えが出ません。そこが厄介なところでしょう。FAQによると、目標より上の版にいるインスタンスは管理された道筋の外で、週ごとの修正も自分で入れる必要があります。表より新しく表にない版なら、サポートに聞くのが早道です。

Task Plan Templatesの件は、アプリを入れている会社だけが対象です。古い版なら3.0.0以降に上げます。³ただ3.0.0はYokohama以降でしか入らないため、Xanadu以前で使っている会社は、まずファミリーを上げることになります。ドメイン分離でグループ会社や顧客ごとにデータを分けている会社ほど、気にしたい件です。

今週の確認の手順

1. 本番と本番以外のインスタンスの版を一覧にし、上の表と比べます。管理者なら、インスタンスのstats.doで版（ファミリーとパッチ）を確認できます。予定されたパッチのCHGは、Now Supportの画面で見られます。本番を複製した検証用のインスタンスも、中身が本番と同じことが多いので数に入れます。
2. 表の版に届いていなければ、パッチの日程を入れます。表より新しく表にない版のときや、迷うときは、件名を「October 2026 Batched CVE Release」にしてサポートに聞きます。同じ問い合わせで、パスワードが平文で残る件がどのテーブルのどの連携に当たるか、更新の前に残った値が更新で消えるかも聞いておきましょう。セルフホストなら、告知が案内するセルフホスト向けのFAQ（ログインが要る）を開きます。運用を委託しているなら、版と当てた日を委託先に聞きます。
3. adminロールを持つアカウントを洗い出します。ユーザーとロールの対応のテーブル（sys_user_has_role）でadminに絞り、グループ経由で付いたadminも数に入れます。たとえば導入を手伝った委託先、異動や退職をした人、連携用のアカウントに残っていないかを見て、日々の作業に要らないならより狭いロールに替えます。残すadminは、シングルサインオンと多要素認証を通すアカウントに限り、SMSの確認コードより聞き出されにくい方法にします。Sophosの事例は、SMSのコードを電話で聞き出す手口でした。
4. now/app-managerで「SR - CSM - Task Plan Templates」を探します。入っていれば版を見て、2.0.1か3.0.0以降でなければ上げます。
5. Now Supportの会社の連絡先を見直します。パッチのCHGの通知も、ここに登録した窓口へメールで届きます。担当が替わったまま古い連絡先が残っていると、次の告知もだれも読まないまま過ぎてしまいます。

ServiceNowを入れている会社の情シスにとっては、毎日開くツールです。そのぶん、adminの付け方は導入のときのままという会社も少なくないはずです。今回の告知は、その棚卸しを始めるのにちょうどよいきっかけだと思います。

確認日: 2026年10月30日（ServiceNowの告知とFAQ、CVE.orgの記録、CISAのKEVの一覧）。