Ivanti SentryにCVSS10.0の認証不要RCE｜PoC公開から1日で悪用開始—R10.5.2/R10.6.2/R10.7.1へ即時更新を

結論：パッチ公開から悪用開始まで実質1日。「今日適用」と「管理者アカウント精査」を同時に進める

モバイル端末と社内メール・社内システムを中継するゲートウェイ製品 Ivanti Sentry に、認証不要でroot権限のリモートコード実行に至るOSコマンドインジェクション（CVE-2026-10520・CVSS 10.0） と、認証不要で管理者アカウントを作成できる認証バイパス（CVE-2026-10523・CVSS 9.9） が公表された。修正版は R10.5.2／R10.6.2／R10.7.1 だ。

深刻なのは時間軸である。6月9日のアドバイザリ公開後、6月10日にセキュリティ企業watchTowrが技術解析と検証ツールを公開し、その翌日の6月11日にはShadowserver Foundationが悪用試行を観測。観測できた脆弱なインスタンス19台のうち少なくとも2台にバックドアの設置が確認されたと報じられている。PoC公開から悪用開始まで実質1日——「来週の定例メンテで」という判断が成立しない速度だ。

押さえるべき1点：CVE-2026-10523は「管理者アカウントを作られる」脆弱性である。パッチを当てても、適用前に作られた不正な管理者アカウントは残る。更新と同時にアカウントの棚卸しまでやって初めて対応完了だ。

2つの脆弱性と対象バージョン

経過は次のとおりだ。

• 6月9日：Ivantiがアドバイザリ公開。この時点で悪用は未確認
• 6月10日：watchTowrが原因箇所（認証不要で到達できるAPIエンドポイント）の解析と検知用ツールを公開
• 6月11日：Shadowserverが悪用試行を観測。脆弱な19台中少なくとも2台でバックドアを確認、「まだパッチを当てていないなら侵害済みの可能性が高い」と警告（二次情報）

なぜ「誰も管理していない箱」が一番危ないのか

Sentryは、スマートフォンから社内メールや社内システムへのアクセスを中継するためにインターネット側に公開されていることが多い。つまり攻撃者から直接見える位置にあり、認証不要のRCEとは相性が最悪の組み合わせだ。しかも「スマホで社内メールを見られるようにする」目的で数年前に導入され、導入したベンダーや担当者が変わって誰もバージョンを把握していない——という運用が起きやすい製品でもある。

今週はCheck Point VPNの認証バイパス悪用（解説記事）も継続中で、狙われているのは一貫して「外部公開された境界機器」だ。自社にどんな公開資産が残っているかを把握できていないなら、ASM（アタックサーフェス管理）による外部公開資産の棚卸しを併せて検討してほしい。

今日やる4手順

1. 利用有無の確認：Sentry（旧MobileIron Sentry）が社内に存在するか。スマホから社内メールを見られる仕組みがあるなら、導入ベンダーに「Sentryを使っているか・バージョンは何か」を即日確認する
2. 修正版の適用：対象バージョンなら定例を待たずR10.5.2／R10.6.2／R10.7.1へ更新する
3. 管理者アカウントの棚卸し：身に覚えのない管理者アカウントがないかを精査する。CVE-2026-10523で作られたアカウントはパッチ後も残存する
4. 侵害調査：6月10日以降のアクセスログを精査し、不審な接続元やAPI呼び出し、設定変更の痕跡を確認する。痕跡があれば封じ込めへ移行する

チェックの勘所：手順1で「分からない」が一番危ない。把握していない＝管理されていない＝パッチも当たっていない、である。MDM・モバイルゲートウェイ周りはMDM/BYOD管理の全体像も参考に、構成の可視化から着手すべきだ。

よくある質問（FAQ）

Q. Sentryを使っているかどうか分からない。何から確認すればよいか？ A. 「社用スマホ・私物スマホから社内メールを見られる仕組みがあるか」が出発点だ。あるなら、その中継経路にSentryがいる可能性がある。導入時のベンダー・SIerに製品名とバージョン、本脆弱性への該当有無を書面で確認すること。

Q. パッチを当てれば対応完了か？ A. 不十分である。悪用が既に始まっており、適用前に侵入されていれば不正な管理者アカウントやバックドアが残る。管理者アカウントの棚卸しと6月10日以降のログ精査までが対応範囲だ。

Q. すぐに更新できない場合は？ A. 認証不要で攻撃できるため、外部からの到達性を絞ることが最優先となる。アクセス元制限などの暫定緩和を施しつつ、更新を「計画」ではなく期限付きの「実行」として進めるべきだ。

社内で今日確認する実務チェック

この記事のテーマを自社に当てはめるときは、次の順で確認する。第一に、対象製品・対象バージョン・対象サービスが資産台帳に載っているか。第二に、インターネットや不要な社内セグメントから到達できないか。第三に、更新・緩和・監視の担当者と期限が明確か。第四に、委託先やクラウド運用先が関係する場合、回答を口頭ではなくチケットやメールで記録しているか。第五に、対応後にバージョン・設定・ログで完了を確認したかである。

脆弱性対応で最も危険なのは、「使っているか分からない」「担当が分からない」「ベンダーに任せているはず」という状態だ。今回の記事を読んだ時点で対象有無を即答できないなら、それ自体が改善テーマである。個別のパッチ適用だけでなく、資産台帳、脆弱性通知の受信経路、緊急対応の承認権限まで点検したい。

GXOへ相談する前に整理しておくと早い情報

相談前には、対象製品名、バージョン、設置場所、外部公開の有無、管理者、保守契約、更新可能な時間帯、過去の障害履歴を分かる範囲でまとめる。すべて揃っていなくてもよいが、「分からない項目」が多いほど、最初の支援はパッチ作業ではなく棚卸しと露出確認から始めるべきである。

