BeyondTrust Remote Supportの脆弱性CVE-2026-102764：BT26-05パッチの適用手順と侵害調査

BeyondTrustは2026年10月15日、リモートサポート製品Remote Support（旧Bomgar）の脆弱性 CVE-2026-102764 を公表しました。認証なしで装置上のファイルを操作でき、8月下旬から中国系とみられる攻撃者にゼロデイとして悪用されていたものです。この記事では、提供形態と版による影響判定、/appliance画面でのBT26-05-RSパッチの確認と適用、Mandiantが公開した手口にもとづく装置外ログの調査、再構築と資格情報の入れ替えまでを整理しました。内容は2026年10月23日時点の公開情報にもとづきます。

まとめ：26.2.3以前の自社運用RSは/applianceでBT26-05-RSを即日適用

対象はRemote Supportの26.2.3以前の全版です。SaaS版は10月9日までに修正済みで、装置への作業はありません。自社運用で自動更新を使っていない装置は、/appliance画面のUpdatesからBT26-05-RSを手動で当てます。24.3.1より古い版は、先にサポート中の版へ上げます。

パッチを当てても、それ以前に入り込まれた痕跡は消えません。8月下旬以降にインターネットから届く状態だった装置は、調査が済むまで侵害の可能性ありとして扱い、装置の外に送ったログで確かめます。リモートアクセス機器を含む入口の露出と版をまとめて点検したい場合は、脆弱性診断・セキュリティ診断で棚卸しすると抜けが出にくくなります。

CVE-2026-102764の中身：内部メッセージの送信元検証不備とファイル操作

Remote Supportは、ヘルプデスクの担当者が端末へ接続して操作を代行する製品で、接続先の一覧とそこへ入る資格情報を装置が預かっています。

CWE-290とCVSS 9.3・9.8の内訳、KEV名称「認証回避」との違い

BeyondTrustのアドバイザリBT26-05によれば、Remote Supportの内部メッセージ部品が、受け取ったメッセージの送信元を十分に検証していませんでした。条件がそろうと、遠隔の攻撃者が装置上でファイル操作を行えます。技術的な詳細は、自社運用の装置のパッチ適用が進むまで非公開とされています。

深刻度は、開発元が付けたCVSS 4.0の基本値が9.3、NVDが付けたCVSS v3.1の基本値が9.8です。v3.1のベクトルは AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H で、ネットワーク越しに認証も利用者の操作も要りません。各指標の読み方はCVSSv3の計算式とスコアの目安で確認できます。

KEVでの名称は「Authentication Bypass by Spoofing Vulnerability」で、分類に使われたCWE-290（なりすましによる認証回避）の名前です。開発元の説明は送信元を検証しない部品経由のファイル操作で、利用者のパスワードを破る型ではありません。社内報告で「認証回避」とだけ書くと、パスワード変更で防げると誤解されます。

8月29日のゼロデイ悪用から10月16日のKEV登録までの時系列

悪用は公表の1か月半前に始まっていました。日付はBeyondTrustのブログ（10月16日更新）とCISAのアラートによります。

ブログの最終更新時点で、BeyondTrustが把握している被害は上記の2社で、8月以降の活動は見つかっていないとしています。それでも楽観はできません。MandiantとGoogle Threat Intelligence Groupの分析は攻撃者をARMORY CASTLE（旧UNC5221）と評価し、公表後に未修正の装置を広く狙う動きに備えるよう求めています。同じ攻撃者はCitrix NetScalerのゼロデイも使っており、同種の対応はNetScalerの脆弱性CVE-2026-88771の確認コマンドと侵害調査で扱った事例です。KEVの対応期限が登録から3日と短い理由はBOD 26-04の是正期限の決まり方で解説しています。

2月のCVE-2026-1731を含むKEV登録4件をJSONフィードで確かめる

