結論から言います。Ivantiが2026年8月11日に公表した「Ivanti Endpoint Manager（EPM）」の脆弱性3件は、いずれも深刻度「高」で、最大CVSSは8.1です。修正版はEPM 2024 SU7で、2024 SU6以前を使っているなら更新対象になります。公表時点で悪用は確認されていませんが、EPMは2026年3月にも別の脆弱性がCISAのKEV（悪用が確認された脆弱性カタログ）に載った製品です。「まだ悪用されていないから急がない」判断は取りにくい相手だと考えてください。
この記事でわかること
- Ivanti EPMとは何をする製品で、なぜ「うちにはない」と思っている組織にも入っていることがあるのか
- 公表された3件のCVEの中身と、実務上どれが痛いのか
- 自社が該当するかの確認手順と、優先度の付け方
- 同時に案内された「Ivanti Neurons for MDM」側の扱い（結論：利用者の作業は不要）
Ivanti EPMとは何者か
Ivanti Endpoint Manager（EPM）とは、社内のPCやサーバにエージェントを入れて、資産インベントリ・ソフト配布・パッチ適用・リモート操作をまとめて行う統合エンドポイント管理（UEM）製品です。Windows、macOS、Linux、Chrome OS、IoT機器を管理対象にできると公式に案内されています。導入するのは情シス部門そのもので、キッティングと日々の運用を支える基盤にあたります。
ここが重要なのですが、この製品は「LANDESK Management Suite」の後継です。LANDESKとHEAT Softwareが2017年1月に合併してIvantiとなり、製品名もバージョン2017.1からIvanti Endpoint Managerに変わりました。資産管理台帳に「LANDESK」と書いたまま更新していない組織や、担当者が代替わりして「昔から入っている管理ツール」としか認識していない現場では、今回のアドバイザリが自社の話だと気づけないおそれがあります。「Ivantiは使っていない」と即断せず、まず管理サーバの製品名とバージョンを見てください。
あわせて公表された「Ivanti Neurons for MDM」も、旧「MobileIron Cloud」の後継です。MobileIronは2020年12月にIvantiが買収しており、スマートデバイス管理でこちらを使い続けている組織は少なくありません。
何が起きたのか
Ivantiは2026年8月11日（米国のパッチ火曜日に合わせたタイミング）に、EPMのセキュリティアドバイザリを公開しました。対象は3件で、すべて深刻度「高」です。
| CVE番号 | CVSS v3.1 | 種別（CWE） | 概要 |
|---|---|---|---|
| CVE-2026-18129 | 8.1（高） | CWE-295 不適切な証明書検証 | Coreでの機微情報の平文送信。中間者位置にいる遠隔・認証不要の攻撃者が、外部SQL接続用の認証情報を盗める |
| CVE-2026-18127 | 7.7（高） | CWE-73 ファイル名の外部制御 | 遠隔の認証済み攻撃者が、セッション録画の保存先として設定したS3バケットに対し完全な書き込み権を得る |
| CVE-2026-18125 | 7.5（高） | CWE-125 領域外読み取り | エージェント側の不具合。遠隔・認証不要の攻撃者が細工した入力でエージェントサービスをクラッシュさせられる |
影響を受けるのはEPM 2024 SU6以前のすべてで、修正版は2024 SU7です（Ivantiの提供チャネルILSから入手）。Ivantiは公表時点で「悪用の証拠はない」「他のIvanti製品には影響しない」としています。
3件のうち、どれから手を付けるべきか
スコアが一番高いのはCVE-2026-18129ですが、成立条件は「中間者位置を取れること」です（CVSSベクタでも攻撃条件の複雑さがHighと評価されています）。EPMのコアサーバと外部SQLサーバの通信がデータセンタ内で閉じているなら、外部からいきなり刺さる類ではありません。ただし漏れるのはデータベースの認証情報です。EPMのデータベースには全社の端末インベントリと構成情報が入っているため、内部に足場を作った攻撃者にとっては次の一手として極めて価値が高い。「内部だから低リスク」と読み替えるのは危険です。
CVE-2026-18125は影響が可用性のみ（エージェントのクラッシュ）で、一見軽く見えます。しかしエージェントが落ちるということは、その端末のパッチ配布と資産把握が止まるということです。管理コンソール上は「しばらく応答がない端末」に見えるだけで、攻撃されて黙らされたのか、単に電源が落ちているのかを区別しづらい。管理の目を潰してから本命の攻撃に移る、という順序を考えると、単なるDoSとして流す気にはなれません。
CVE-2026-18127はセッション録画の保存にS3バケットを構成している場合が前提です。該当する構成でなければ優先度は下がるので、まず自社の設定を確認してください。
自社が該当するかの確認手順
- まず版数：EPMの管理コンソールでコアサーバのバージョンを確認し、2024 SU6以前かどうかを見る。ここが一次判定です。
- 製品名の読み替え：資産台帳や購買記録に「LANDESK」「LANDesk Management Suite」「LDMS」とあれば、実体は現行のEPMである可能性が高い。
- エージェントの存在：管理対象端末にはWindowsサービスとしてエージェントが常駐します。Ivantiのドキュメントでは、コアサーバと管理対象端末の間の通信にTCP 9593〜9595、リモートコントロールにTCP 9535などを使うと案内されています。Endpoint Managerのポート一覧を参照し、ファイアウォールやNDRの通信ログから存在を洗い出す手もあります（プロセス名・パスは版により異なるため、確実なのはコンソール側のインベントリです）。
- Neurons for MDM側：こちらはSaaSで、中程度の脆弱性1件が2026年6月下旬のR124で修正済みです。CVE番号の付与基準を満たさなかったとIvantiは説明しており、利用者側の作業は不要とされています。
なぜ「悪用未確認」でも急ぐべきなのか
EPMは実績のある標的です。2026年2月に公表されたCVE-2026-1603（2024 SU5より前の認証バイパス。認証不要で保存された認証情報を窃取できる）は、その後CISAのKEVカタログに登録され、米国連邦機関への対応期限は2026年3月23日に設定されました。つまり、同じ製品で「公表→実際の悪用→KEV登録」という流れが半年以内に起きています。
加えて構造的な事情もあります。EPMのような管理基盤は全端末にエージェントを配り、ソフトを配布し、管理者権限で動く——攻撃者から見れば、1台落とせば社内全域に配れる理想的な踏み台です。だからこそ管理系製品は狙われ続けます。KEV登録を待ってから動くと手遅れになりがちな点は、LoadMasterの脆弱性がKEV登録まで39日かかった件でも触れたとおりです。
考察：ベンダーが「AIで見つけた」と言い始めた意味
今回のIvantiの発表で目を引いたのは、脆弱性の検出に高度な言語モデルを組み込んだことが発見につながったと自ら述べ、今後こうした公表は増える見込みだと予告している点です。同社はこれを「製品セキュリティへの取り組みの証」と位置づけています。
方向性としては妥当ですが、運用側にはそのまま負荷として跳ね返ります。検出能力が上がれば、悪用の有無にかかわらずアドバイザリの本数は増える。「件数が増えた＝製品が劣化した」ではなく「見つかるようになった」と読み替えたうえで、増える通知を捌く仕組み——受信経路の一本化と、深刻度だけでなく自社構成を踏まえたトリアージ——を先に整えておきたいところです。件数で消耗しないための考え方は月例パッチ751件をどう見極めるかでも整理しています。
現場目線の課題
正直なところ、管理基盤そのものの更新はいちばん後回しにされやすい仕事です。業務システムは止まると業務が止まるので優先度が上がりますが、EPMのようなツールは「今日1日更新しなくても誰も困らない」。しかも更新すればエージェント配布や既存タスクへの影響検証がついて回るため、検証環境を持たない小規模な情シスほど腰が重くなります。
加えてつらいのが、今回のCVE-2026-18129のように「設定次第で影響が変わる」タイプです。外部SQLを使っているか、S3への録画保存を構成しているか——判断材料が自社の設計にしかないため、当時の構築ベンダーに問い合わせないと分からない、ということが起こります。今回を機に、EPMのコアサーバがどこと何の通信をしているかを一枚の図にしておくと、次回以降のアドバイザリで悩む時間が確実に減ります。
情シスはどうすべきか
個別のチェックリストを長々と並べるより、公的機関の指針に沿って進めるほうが確実です。
- 脆弱性への対応体制そのものを見直すなら、IPAの中小企業の情報セキュリティ対策ガイドラインが出発点として使いやすい。まず「何を・誰が・いつまでに」を決める枠組みを借りるのが早道です。
- 管理基盤が落ちた場合の動き方は、IPAのセキュリティインシデント対応 机上演習教材で一度シミュレーションしておくと、実際に「エージェントが一斉に無応答」になった夜に判断が早くなります。
- プロセスの型は脆弱性管理とは？プロセスと情シスの進め方を、証明書検証の話が腑に落ちない場合は公開鍵基盤（PKI）とは？を先に読むと理解が早いはずです。
- 地味ですが効くのは、管理ツールの棚卸しと担当者の引き継ぎ資料の整備です。製品名が変わっても中身は同じ、という事態を防ぐのは技術ではなく記録です。
まとめ
- EPM 2024 SU6以前は更新対象。深刻度「高」の3件（最大CVSS 8.1）が修正され、修正版は2024 SU7。公表時点で悪用は未確認。
- 「Ivantiは使っていない」は要検証。旧LANDESK Management Suiteの後継であり、台帳の記載が古いままだと自社が対象だと気づけない。Neurons for MDM側はSaaSで修正済み、利用者の作業は不要。
- 管理基盤は狙われる前提で優先度を上げる。同製品では2026年3月にKEV登録の実例（CVE-2026-1603）がある。設定依存の脆弱性に備え、コアサーバの通信構成を可視化しておく。
出典
- Ivanti「August 2026 Security Update」
- NVD: CVE-2026-18129 / CVE-2026-18127 / CVE-2026-18125 / CVE-2026-1603
- Ivanti Security Advisory: Ivanti Endpoint Manager (EPM) August 2026
- SecurityWeek「Ivanti EPM Update Patches Remotely Exploitable Flaws」
- Security NEXT「『Ivanti EPM』や『Ivanti Neurons for MDM』に脆弱性 – 修正を実施」
- Ivanti「LANDESK and HEAT are Now Ivanti」（製品名変更の経緯） / Ivanti Endpoint Manager 製品ページ
