サイトアイコン IT & ライフハックブログ|学びと実践のためのアイデア集

Ivanti Neurons for ITSMに未認証RCE脆弱性、8件の影響と更新手順

企業向けITサービス管理基盤を、不審なデータから守る防御層を表したイメージ

Ivanti Neurons for ITSMに、認証なしでサーバー上の任意コードを実行されるおそれがある2件を含む、計8件の脆弱性が公表されました。

オンプレミス版の管理者は、稼働版と公開範囲を確かめ、対応する2026年9月セキュリティパッチまたは2026.2以降への更新を進める必要があります。

ただし、Ivantiの2026年9月セキュリティ更新情報は、公表日の9月8日時点で実環境における悪用の証拠はないと説明しています。

公表された8件の脆弱性

デシリアライゼーションとは、保存や送信のために変換されたデータを、アプリケーション内のオブジェクトへ戻す処理です。

外部から受け取ったデータを安全に検証せず復元すると、攻撃者が用意した内容によって意図しない処理が動く場合があります。

IvantiのNeurons for ITSMセキュリティアドバイザリTWCERT/CCの脆弱性情報が示す8件は、必要な権限と不備の種類によって次の三群に分けられます。

条件 CVE 想定される影響
認証なし CVE-2026-12744、CVE-2026-12745 信頼できないデータのデシリアライゼーションによる遠隔コード実行
認証済み CVE-2026-12648、CVE-2026-12650、CVE-2026-12651 信頼できないデータのデシリアライゼーションによる遠隔コード実行
認証済み CVE-2026-12645、CVE-2026-12646、CVE-2026-12647 認可の不備による遠隔コード実行

TWCERT/CCは、認証を必要としない2件をいずれもCVSS 9.8として掲載しています。

認証済みの攻撃者を前提とする残り6件も、被害が小さいという意味ではありません。

権限の弱いアカウントを奪われた場合や、不要なアカウントが残っている場合には、脆弱性を足掛かりとしてサーバー上の処理へ影響が及ぶ可能性があります。

影響を受ける版と修正版

フランスCERTのアドバイザリは、クラウド版とオンプレミス版の対象を分けて示しています。

クラウド版はIvanti側で修正済みとされますが、利用組織は自社テナントの保守情報と連携機能への影響を確認しておくと、更新記録を監査へ残しやすくなります。

提供形態 影響を受ける版 対応先
CloudまたはSaaS 2026.2 mo2026.2以降。クラウド環境には修正が適用済み
オンプレミス 2025.2 2025.2 Sept 2026 Security Patch
オンプレミス 2025.3 2025.3 Sept 2026 Security Patch
オンプレミス 2025.4 2025.4 Sept 2026 Security Patch
オンプレミス 2026.1 2026.1 Sept 2026 Security Patch
オンプレミス 2026.2以降 修正を含む版

版番号だけで判断せず、管理画面や配備台帳で実際のビルドとパッチ適用状況を照合してください。

検証環境と本番環境で更新状態が異なる組織では、台帳上の代表値だけを見ると未修正サーバーを見落とします。

管理者が進める対応手順

1. 対象サーバーと公開範囲を特定する

資産台帳、DNS、ロードバランサー、リバースプロキシの設定を突き合わせ、稼働中のNeurons for ITSMを洗い出します。

開発用や移行用として残った環境も確認対象です。

インターネットから到達できる管理画面やAPIがあれば、更新完了まで接続元制限やVPN経由への切り替えを検討します。

2. 復旧手段を確保してから更新する

組織の変更管理手順とIvantiの手順に従い、設定、データベース、添付ファイル、連携設定を復元できる状態にしてからパッチを適用します。

バックアップは取得しただけでは不十分で、保存先、復元担当者、復元に必要な認証情報を確認しておく必要があります。

本番適用前には、認証、チケット登録、メール取り込み、API連携、定期処理など、自社が使う主要機能を検証環境で確かめます。

3. 更新後に版と機能を再確認する

再起動やサービス復旧だけで完了とせず、実行中の版、適用済みパッチ、外部公開設定を証跡として保存します。

SSO、メール、資産管理などの外部連携についても、認証失敗や処理滞留が起きていないか確認します。

ロールバックした場合は脆弱な状態へ戻るため、単なる作業失敗として閉じず、再適用の期限と責任者を決めます。

4. 公表前後のログを点検する

Ivantiは公表時点で悪用を確認していませんが、「悪用されていないことが保証された」という意味ではありません。

Webアクセス、認証、管理操作、アプリケーション、OS、EDRのログを保全し、通常と異なる接続元、急な権限変更、未知のプロセス、予期しないファイル変更がないかを調べます。

異常が見つかった場合は、ログを消さずにネットワーク分離とインシデント対応へ移り、影響を受けた認証情報の変更範囲を判断します。

更新だけで終わらせない運用設計

今回のように一度に複数の脆弱性が公表されると、個々のCVEを読む作業よりも、どのシステムを誰が更新するかという運用上の曖昧さが遅延を生みます。

製品名、提供形態、版、公開範囲、業務責任者、技術責任者、保守期限を一つの台帳で追えるようにすると、対象確認から対応判断までを短縮できます。

変更後の確認項目も定型化し、認証や主要連携のテスト結果をパッチ記録と一緒に残してください。

脆弱性情報を受け取る担当者と、実際に更新できる担当者が異なる場合は、通知先、一次判断の期限、緊急変更の承認経路まで決めておくと滞留を防げます。

よくある質問

実際の攻撃で悪用されていますか

Ivantiは2026年9月8日の公表時点で、今回の脆弱性が実環境で悪用された証拠はないとしています。

ただし、将来の悪用可能性や個々の環境の安全性を保証する情報ではないため、対象版の放置は避けるべきです。

クラウド版の利用者にも作業はありますか

クラウド環境には修正済みと案内されています。

利用組織側では、テナントの更新通知を保存し、SSOやAPIなど自社管理の連携が正常かを確認してください。

外部公開していなければ更新は不要ですか

不要とは判断できません。

認証済み利用者を前提とする6件も含まれ、内部アカウントの侵害や不要な経路から影響を受ける可能性があるためです。

参考情報

この記事に関連する株式会社greedenの取り組み

脆弱性対応は、製品を更新して終わりではなく、構成把握と検証、保守の手順まで設計してこそ継続します。株式会社greedenは、要件定義から運用改善まで一気通貫のWebシステム開発を支援しています。

モバイルバージョンを終了