同社製品のKEV入りは初めてではありません。2026年2月には、Remote SupportとPRAのOSコマンドインジェクションCVE-2026-1731（RS 25.3.1以前などが対象）が公表され、4日後に悪用の試みが観測されました。KEVはJSON形式のフィードでも配布されており、製品単位の登録履歴は標準ライブラリだけの次のPythonで一覧できます。

import json
import urllib.request

KEV_URL = ("https://www.cisa.gov/sites/default/files/feeds/"
           "known_exploited_vulnerabilities.json")

req = urllib.request.Request(KEV_URL, headers={"User-Agent": "Mozilla/5.0"})
kev = json.load(urllib.request.urlopen(req, timeout=30))

# ベンダー名で絞り込み、登録日の新しい順に並べる
rows = [v for v in kev["vulnerabilities"] if v["vendorProject"] == "BeyondTrust"]
rows.sort(key=lambda v: v["dateAdded"], reverse=True)

print("カタログ版:", kev["catalogVersion"], "／BeyondTrust件数:", len(rows))
for v in rows:
    print(v["dateAdded"], v["cveID"], "期限", v["dueDate"], v["product"])

2026年10月23日に実行した結果は、カタログ版2026.10.21で4件でした。2024年12月のCVE-2024-12356、2025年1月のCVE-2024-12686、2026年2月のCVE-2026-1731、今回のCVE-2026-102764です。2年足らずで4回目です。

影響範囲の切り分け：SaaSと自社運用、24.3.1を境にした版ごとの作業

判定に使うのは提供形態と版です。同社のPRAの扱いは、よくある質問で答えます。

SaaS版は10月9日に適用済みでも資格情報の見直しが残る理由

Remote SupportのSaaS版は、アドバイザリのとおり10月9日までに全テナントへパッチが当たっています。装置そのものへの作業は要りません。

ただしMandiantは、SaaS版でも資格情報と設定の見直しは適用対象だとしています。8月29日の被害の1件はSaaS側で起きていたためです。8月下旬から10月9日までに、管理者アカウントやJump Itemの権限に覚えのない変更が無いかを、後述のuser_changedの記録で確かめます。

自社運用で24.3.1未満なら先に版を上げる、版ごとの作業の分かれ目

自社運用（物理のB Seriesアプライアンスと仮想アプライアンス）では、現在の版で作業が分かれます。修正はBT26-05-RSという名前のパッチで、24.3.1から26.2.3までの版に向けて配布されています。

24.3.1より前の版から上げる場合、BeyondTrustのドキュメントには、Remote Support 24.2.4以降へ上げるにはBase software 7.3.0以降が要るとの記載があります。基盤ソフトウェアから順に上げる場合もあるので、基盤側の更新も含めて作業時間を長めに計画してください。版を上げても、それ以前に受けた侵害は残るとMandiantは明記しています。

/appliance画面でBT26-05-RSを確認・適用する更新手順と自動化

サイトURLの末尾に /appliance を付けた管理画面で、確認、適用、自動化の順に進めます。

Status画面での版確認とInstalled Patchesでの適用状況確認

最初に今の状態を記録します（項目名はStatusとInstalled patchesのドキュメントによる）。

1. /applianceにサインインし、Status > Basicsで「Base software version」と「Serial number」を控える。
2. 上部メニューのUpdatesを開き、ページ上部のInstalled Patchesを選ぶ。
3. Name・Version・Install Timeの列でBT26-05-RSが並んでいるかを確かめ、あればInstall Timeを装置名と一緒に記録する。

自動更新を購読している装置は、10月8日以降に自動で当たっている可能性があります。Install Timeは「いつまで脆弱だったか」の終点になり、侵害調査でログを集める期間を絞れます。

Updates画面でのパッチ確認からインストールまでの手順と接続切断の影響

未適用なら、Updatesのドキュメントの手順で当てます。

1. /appliance > Updatesで「Check for Updates」を押す。
2. 一覧に出たパッケージの「Install This Update」を押す。ダウンロードと適用は自動で進む。
3. 完了後にInstalled Patchesを開き直し、BT26-05-RSが並んだことを確かめる。

