Check Point の脆弱性 CVE-2026-123039 の影響確認と対処手順
Jumbo Hotfix 適用と侵害痕跡の確認
Check Point の CVE-2026-123039（DynamicCLI の root 権限昇格、CVSS 7.8）は数十社で悪用され CISA KEV に追加された。影響版、修正 Jumbo Hotfix の Take、確認コマンド、一時的な緩和策、侵害痕跡の調べ方、委託先への確認事項まで整理する。
CVE-2026-123039 は、Check Point の Gaia OS にある DynamicCLI の脆弱性で、root で動く dynamic_server デーモンが、誰でも書き込める /tmp/dynamic_socket で待ち受け、接続してきたプロセスを認証しないため、ローカルの低権限ユーザーが root 権限でコマンドを実行できる（CVSS 7.8）。Check Point は数十社の顧客で悪用を確認しており、CISA の KEV カタログにも 2026 年 11 月 13 日に追加された。 Check Point のファイアウォールや管理サーバを使っている会社は、バージョンと Jumbo Hotfix の Take を確認し、対象なら修正版を適用して、あわせて侵害の痕跡を調べる必要がある。
本記事は、Check Point 公式の sk1000362、CISA の KEV 追加アラート、BleepingComputer の報道をもとに、影響範囲、確認手順、環境別の対処、パッチを当てられない間の緩和策、侵害痕跡の確認方法を整理したものである。数値と日付は一次情報で確認できたものに限り、公表されていない点はそう書く。
3行でわかる要点
- 何が: Gaia の dynamic_server が、全ユーザーが書ける /tmp/dynamic_socket で接続元を認証せずに待ち受けており、ローカルの低権限プロセスから root でコマンドが実行できる。CVSS 7.8。Check Point は数十社への悪用を確認し、CISA が 2026 年 11 月 13 日に KEV へ追加した
- 誰が: R82.20／R82.10／R82／R81.20／R81.10／R81 の Check Point Force Firewalls、管理・ログサーバ、Multi-Domain Security Management／Log Server、Maestro Orchestrator。Spark Firewalls と Smart-1 Cloud は対象外
- 何をする: Jumbo Hotfix Accumulator を R82.20 は Take 14 以降、R82.10 は Take 52 以降、R82 は Take 132 以降、R81.20 は Take 174 以降へ更新する。更新できない間は dynamic_server の停止で緩和し、/var/log/dynamicCli.log で侵害痕跡を確認する
影響範囲の早見表
sk1000362 に記載された影響バージョンと、修正が入った Jumbo Hotfix Accumulator の Take を並べる。自分の環境の Take が表の数字以上であれば修正済みである。
| バージョン | 状態 | 修正済みの Take |
|---|---|---|
| R82.20 | 影響あり | Take 14 以降 |
| R82.10 | 影響あり | Take 52 以降 |
| R82 | 影響あり | Take 132 以降 |
| R81.20 | 影響あり | Take 174 以降 |
| R81.10 | 影響あり・EOS（サポート終了） | 記載なし |
| R81 | 影響あり・EOS（サポート終了） | 記載なし |
影響を受ける製品は、Force Firewalls、Management and Log Servers、Multi-Domain Security Management と Multi-Domain Log Server、Maestro Orchestrator である。影響を受けない製品として、Spark Firewalls と Smart-1 Cloud が挙げられている。
何が起きているのか
dynamic_server と /tmp/dynamic_socket
Gaia は Check Point 製品が動く専用の OS で、その中の DynamicCLI という仕組みが、ほかのプロセスからの設定コマンドを受け付ける。受け付け役が root 権限で動く dynamic_server というデーモンで、窓口として /tmp/dynamic_socket というローカルのソケット（プロセス同士が通信するためのファイル状の入口）を使う。
問題は、この窓口が全ユーザーに書き込める権限（脆弱な状態では srwxrwxrwx、すなわち 0777）で作られ、しかも接続してきたプロセスが誰なのかを確認しないことである。つまり、機器の中で低い権限のプロセスを動かせる人は、このソケットにコマンドを書き込むだけで、root としてそのコマンドを実行させられる。弱点の種類としては、CISA の KEV 上の名称が「Incorrect Permission Assignment for Critical Resource」（重要なリソースへの不適切な権限付与）となっている。
ローカル権限昇格なのに危険な理由
「ローカル」と聞くと、機器の前に座った人だけの話に思えるかもしれない。しかし実際には、攻撃者が別の脆弱性やなりすましで、機器の上で低い権限のコードを動かすことに成功した場合の、次の一手として働く。入口は別にあり、この脆弱性は、入った後に root へ上げる役を担う。
BleepingComputer の報道によれば、攻撃は 10 月下旬から確認されており、攻撃者はまず Mobile Access ポータルへ侵入し（報道では PHP2Shell と呼ばれる脆弱性を利用）、次に本脆弱性で root を取り、Web シェルを置いたうえで、TSGA バックドアと TSProxy マルウェアを設置したとされる。その後、ゲートウェイから VMware ESXi のホストへ横展開し、破壊型のワイパー（データを消去するマルウェア）を展開した。root を取られたゲートウェイは、中の通信や認証情報にも触れられる立場になるため、単体の脆弱性として軽く見ないほうがよい。
Check Point は、数十社（a couple of dozen）の顧客に対する悪用を確認していると述べている。個別の被害組織や、被害の詳細な内訳は公表されていない。
自分が影響を受けるかの確認手順
確認は 3 段階で行う。まず Gaia のバージョンと Jumbo Hotfix の Take を調べ、次に dynamic_server の稼働状況を見て、最後にソケットの権限で修正済みかどうかを判断する。以下のコマンドは Expert mode のシェルで実行する。
# 1. Gaia のバージョンと、入っている Jumbo Hotfix の Take を確認する（Expert mode）
cpinfo -y all
# （clish でも版数は確認できる）
show version all
# 2. dynamic_server が動いているか
ps auxw | grep -v grep | grep 'dynamic_server'
# 3. ソケットの権限を見る
# 修正済み: srw-rw---- root config（0660）／脆弱: srwxrwxrwx（0777）
ls -l /tmp/dynamic_socketバージョンと Take は、cpinfo -y all の出力に含まれる Jumbo Hotfix Accumulator の項目で確認できる。表示の見え方は環境によって異なるため、迷う場合は Gaia ポータルの更新画面（CPUSE）で、適用済みの更新を見るほうが確実である。表の Take 未満であれば、更新が必要である。
ソケットの権限は、修正後は srw-rw---- root config（0660）となり、特定のグループ以外は書き込めなくなる。srwxrwxrwx（0777）のままであれば、修正が入っていない状態である。また、修正後は、権限のないユーザーからの接続が拒否され、その記録がログに残る。次のコマンドで確認でき、UID 99（nobody）などの接続拒否が出ていれば、修正後に権限昇格の試みがブロックされたことを示す。
# 修正後にブロックされた権限昇格の試行（UID 99 = nobody など）
grep "Rejected connection from unauthorized uid" /var/log/dynamicCli.logこのログが出ていた場合は、その時刻の前後にポータル、Web、認証のログで何があったかを突き合わせる。攻撃が失敗した記録であっても、機器の上で低権限のコードが動いた、つまり別の侵入口が存在した可能性を示すためである。
環境別の対処
R82.x（R82.20／R82.10／R82）の場合
Jumbo Hotfix Accumulator を、R82.20 は Take 14 以降、R82.10 は Take 52 以降、R82 は Take 132 以降へ更新する。更新は通常のメンテナンス手順と同じで、Gaia ポータルの CPUSE から行う。クラスタ構成では、片系ずつ順番に更新し、切り替えを確認してから次へ進める。更新後は、前章のソケット権限（0660）を確認する。
R81.20 の場合
Jumbo Hotfix Accumulator を Take 174 以降へ更新する。手順は R82.x と同様である。R81.20 を使い続けている場合でも、修正は提供されている。更新後にソケット権限と、更新前のログの痕跡確認を行う。
R81.10／R81（EOS）の場合
sk1000362 では、この 2 つのバージョンは EOS（サポート終了）とされ、修正の Take は記載されていない。この場合の現実的な選択は、サポートされているバージョン（R81.20 以降）へのアップグレードを計画することである。計画ができるまでの間は、後述の dynamic_server の停止による緩和策を実施し、侵害の痕跡を確認する。外部へ公開しているゲートウェイは優先度を上げる。
Multi-Domain／Maestro の場合
Multi-Domain Security Management、Multi-Domain Log Server、Maestro Orchestrator も影響を受ける製品に含まれている。Multi-Domain では複数のドメインを 1 台で管理しているため、1 台が root を取られた場合の影響範囲が広くなる点に注意する。適用する Take は、上の表のバージョン別の番号に従う。Maestro は構成要素ごとに更新が必要になることがあるため、手順は sk1000362 と Check Point のドキュメントで確認する。
運用を業者に委託している場合
保守・運用を委託している会社は、委託先に次の 3 点を、メールなどの記録が残る形で確認するとよい。①自社の機器の製品・バージョン・Jumbo Hotfix の Take、②適用の予定日（すでに適用済みならその日付）、③dynamicCli.log の痕跡確認の結果。委託先が確認中であっても、結果が出るまでの間に dynamic_server の停止を依頼するかどうかは、自社の運用への影響とあわせて判断する。
パッチを当てられない間の緩和策
Check Point は、Jumbo Hotfix をすぐに適用できない場合の一時的な措置として、dynamic_server プロセスを停止し、再起動しないように設定する方法を示している。コマンドは dbset を使い、最後に dbset :save で保存する。ただし、停止する際に指定する値は sk1000362 の記載を確認して実行すること（本記事では値を断定しない）。
# dynamic_server を停止し、再起動しないようにする（Expert mode）
# 設定する値は sk1000362 に記載の手順で確認すること（本記事では値を断定しない）
dbset process:dynamic_server <sk1000362 記載の値>
dbset :save
# 元に戻す場合
dbset process:dynamic_server t
dbset :save副作用として、sk144112 に記載されている Dynamic CLI のコマンドが失敗するようになる。それらのコマンドを自動化や運用で使っていないかを、先に確認する。元に戻すときは、dbset process:dynamic_server t のあとに dbset :save を実行する。この緩和策は、パッチの代わりにはならない。すでに侵入されていた場合の痕跡を消すものでもないため、次章の確認は必ず行う。
あわせて、一般的な対策として、管理画面や Mobile Access ポータルなどを、不要なインターネット側へ公開していないかを見直す。報道された攻撃は、公開されたポータルが最初の入口になったと伝えられている。公開が必要な場合も、接続元の制限や、ログの監視を強めておく。
侵害痕跡の確認と、痕跡があった場合の対応
悪用は 10 月下旬から確認されていると報じられているため、パッチを当てたあとでも、更新前にすでに侵入されていなかったかを確認する。Check Point は、/var/log/dynamicCli.log に残る痕跡を調べる 3 種類の検索を示している。
# 1. Clish ラッパーを通っていないコマンド
grep "Received =" /var/log/dynamicCli.log \
| grep -vF "CPprofile.sh >> /dev/null; export SP_DISTRIBUTE=0; set -o noglob;"
# 2. 通常の通信ではまれな system() 経由の実行
grep -F "Received = #return_value#" /var/log/dynamicCli.log
# 3. 攻撃で使われやすいコマンドの痕跡
grep -EI "Received =.*( id;| whoami| /etc/shadow| ncat| nc -| /dev/tcp| curl | wget | base64| useradd| authorized_keys)" \
/var/log/dynamicCli.log1 つ目は、正規の操作で通る Clish のラッパーを経由していないコマンドである。2 つ目は、通常の通信ではまれな system() 経由の実行で、3 つ目は、id、whoami、/etc/shadow、nc、curl、wget、base64、useradd、authorized_keys など、攻撃でよく使われるコマンドの痕跡である。Check Point は、いずれかに該当した場合、ソケットを通じた root でのコマンド実行の可能性として調査するよう求めている。なお、検索に引っかかるものがすべて攻撃とは限らないため、時刻、前後のログ、実行した人の作業記録と突き合わせて判断する。
痕跡が見つかった場合は、次の順で対応する。
- 隔離: 該当の機器を、可能な範囲でネットワークから切り離す、または通信を制限する。ただし、調査に必要なログやメモリの情報を失わないよう、電源を落とす前に専門家へ相談する
- 記録の保全: dynamicCli.log をはじめ、関連するログを別の場所へコピーして保存する。攻撃者がログを消している可能性も考える
- 認証情報の変更: 該当の機器に保存・経由していた管理者のパスワード、VPN の証明書や鍵、連携しているアカウントの認証情報を変更する。root を取られた機器上の情報は、読み取られたものとして扱う
- 周辺機器の確認: 報道では ESXi への横展開とワイパーの展開が伝えられているため、仮想化基盤、バックアップ、同じセグメントのサーバに異常がないかを確認する。バックアップが別系統で守られているかも確認する
- 専門家への相談: インシデント対応の専門家、または Check Point のサポートへ連絡する。個人情報や取引先の情報に影響した可能性がある場合は、法令上の報告義務の有無も検討する
時系列
| 日付 | 出来事 |
|---|---|
| 2026 年 10 月下旬 | 攻撃が始まったと報じられる（BleepingComputer） |
| 2026 年 11 月 8 日 | Check Point が sk1000362 を作成 |
| 2026 年 11 月 12 日 | sk1000362 の最終更新日 |
| 2026 年 11 月 13 日 | CISA が KEV カタログに追加。BleepingComputer が緊急ホットフィックスと開示を報道 |
| 2026 年 11 月 16 日 | KEV カタログ上の連邦機関の対応期限 |
CISA の KEV 追加アラートは、悪用の証拠に基づく追加であるとし、連邦機関に対して BOD 26-04 に基づく迅速な対応を求めている。KEV カタログ上の連邦機関の対応期限は 2026 年 11 月 16 日である。連邦機関以外の組織にも、同じ優先度で扱うことが推奨される。
今日やることチェックリスト
- Check Point の機器（ゲートウェイ、管理サーバ、ログサーバ、Multi-Domain、Maestro）の一覧を作り、バージョンを確認する
- 各機器の Jumbo Hotfix の Take を確認し、表の修正済み Take と比べる
- ls -l /tmp/dynamic_socket で、権限が 0660 になっているかを確認する
- 未修正の機器は、Jumbo Hotfix の適用日を決める。すぐに当てられない場合は dynamic_server の停止で緩和する（sk144112 のコマンドへの影響を先に確認）
- R81.10／R81 を使っている場合は、サポート対象バージョンへのアップグレード計画を立てる
- dynamicCli.log で、権限昇格の拒否記録と、侵害痕跡の 3 種類の検索を実施する（10 月下旬までさかのぼれるか確認）
- Mobile Access ポータルや管理画面を、不要にインターネットへ公開していないか見直す
- 委託先がある場合は、対応状況を文書で確認する
- 痕跡が見つかったときの連絡先（社内の責任者、委託先、専門家）を今のうちに決めておく
関連記事
- 11月14日の脆弱性まとめ
- SonicWall の脆弱性 CVE-2026-19868（SSLVPN の SAML・MFA 回避）の影響確認と対処手順
- UTM・ファイアウォールの費用と選び方（中小企業向け）
出典
- Check Point sk1000362（CVE-2026-123039）: https://support.checkpoint.com/results/sk/sk1000362
- CISA「CISA Adds Two Known Exploited Vulnerabilities to Catalog」（2026 年 11 月 13 日）: https://www.cisa.gov/news-events/alerts/2026/11/13/cisa-adds-two-known-exploited-vulnerabilities-catalog
- BleepingComputer「Check Point patches zero-day that lets hackers get root access」: https://www.bleepingcomputer.com/news/security/check-point-patches-zero-day-that-lets-hackers-get-root-access/
- NVD CVE-2026-123039: https://nvd.nist.gov/vuln/detail/CVE-2026-123039
よくある質問
ローカルの権限昇格なのに、なぜ緊急扱いなのですか。
攻撃者が先に別の経路でゲートウェイやサーバに低い権限で入り込めれば、この脆弱性で root まで一気に権限を上げられるためです。Check Point は数十社の顧客での悪用を確認しており、報道では Mobile Access ポータルから侵入し、本脆弱性で root を取り、その後に VMware ESXi へ横展開して破壊型のワイパーを展開する攻撃連鎖が伝えられています。CISA も 2026 年 11 月 13 日に KEV カタログへ追加しました。
Mobile Access を使っていなければ影響はありませんか。
影響の有無は Mobile Access の利用ではなく、対象バージョンと対象製品かどうかで決まります。Mobile Access は報道された攻撃連鎖で最初の入口になったと伝えられているだけで、ほかの経路から低権限のコードを実行された場合でも、この脆弱性で root に上げられる点は変わりません。対象なら Jumbo Hotfix を適用してください。
パッチを当てる前に dynamic_server を止めても問題ありませんか。
Check Point が示す一時的な緩和策です。ただし、sk144112 に記載された Dynamic CLI のコマンドが失敗するようになります。そのコマンドを自動化に使っている場合は影響が出るため、先に確認してください。パッチ適用後は、設定を元に戻すことができます。
R81.10 や R81 を使っています。どうすればよいですか。
sk1000362 では、この 2 つは EOS（サポート終了）とされ、修正の Take は記載されていません。サポートされているバージョンへのアップグレードを計画し、それまでは dynamic_server の停止などの緩和策と、侵害痕跡の確認を行ってください。ゲートウェイを外部に公開している場合は、特に急ぐ必要があります。
痕跡が見つからなければ、侵害されていないと言えますか。
言えません。ログの確認で見つかるのは、dynamicCli.log に記録された範囲の痕跡だけです。ログが消されている、保存期間が短いといった場合は判断できません。報道された攻撃は 10 月下旬からとされているため、その時期までさかのぼってログと周辺機器（ESXi を含む）を確認し、判断に迷うときは専門家に相談してください。
株式会社オブライト
株式会社オブライトは、ソフトウェア開発、デジタルサイネージ、Web開発、ネットワークシステム、IoT/AR/VRなどの技術サービスを提供する東京のIT企業です。
この記事に関連する無料ツール（登録不要・その場で結果）
お気軽にご相談ください
お問い合わせ