30日で整える脆弱性対応ロードマップ

初日から3日目までは、対象有無の確認と暫定緩和に集中する。資産台帳、EDR/MDM、クラウド管理画面、保守ベンダーへの照会を使って、対象製品がどこにあるかを洗い出す。対象が見つかった場合は、外部公開の停止、アクセス制限、管理画面のIP制限、監視強化など、更新前にできる緩和策を先に入れる。

4日目から10日目までは、更新・設定変更・影響確認を進める。業務影響が大きい製品では、検証環境で更新手順を確認し、失敗時の切り戻し手順を用意する。更新後はバージョン表示だけでなく、実際に脆弱な経路が閉じているか、ログに不審なアクセスが残っていないかを確認する。

11日目から30日目までは、再発防止に使う。通知を誰が受けるか、KEVやJPCERT/CCなどの情報をどう優先度付けするか、休日・夜間の緊急判断を誰が承認するかを決める。今回のような高リスク通知に対して、次回は「対象有無を24時間以内に答えられる」状態を目標にする。

よくある失敗パターン

第一の失敗は、CVE番号やCVSSだけを見て、対象資産の有無を確認しないことだ。スコアが高くても自社に対象がなければ対応は不要であり、逆にスコアが中程度でもKEV登録や悪用確認があれば最優先になる。優先順位は、CVSS、悪用状況、外部公開、権限条件、業務影響を組み合わせて決める。

第二の失敗は、更新完了を「ベンダーに依頼した」で止めることだ。更新後のバージョン確認、到達制限、ログ確認、再起動状態、冗長系への反映まで確認しなければ完了とは言えない。特にアプライアンスや管理基盤では、片系だけ更新されてもう片系が古いまま残ることがある。

第三の失敗は、今回だけの緊急対応で終わることだ。脆弱性情報は毎月出る。対応のたびに担当者探しから始まる組織は、次回も同じ遅れを繰り返す。今回の対応記録を使い、対象確認テンプレート、判断フロー、連絡先一覧、夜間休日の承認ルールまで更新することが重要である。

成果物として残すべきもの

公開記事を読んで終わらせず、社内には少なくとも4つの成果物を残したい。対象有無確認表、対応判断メモ、更新・緩和作業の証跡、再発防止タスクである。これらが残っていれば、監査や事故後説明でも「いつ、誰が、何を根拠に判断したか」を示せる。

また、委託先が関係する場合は、委託先回答をそのまま保存するだけでなく、自社として受け入れた判断も記録する。セキュリティ運用では、作業を委託できても説明責任は委託できない。

判断表：読むだけで終わらせないための整理

この表を埋めると、記事の内容を「読んだ情報」から「社内で動かすタスク」に変えられる。特に重要なのはNGサインである。NGサインが1つでも出る場合、問題は個別ニュースではなく、社内の判断プロセスにある。

公開情報は日々更新されるため、記事本文の数値や期限をそのまま固定値として扱うのではなく、一次情報の最新版、社内の対象有無、実施記録をセットで確認する。これにより、速報記事を一過性の話題で終わらせず、監査・稟議・改善計画に使える材料へ変換できる。

いつGXOに相談すべきか

• 外部公開している機器の棚卸しができておらず、Sentryの有無・バージョンを即答できない
• パッチは当てたが、不正アカウントや侵害痕跡を精査する技術力が社内にない
• 境界機器の脆弱性対応が毎回後手に回っており、パッチ適用のSLAを含む運用体制を作りたい

GXOは脆弱性診断による外部公開資産の棚卸しと露出評価、セキュリティ顧問によるパッチ運用体制の構築、インシデント対応支援による侵害調査・封じ込めを提供している。→ Sentry脆弱性対応の相談はこちら

関連記事

• Check Point VPNに認証バイパス、悪用継続中
• ASM（アタックサーフェス管理）中堅企業向け導入ガイド
• MDM/BYOD管理ガイド｜Intune・Jamf・CLOMO比較
• Windows月例パッチ史上最多200件｜BitLocker迂回ゼロデイ2件

編集部注：公開後の更新方針

本記事は速報性のある公開情報をもとに、GXOの商談領域であるシステム開発、AI導入、セキュリティ、レガシー刷新、データ基盤構築の観点へ翻訳したものである。公開後に一次情報の更新、ベンダー側の追記、制度要件の変更、悪用状況の変化が確認された場合は、本文・参考資料・CTAの導線を更新する。

読者が実務で使う場合は、記事の数値や期限を固定値として扱うのではなく、必ず一次情報と自社環境を突き合わせることが重要である。特に、契約条件、対象バージョン、制度要件、提供リージョン、価格、悪用状況は短期間で変わり得る。この記事の役割は、最新情報を自社の判断項目へ変換することであり、最終判断は一次情報と社内の対象有無確認にもとづいて行う。

参考資料

• Ivanti「Security Advisory Ivanti Sentry (CVE-2026-10520, CVE-2026-10523)」
• watchTowr Labs「Ivanti Sentry Pre-Auth OS Command Injection (CVE-2026-10520)」
• Rapid7「ETR: CVE-2026-10520, CVE-2026-10523 - Multiple critical vulnerabilities affecting Ivanti Sentry」（二次情報）
• Help Net Security「Critical Ivanti Sentry flaw allows root-level remote code execution」（二次情報・Shadowserver観測の報道）
• Security NEXT「Ivanti Sentryに深刻な脆弱性」（二次情報）

本記事は2026年6月12日時点の公開情報をもとに作成。悪用観測・バックドア確認数はShadowserverの観測に基づく報道時点の値であり、今後増える可能性がある。対象バージョン・修正状況はIvantiの一次情報の最新版を必ず確認すること。