速報

X.Orgのクライアントライブラリーで17件を修正!Linux端末と画像処理の利用範囲を点検

CATEGORY

Ivanti Connect Secureで脆弱性の連鎖悪用を確認!更新と認証基盤の調査を分けて進める

※本ページのリンクにはプロモーションが含まれています。

VPN装置から認証基盤へ向かう不正な接続と装置外で確認する調査記録を表す紫色背景のフラットな概念イラスト

この記事のポイント

脆弱性
CVE-2026-104935
深刻度

HIGH8.6

対象
Ivanti Connect Secure
悪用状況
確認済み
推奨対応
対象のソフトウェア系統と機種に適合する公式更新を保守窓口で確認して適用する。公的資料の修正版は22.8R2.5、25.1.1.2、25.1.3.0または25.1.3.1。外部公開履歴と認証基盤への到達・権限を調査し、証拠保全と認証情報の更新を担当者と判断する。権限昇格の最新修正状況は別途確認。ICT正常だけで侵害を否定しない。
公表日

目次

カナダのサイバーセキュリティセンターは2026年10月16日、Ivanti製品の注意喚起を更新し、CVE-2026-111357が実際の攻撃で悪用されているとの公開報告を追記しました。同じ注意喚起は、Connect SecureのCVE-2026-104935が10月13日にCISAの悪用確認済み脆弱性カタログへ追加されたことも示しています。VPN装置の更新を確認するだけでなく、そこから接続できた認証基盤まで調査範囲を考える必要があるニュースです。出典:カナダ・サイバーセキュリティセンター:AV26-1035 Update 1。

本記事の情報確認日は2026年10月18日です。10月18日に新しい攻撃が発生したという報道ではありません。公的機関の10月16日更新と、10月13日に公表された調査報告を扱います。確認できた事実、時点が限られる情報、本サイトが提案する運用手順を分けて説明します。国内の被害件数や自社環境の侵害を推定する記事ではありません。

スポンサーリンク

今回の更新で押さえたい二つの脆弱性

CVE-2026-104935について、フィンランドの国家サイバーセキュリティセンターは、認証を回避して遠隔からコマンドを実行でき、攻撃者のアカウントや利用者の操作を必要としないと説明しています。CVSS v3.1は8.6です。通常のVPNログインを突破するためのパスワードを持たなくても、入口の処理が攻撃対象になる点が重要です。出典:フィンランドNCSC:Ivanti Connect Secureの悪用された脆弱性。

Volexityは10月13日、当時最新の22.8R2.4への連鎖悪用を報告しました。活動を確認したのは10月3日から、調査開始は5日です。「公表前から更新を続けていた」という事実だけでは、この事例の侵入可能性を否定できません。出典:Volexity:Connect Secureのゼロデイ連鎖を調査した報告。

10月16日の追記が挙げるCVE-2026-111357と、入口のCVE-2026-104935は、別の識別子として扱います。一方の修正状況を見て他方まで解決済みと判断したり、別のCVEを一つのスコアで評価したりしないでください。更新一覧、悪用の確認、侵害の有無はそれぞれ異なる確認事項です。

影響する版はソフトウェアの系統ごとに確かめる

フィンランドNCSCが示すCVE-2026-104935の対象は、22.8系の22.8R2.4以前、25.1.1系の25.1.1.1以前、25.1.2系の25.1.2.2以前です。同資料は修正版として22.8R2.5、25.1.1.2、25.1.3.0または25.1.3.1を案内しています。22.7R2.14以前の22.7系はこの脆弱性の対象外と説明しています。出典:フィンランドNCSC:対象バージョンと修正版の案内。

これはすべての装置へ同じファイルを入れればよい、という意味ではありません。本サイトの提案は、製品名、機種、現在の系統、稼働中のビルド、冗長構成の各装置を一行ずつ記録し、保守窓口に適合する更新経路を確認することです。数字の大小だけを比較する自作判定は避けます。