ソフトウェア更新の間、ログイン中の担当者はセッションと担当者コンソールへの接続を一時的に失います。それでも保守時間まで待つ理由にはなりません。悪用済みでKEVの期限も過ぎているため、担当者へ周知して当日中に済ませます。一覧にパッチが出てこない場合、Mandiantは「BT26-05」を記載してBeyondTrustサポートへ問い合わせるよう案内しています。

btupdate.comに届かない閉域環境で更新用キーを使う適用手順

Check for Updatesは、装置が更新サーバーのbtupdate.comへ届くことが前提です。外への通信を絞っている環境では、Updatesの画面で「Appliance Download Key」を発行し、外へ出られる端末からそのキーをbtupdate.comへ送ってパッケージを取得します。取得したファイルを「Manual Installation」で選び、「Update Software」を押せば適用は完了です。

外へ出られなくても、443番で外からの接続を受けている以上、攻撃の入口は同じです。

重大な更新を保守時間帯に自動で当てる設定と再起動を伴う更新の扱い

次回の遅れを減らすには、重大な更新の自動適用を有効にします。

1. btupdate.comへの通信を許可しておく。
2. /appliance > UpdatesのMaintenance Windowで「Automatically install critical updates during the Maintenance Window」を選ぶ。
3. 再起動やサービス停止を伴う更新も含めるなら「Include updates that require rebooting the Secure Remote Access Appliance or interrupt services」も選ぶ。
4. Saveを押す。

BeyondTrustは再起動を伴う重大更新も自動で入れるよう強く勧めています。2月のCVE-2026-1731では、更新サービスを有効にしていた装置にパッチが自動で配られ、悪用は2月9日までに未適用だった装置に限られました。自動更新の有無が被害を分けた実例です。

侵害の痕跡調査：Mandiantが示した手口と装置外ログで探す箇所

Mandiantによれば、利用者は装置のホストのファイルシステムを監査できず、痕跡のあった装置内のログも暗号化された領域にあり、攻撃者が消していました。調べられるのは装置の外に送ったログです。

SAWFLYウェブシェルからroot昇格と資格情報の抜き取りまでの6段階

Mandiantが公開した侵入後の流れです。

1. /app_84304470%2Ephp へPOST要求を送り、約11分後にWebルートへ mangoapi.php（SAWFLYウェブシェル）を置く。
2. /bin/sh を /usr/bin/dbus-authd へ複製してSUIDを付け、root権限を得る。
3. 装置付属のCLI bt-secrets で資格情報の保管庫の取り出しを試み、記録を消す。
4. 起動時に実行される post_boot.d にスクリプトを置き、sudoersのテンプレートへパスワード不要のroot権限を書き足す。
5. 奪った管理者アカウントで /login に入り、Jump Itemとチームの権限を「No Access」から「Administrator」へ上げる。
6. 遠隔操作のセッションで社内端末からファイルを持ち出し、トンネルツールBARECLAWを /uidchanarge のパスで外から使えるようにする。

4の永続化は再起動や設定の初期化でも消えません。2〜4は装置の中で起きるため利用者には見えず、外から見えるのは1と6のHTTPのパスと、5の権限変更です。調査はこの3点に絞ります。

転送済みsyslogとリバースプロキシのログをIOCで検索するコマンド

Remote Supportの装置は、/appliance > Security > Appliance AdministrationのSyslog欄で、最大3台のsyslogサーバーへログを送れます（Syslogのガイド）。前段のリバースプロキシやWAFのアクセスログにはリクエストのパスが残ります。次は転送先サーバーで、Mandiantが公開した文字列を数える例です。

# リバースプロキシ・WAFのアクセスログ：攻撃に使われたパスを数える
# （app_84304470 は URL エンコードされた %2E と通常の . の両方に当たるよう前半だけで探す）
zgrep -c -E "app_84304470|mangoapi\.php|/uidchanarge" /var/log/rs-proxy/access.log*