メーカーの勧告ページは今回の確認では読み取れなかったため、そのページの最新の機種別手順を直接確認したとは扱いません。上記の版は実際に開いた公的資料による案内です。適用前には契約上の保守窓口で現在の公式手順と追加更新を確認してください。古い系統が本CVEの対象外でも、ほかの問題や保守期限まで安全だと保証されるわけではありません。

スポンサーリンク

修正がある部分と確認が残る部分を分ける

Volexityの10月13日報告は、入口の修正を案内する一方、連鎖に使われた権限昇格の修正を今後の予定としています。これはその報告時点の情報です。本記事では、10月18日時点でも権限昇格の修正が未提供だと断定せず、最新状況を保守窓口へ確認する項目として残します。出典:Volexity:修正の対象と報告時点の残る課題。

対応票では「入口の修正」「関連する権限昇格の確認」「過去の侵害調査」を別々に管理することを提案します。たとえば入口の修正を完了としながら、関連更新の追跡には担当者と次回確認時刻を残します。更新が一つ成功したため、調査や追加勧告の追跡まで自動的に閉じる運用を防げます。

一方で、残る確認事項があるからといって、提供済みの入口の修正を先延ばしにする理由にもなりません。業務影響、証拠保全、外部への露出を同時に判断し、できる防御を進めます。停止が必要な場合は、業務継続のための代替経路が別の未管理の入口にならないことも確認してください。

Web運営への影響はVPNの先にある

以下は説明用の仮想例です。Web制作会社が、社内のVPNを経由して顧客の検証環境へ接続し、共通のディレクトリで担当者を認証しているとします。公開サイトのWordPressやWebサーバーが更新済みでも、VPN装置が参照するアカウントや到達先によって、調べる範囲が広がる可能性があります。

Volexityは、認証情報の窃取と、Active Directory内のLAPSパスワードやBitLocker回復情報などの探索を報告しています。報告された探索と、すべての情報を実際に取得できたことは同じではありません。自環境ではその装置のサービスアカウントに何を読める権限があったかを調べる理由になります。出典:Volexity:侵入後の認証情報とディレクトリへの活動。

本サイトの提案として、接続関係を「VPNだから社内全体」と一括りにしないでください。VPNから到達できるサーバー、認証用アカウントの参照範囲、そのアカウントを共有する別サービスを分けて列挙します。権限の付与理由と実際の設定を照合し、不要な参照権限や広すぎる通信許可を修正候補にします。

委託先が装置を運用している場合は、利用有無、対象装置、外部公開期間、対応責任者、修正の確認資料を依頼します。「対策済み」という回答だけでは、更新を済ませたのか、過去の侵害も調べたのか分かりません。業務に必要な範囲で、対応の種類と未確認事項を区別して説明してもらいます。

スポンサーリンク

最初に露出と証拠を確保しながら入口を閉じる

以下は本サイトが提案する実施順序です。個別環境の復旧指示や専門家の判断を置き換えるものではありません。脆弱な状態で外部へ公開されていた期間を確認し、不審な挙動がある場合は、保守担当とインシデント対応担当を同じ連絡系統に入れてください。

  • 対象を特定する:現行版だけでなく過去の更新履歴、公開開始・終了時刻、待機系の状態も記録する。
  • 緊急対応を決める:許可された接続元への制限やサービス停止が必要か、業務責任者と判断する。これらを修正の代替だとみなさない。
  • 証拠を保全する:外部に保存したログ、設定の履歴、調査可能な期間を確保し、装置内の採取は保守窓口や専門担当の方法に従う。
  • 適合する更新を適用する:事前に承認した対象と更新経路で実施し、再起動後の稼働版を各装置で確認する。

証拠採取を待つ間も入口が公開されたままなら、その時間にもリスクが続きます。反対に、確認せず再起動や初期化をすると、一部の調査材料を失う可能性があります。どちらを先に行うかは状況次第なので、判断者、判断時刻、保全できたものを残し、危険な公開状態を放置しない形で進めます。

ログが静かでも調査を終えない

Volexityは、ログ削除やメモリー上の変更を報告し、この手法はIntegrity Checker Toolで検出できないと説明しています。正常という結果やWebシェルが見つからないことだけで、過去の侵害を否定できるとは限りません。出典:Volexity:痕跡を残しにくい活動と調査上の限界。

運用上は、装置の記録に加えて、外部ファイアウォールの通信記録、認証基盤の監査記録、管理作業の申請履歴を時間軸で合わせることを提案します。たとえばVPN装置から、通常は使わない宛先への通信があった場合、保守作業や障害対応によるものかを先に照合します。珍しい通信だけで攻撃とは確定しません。

確認結果には、何を何日分調べたかと、何を調べられなかったかを書きます。外部ログを保存していなかった期間を「異常なし」に含めないでください。時刻のずれ、タイムゾーン、保存期間の違いも整理すると、記録がない理由と攻撃がなかったという結論を混同しにくくなります。

認証情報の交換は復旧の状態と順序を合わせる

認証情報を変える際は、秘密の値を扱う装置や管理端末が信頼できる状態かを確認します。以下は本サイトの対処案です。侵害の疑いが残る装置へ新しい秘密を先に登録してしまうと、その新しい値の安全性も説明できなくなります。必要な隔離と復旧を進めながら、交換対象と実施順序を決めます。

一覧に残すのはパスワードそのものではなく、アカウントの用途、所有者、参照先、共有の有無、失効方法です。LDAP用アカウント、装置管理者、ほかのシステムと共有した認証情報を分け、変更後に旧資格情報で認証できないことと、正規のサービスが動くことを確認します。セッションや連携トークンの失効が必要かも別項目として判断します。

ディレクトリ内の秘密情報については、「探索された可能性」と「読める権限があったこと」と「取得された証拠」を分けます。調査結果に応じて端末側の資格情報や回復情報まで対応範囲を広げる場合がありますが、対象も順序も決めずに全組織で一斉変更すると復旧を難しくします。認証基盤の管理者と影響範囲を詰めてください。

更新の成功と業務再開の条件を別々に検証する

完了の確認は、VPNへ接続できることだけでは足りません。本サイトの提案は、変更対象の装置が意図した版で動作していること、許可された利用者だけが必要な宛先へ到達できること、ログの転送が続くことを個別に確かめる方法です。通常利用、許可されない接続、監視の三方向から検証します。

結果には、修正済みのCVE、追加確認が残る問題、調査対象期間、認証情報の扱い、再開を承認した人を残します。未確認の項目には担当と期限を付けます。今回のニュースを受けた対応は、更新ボタンの操作ではなく、外部の入口とその先の権限を説明できる状態まで進めることが目標です。

出典・一次情報

本記事は以下の公開情報をもとに作成しています。最新の状況は各リンク先で確認してください。

この記事を書いた人

Ryohei

Webエンジニア / アプリ開発者 / 技術ブログ運営者

福岡のWeb制作会社に勤務するWebエンジニアです。10年以上にわたりWeb制作・開発に携わり、これまでに100以上のWordPressサイトの構築・保守を担当してきました。Webサイト制作に加え、アプリ開発やAIを活用した開発にも取り組み、近年はWebセキュリティにも注力しています。

2015年から技術メディア「Into the Program」を運営し、実務や開発で得た知識をもとに、プログラミングの実装方法やWebサイトの運用・セキュリティ情報を発信しています。

主な分野
WordPress / PHP / JavaScript / アプリ開発 / Webサイトの運用・セキュリティ対策
資格・試験合格
情報セキュリティマネジメント試験
基本情報技術者試験
AWS認定ソリューションアーキテクト アソシエイト
メディア運営
2015年〜

記事の作成・更新について

セキュリティ記事は、ベンダーの公式アドバイザリやCVE・JVNなどの一次情報を参照し、出典と情報確認日を記載します。実環境での検証を行った場合は、その環境と確認範囲を明示します。重要な追加情報や誤りを把握した場合は、内容を確認して追記・訂正します。

スポンサーリンク

関連する記事

おすすめの書籍