# 装置から転送されたsyslog：Jump Item の権限変更を抜き出す
zgrep -h "user_changed" /var/log/remote/rs/*.log* | grep "jump_item_role" | grep "Administrator"

パスとファイル名は保存場所に合わせて置き換えます。1つ目で1件でも出れば侵害を前提に次章へ進みます。0件でも安心はできません。BeyondTrustのブログは、この攻撃者が侵入先ごとに道具とインフラを入れ替えると説明しており、一致しないことは侵入が無かった証明になりません。syslogを改ざんされにくい形で外へ残す設計はLogstorageのsyslog TLS転送の設定例が参考になります（Syslog over TLSの既定はTCP 6514番）。

user_changedでJump Itemの管理者権限への昇格記録を調べる

Mandiantが公開したsyslogの例では、user_changed イベントの old_permissions:jump_item_role:default:name が「No Access」、new_permissions:jump_item_role:default:name が「Administrator」で、チームの権限にも同じ変更が入っていました。8月下旬以降のuser_changedで権限を上げたもののうち、作業記録が無いものはすべて調査対象です。Mandiantは、家庭向け回線や商用VPNのアドレスからの /login 成功、業務時間外の管理者ログイン、1つのセッションの間だけsyslogが途切れる空白も検知の観点に挙げ、最後の空白はログ改ざんの強い兆候としています。

侵害が疑われるRSの復旧判断：作り直しと資格情報の入れ替え順

痕跡が見つかった場合と、ログが無く判断できない場合は、パッチで終わりにしません。Mandiantの推奨は保全、遮断、再構築、資格情報の入れ替えの順です。

装置の証拠を保全してから境界で遮断し、掃除でなく再構築を選ぶべき条件

仮想アプライアンスは、変更や再起動の前にメモリ付きのスナップショットを取り、ディスクを書き出します。物理のB SeriesとSaaSは、BeyondTrustサポートへの保全依頼が必要です。そのうえで公開アドレスへの通信をファイアウォールで遮断します。/applianceの設定で止めないのは、調査用に設定をそのまま残すためです。

侵害が確定した装置と、ログが無く判定できない装置は、作り直す判断が妥当です。ホスト側の永続化は消えず、利用者には中を監査する手段もありません。修正済みのきれいなイメージから再展開し、新しいTLS証明書を発行して、Jump Client・Jumpoint・担当者コンソールを再展開してください。設定のバックアップは、悪用の窓より前の日付のものを戻すのが原則です。最新のバックアップを使う場合は、隔離したまま後述の資格情報と設定の見直しを済ませてから接続を戻します。保全の進め方や外部調査を頼む判断はフォレンジック調査の流れと依頼先の選び方で整理しています。

装置と連携先の資格情報を入れ替える順番と、パッチ前に変えてはいけない理由

この装置は、社内のどこへ誰が入れるかの地図と、そこへ入る鍵を同時に持っています。Mandiantが示す入れ替えの順番は次のとおりです。

1. /applianceの管理者の資格情報
2. /loginの管理者とローカルユーザー
3. APIクライアントのシークレット
4. 認証基盤との連携アカウントとSAMLの署名鍵
5. Remote Support Vaultと、連携先の資格情報（接続先のシステム側で変更）
6. SMTP・syslog・ITSM連携と、窓の期間にセッション内で入力された資格情報

入れ替えは、パッチ適用または再構築の後にだけ行います。攻撃者がまだ装置を握っている段階で変えると、新しい資格情報も相手に渡るおそれがあるためです。装置に預けたままの特権アカウントを減らす設計は、特権ID管理の仕組みと監査で問われる要件で解説しています。

パッチだけで終えてよい構成と、管理画面の公開範囲を絞るべき構成

ゼロデイの期間は自動更新でも防げなかったため、判断の軸はログです。パッチと記録の確認だけで終えてよいのは、8月下旬から適用日までのsyslogが欠けずに外へ残り、user_changedに説明のつかない権限変更が無く、プロキシのログに前述のパスが出ていない装置です。3つがそろえば、再構築や全資格情報の入れ替えまでは必要ありません。syslogを外へ送っていなかった装置は判定できないため、再構築の対象にします。

/loginと/applianceをインターネットへそのまま公開していた装置は、痕跡が無くても公開範囲を絞ります。Mandiantは、外から届くのを担当者コンソール、顧客ポータル、Jump Clientの通信だけにし、管理画面は信頼できるネットワークに限るよう勧めているため、この範囲に通信を制限してください。パッチの代わりにはなりませんが、次の欠陥で管理画面を突かれる余地を減らすための対策です。入口機器の版と露出を点検する進め方や費用の目安は脆弱性診断の進め方と外注時の判断基準にまとめています。同じ10月に悪用が公表された別の入口機器の対応はCisco Secure Email Gatewayの脆弱性CVE-2026-76519の確認コマンドと侵害調査も参考になります。

BeyondTrust RSのCVE-2026-102764対応でよくある質問と回答

CVE-2026-102764の対応で出てきやすい疑問に、公開されている一次情報の範囲で答えます。

KEVの対応期限10月19日は民間企業にも適用されますか？

直接の義務はありません。期限を定めるBOD 26-04の対象は米国の連邦文民行政機関に限られると、CISAのアラートにも明記されています。ただしCISAは、すべての組織にKEV掲載の脆弱性を優先して直すよう勧めています。公表後に攻撃が広がるとMandiantが警告している以上、未適用なら今日当ててください。

パスワードを変更すれば暫定の回避策になりますか？

回避策にはなりません。KEVの名称は「認証回避」ですが、開発元の説明では送信元を検証しない内部部品を経由したファイル操作で、利用者のパスワードを使わずに成立します。パッチ前に変えると、装置を握った攻撃者に新しい値を渡すおそれもあります。BT26-05-RSの適用と侵害の確認が先です。

Privileged Remote Access（PRA）にも対応は必要ですか？

必要です。BeyondTrustは社内試験でPRAへの悪用方法は見つかっていないとしつつ、影響のあるコードを共有しているため、PRA向けのパッチを出し、自社運用のPRAにも直ちに当てるよう勧めています。NVDの影響製品にPRAは無く、CVE単位で判定するツールでは該当なしと出ることがあるので、台帳には手で載せてください。

2月のCVE-2026-1731に対応済みなら今回は対象外ですか？

対象外にはなりません。2月の件はBT26-02で直されたOSコマンドインジェクションで、今回は別の欠陥です。影響範囲は26.2.3以前の全版なので、2月の修正を当てた装置も脆弱なままです。Installed PatchesでBT26-05-RSを別途確かめてください。

JPCERT/CCの注意喚起は出ていますか？

2026年10月23日時点で、JPCERT/CCの注意喚起一覧（10月22日更新）に本件はありません。国内の注意喚起の有無で優先度を決めるのは適切ではありません。CISAがKEVに登録して期限を3日と定めたこと、カナダのサイバーセキュリティセンターがアラートAL26-025を出したことのほうが判断の根拠になります。

関連記事

• 脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務を解説：公表から修正までの流れの基礎です。
• CVE（共通脆弱性識別子）とは？仕組み・CVSS/CWE/NVDとの違いと2026年の運営体制変化：CVEとCWE・NVDの関係を整理しています。
• VPN 脆弱性：機器の版確認コマンドとKEV照合スクリプト・パッチと移行の判断【2026年10月】：入口機器の版をKEVと照合する例です。
• 特権ID管理ツール比較：ゲートウェイ型とクライアント型の違い・料金・選び方：装置に資格情報を預けない構成の比較軸です。
• CTEMとは？脆弱性管理との違い・5つの段階と企業の導入判断を解説：露出を継続的に管理する運用の考え方です。