Check Point脆弱性CVE-2026-123039：Gaiaのroot権限昇格を確かめるコマンドと侵害調査の手順

Check Pointは2026年11月8日、Gaia OSのローカル権限昇格の脆弱性 CVE-2026-123039 をサポート記事sk1000362で公表し、11月12日に更新しました。Dynamic CLIを担うrootのプロセスが、誰でも書き込めるソケットからの命令をそのまま実行してしまう欠陥で、同社は数十社規模の顧客に対する悪用を確認しています。この記事では、影響を受ける製品とJumbo Hotfixの修正Take、自社の機器が修正済みかを判定するコマンド、dynamicCli.logを使った侵害調査、サポート終了版での回避策、そしてファイアウォールの内側で業務システムを動かす側が確認すべきことまでを、実装者の目線で整理します。記載内容の根拠は、2026年11月14日時点で公開されている情報です。

まとめ：ソケット権限の確認とJumbo Hotfix適用、侵害調査を同じ日に

CVE-2026-123039は、Check PointのファイアウォールやManagement Server上で、ローカルの一般ユーザーがroot権限でコマンドを実行できる脆弱性です。CVSS 3.1の基本値は7.8で、遠隔から直接は突けません。それでも米CISAは2026年11月13日に既知の悪用リスト（KEV）へ登録し、対応期限を3日後の11月16日に設定しました。

やることは3つに絞れます。まず /tmp/dynamic_socket の権限が0660かを見て、修正済みかを判定する。未修正ならR82.20・R82.10・R82・R81.20のJumbo Hotfixを修正Take以上へ上げる。そして適用の前後どちらでも、/var/log/dynamicCli.log に正規の形式でない命令が残っていないかを調べる。サポートが終了したR81.10とR81には修正が出ていないため、dynamic_server の停止で塞ぎます。

侵害の痕跡が出た場合、影響は機器の中で終わりません。その機器を経由する業務システムの認証情報や、VPN利用者のアカウントまで点検範囲を広げます。

CVE-2026-123039とdynamic_serverのroot命令実行経路

Gaiaは、Check Pointのセキュリティゲートウェイと管理サーバーが動く専用OSです。今回の欠陥は、Gaiaのコマンドシェル（Clish）を拡張する「Dynamic CLI」の内部にありました。

誰でも書き込める0777のソケットと接続元を認証しない設計の欠陥

Check Pointのsk1000362によれば、Dynamic CLIの命令はrootで動く dynamic_server というプロセスが処理し、ローカルのプロセス間通信用ソケット /tmp/dynamic_socket で待ち受けています。影響を受ける製品では、このソケットが権限0777（全ユーザーが書き込み可能）で作られていました。

しかも dynamic_server は、接続してきたプロセスが誰かを確かめず、受け取った文字列をrootとして実行します。ソケットに1回書き込むだけで、ログインできる一般ユーザーが任意のコマンドをrootで動かせる、というのが脆弱性の中身です。Dynamic CLI自体の位置づけはsk144112（Dynamic CLIの解説）にまとまっています。

CISAのKEVカタログはこの欠陥を、重要な資源に対する不適切な権限設定（CWE-732）と、認可の欠如（CWE-862）に分類しています。

CVSS 7.8のベクトル内訳とローカル攻撃が前提である意味

NVDのCVE-2026-123039に載っているCheck Pointの採点は、ベクトル AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H です。攻撃元はローカル（AV:L）、必要な権限は低い（PR:L）、利用者の操作は不要（UI:N）で、成立すれば機器の機密性・完全性・可用性をすべて失います。

sk1000362は、攻撃者がすでに機器上でコードを実行できる状態にあることを前提条件として明記しています。点数が9点台でないのはこのためです。ただし、前提を満たす手段が別にあれば話は変わります。CVE番号とスコアの関係そのものはCVEの番号の読み方とNVDとの違いで整理しています。

影響を受けるCheck Point製品とバージョン、修正Takeの対応表

影響の有無は製品の種類とGaiaのバージョン、そして適用済みのJumbo Hotfix Accumulator（以下JHA）のTake番号の3点で決まります。

Force FirewallとManagement Serverの影響対象判定

sk1000362が挙げる影響製品は次のとおりです。ゲートウェイだけでなく、ポリシーを配る管理サーバーやログサーバーも含まれる点に注意してください。

• Check Point Force Firewall（セキュリティゲートウェイ）
• Management ServerとLog Server
• Multi-Domain Security ManagementとMulti-Domain Log Server
• Maestro Orchestrator

対象外とされているのは、小規模拠点向けのSpark FirewallとクラウドのSmart-1 Cloudです。対象外の理由までは記事に書かれていないため、ここは公表どおりに扱います。一方で、管理サーバーを社内に置くオンプレミス構成なら、ゲートウェイと管理サーバーの両方を確認対象に数えます。

R82.20 Take 14からR81.20 Take 174までの修正版と対象版

影響を受けるバージョンはR82.20、R82.10、R82、R81.20、R81.10、R81です。修正はJHAに含まれており、バージョンごとの修正Takeは次の表のとおりです。

修正版は、認証されていないDynamic CLIの呼び出しを遮断し、その事実をログに残します。R81.10とR81は対象バージョンに含まれながら修正Takeが示されていません。この2つは、後述の回避策で塞いだうえで、R81.20以降への更新を計画する前提で扱います。

Expertモードで修正状況と稼働プロセスを判定する確認コマンド

判定は、機器ごとにExpertモードへ入り、読み取りだけのコマンドを流せば数分で終わります。クラスタ構成では、メンバーそれぞれで実行してください。

ソケットの権限とdynamic_server、適用済みTakeを一度に見る手順

次のスクリプトは、ソケットの権限、dynamic_server の稼働状況、適用済みJHAのTakeを続けて表示します。1と2はsk1000362に記載の確認方法、3はGaia標準の cpinfo によるHotfix一覧の表示です。

#!/bin/bash
# CVE-2026-123039 の状態確認（Expert モードで実行・読み取りのみ）
SOCK=/tmp/dynamic_socket

echo "== 1. ソケットの権限（root config 0660 なら修正済み、0777 なら未修正）"
ls -l "$SOCK"
stat -c '%a %U %G' "$SOCK"

echo "== 2. dynamic_server の稼働状況（回避策を入れた機器では何も表示されない）"
ps auxw | grep -v grep | grep 'dynamic_server'

echo "== 3. 適用済み Jumbo Hotfix の Take"
cpinfo -y all 2>/dev/null | grep -i 'JUMBO'

1の結果が srw-rw---- root config（stat では 660 root config）なら修正済みです。srwxrwxrwx（777）なら未修正で、すぐ次の章の対応に進みます。ソケットが存在しない場合は、dynamic_server が止まっているか、まだ一度も起動していない状態です。

3でバージョンとTakeが表の修正Take以上であれば、1の結果と合わせて「修正済み」と記録します。Takeの数字だけ見て判断せず、必ず1の権限表示で裏を取ってください。Hotfixを入れたつもりで別のボリュームを起動していた、という食い違いをここで拾えます。

管理サーバーと冗長構成のメンバーを修正状況の確認から漏らさない範囲

確認の漏れが出やすいのは3か所です。

1. クラスタのスタンバイ側メンバー。フェイルオーバーした時点で同じ欠陥が表に出ます。
2. Management ServerとLog Server。ゲートウェイの保守だけを請け負う体制だと、管理サーバーのJHAが数Take遅れていることがあります。
3. 検証環境や災害対策サイトのゲートウェイ。本番と同じ管理者アカウントを使い回していれば、侵入口になりえます。

機器の台数が多い場合は、版の一覧とKEVの照合を自動化しておくと毎回の判定が速くなります。VPN装置全般での照合スクリプトの組み方はVPN機器の版確認コマンドとKEV照合スクリプトで解説しています。

Jumbo Hotfix適用とdbsetで止める回避策を選ぶ判断基準と手順

原則はJHAの修正Take以上への更新です。回避策は、更新までの時間を稼ぐ手段か、修正が出ないEOS版を塞ぐ手段として使います。

修正Takeへ即日更新する機器と回避策で数日しのげる機器の線引き

当日中に更新するのは、外部からVPNやポータルで到達できるゲートウェイと、インターネットに管理用ポートを開けている管理サーバーです。ローカル権限昇格は単独では成立しませんが、Check Pointは2026年9月にも、認証なしで遠隔からコードを実行できる脆弱性を相次いで公表しました。VPNの証明書検証の欠陥 CVE-2026-85102（sk1000117）と、管理サーバーのパストラバーサル CVE-2026-93616（sk1000171）で、どちらもKEVに登録されています。

遠隔の欠陥で一般権限のコードを動かし、今回の欠陥でrootを取る。この2段の組み合わせが成立する機器は、点数7.8という数字より重く扱います。KEVの登録事例やPoCの公開状況をどう読むかはexploitの意味と悪用状況の確認手順で扱っています。

社内からしか届かず、シェルに入れるアカウントが運用担当者に限られる機器は、回避策を入れたうえで数日以内の保守枠での更新でかまいません。待ってよいのはここまでです。

dbsetでdynamic_serverを止める回避策とDynamic CLIへの影響

sk1000362が示す回避策は、dynamic_server を止めて再起動させない設定です。コマンドは記事の記載どおりで、1行目は値を付けずに実行します。

# dynamic_server を停止し、再起動させない（sk1000362 の回避策）
dbset process:dynamic_server
dbset :save

# Dynamic CLI が必要になり、元に戻すとき
dbset process:dynamic_server t
dbset :save

止めると、sk144112に載っているDynamic CLIのコマンドは失敗するようになります。運用手順書や監視スクリプトがDynamic CLIのコマンドを呼んでいないかは、回避策を入れる前に確かめておく項目です。止めた後は、前章のスクリプトの2で dynamic_server が表示されないことを確認します。

JHAを修正Takeに上げた後に再び有効化するかは、Dynamic CLIのコマンドを実際に使っているかで決めます。使っていないなら止めたままにしておく、というのが私たちの判断です。動いていないデーモンは、次に欠陥が見つかっても攻撃面になりません。

dynamicCli.logに残る正規でない命令を探す侵害調査の手順と読み方

sk1000362によれば、脆弱なデーモンは受け取ったすべての命令を /var/log/dynamicCli.log に記録しています。調査はこのログを起点に進めます。CISAもKEVの記載でフォレンジックの初期調査を求めており、更新作業の前にログを退避しておく順番を守ってください。

Clishのラッパーを通らない命令とsystem()呼び出しを洗い出すgrep

正規の要求は、Clishが付ける決まった前置き（ラッパー）を必ず通ります。sk1000362が示す正規の形は次の1行です。

Received = #524288# . /opt/CPshared/5.0/tmp/.CPprofile.sh >> /dev/null; export SP_DISTRIBUTE=0; set -o noglob; <Gaia binary> 2>&1

このラッパーを通らない命令は、ソケット経由でrootとして実行された可能性があります。sk1000362は、ゲートウェイとクラスタメンバーのそれぞれで次の3つの検査を求めています。

# 1. 正規のラッパーを使っていない命令を抜き出す
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.log

1で何か出た時点で、侵害を前提に動きます。3は、外部への接続（nc・/dev/tcp）、ファイルの持ち込み（curl・wget）、永続化（useradd・authorized_keys）を狙った命令の検出です。出てきた命令の日時を控え、同じ時間帯のポータルや認証のログと突き合わせて、侵入の入口を探します。

修正後に出るRejected connectionのログとuid 99が示す攻撃の試み

修正Takeを適用した機器では、認証されない呼び出しが遮断され、次のコマンドで記録を確認できます。

grep "Rejected connection from unauthorized uid" /var/log/dynamicCli.log

sk1000362の例では [DynamicCLI]: Rejected connection from unauthorized uid 99 (pid 123456) という行が出ています。uid 99はnobodyで、ログインユーザーではなく権限を絞って動くプロセスに割り当てられる番号です。想定外のuidが記録されていれば、権限昇格が試みられ、修正によって止められたことを意味します。

止められたから安心、とはなりません。uid 99で命令を送れた時点で、何者かが機器の上で一般権限のコードを動かしています。一般権限でコードを動かせる状態になった入口は、この権限昇格とは別の経路です。拒否の記録が短時間に集中していれば、その時刻を軸にポータルと認証のログを洗い、最初の侵入経路を特定します。ログを長期で集めて相関を見る体制は、SOCとSIEMによる監視運用の仕組みが前提になります。

ローカル権限昇格を境界機器で軽く見てはいけない理由と見送れる条件

サーバーのローカル権限昇格は、Linux全般でも毎月のように公表されます。Linuxカーネルの脆弱性CVE-2026-98432の修正版と緩和策のように、通常は「まず侵入されないこと」を前提に保守枠で更新すれば足ります。境界機器について、保守枠まで待つという判断を変える理由は次の2つです。

VPNとポータルが外に開く機器では一般権限の足場が作られやすい構造

1つ目は、ファイアウォールやVPNゲートウェイが、外部からの通信を受ける処理をもともと多く抱えていることです。ポータルやVPNのデーモンに欠陥があれば、そこが一般権限の足場になります。sk1000362が拒否ログの例にnobodyのuidを挙げ、ポータルと認証のログとの突き合わせを勧めているのも、この経路を想定しているからだと読めます。

2つ目は、rootを取られた境界機器は、通信の中身と内部ネットワークへの経路を同時に握られることです。ファイアウォールの役割と、UTMとして機能を集約したときの影響範囲はUTMの機能とファイアウォールとの違いで整理していますが、機能を集めた機器ほど1台の侵害で失うものも大きくなります。

シェルに入れるアカウントを絞る運用と更新を後回しにしてよい場面

あわせて見直す対象は、ローカルで攻撃できる者を減らすためのアカウント運用です。Expertモードに入れる管理者アカウントを棚卸しし、退職者や外部ベンダーの共有アカウントが残っていないかを確かめます。誰がいつ特権で入ったかを記録する仕組みは特権ID管理の貸出・操作記録の仕組みで解説しています。

更新を通常の保守枠まで後回しにしてよいのは、次の条件をすべて満たす機器だけです。外部から管理画面・ポータル・VPNのいずれにも到達できない。シェルに入れるのは記録の残る特権アカウントだけ。そして dynamic_server を回避策で止めている。1つでも欠けるなら、今週中に修正Takeへ上げます。

ファイアウォールの侵害が疑われるとき業務システム側で確認すること

ここからは、Check Pointの機器そのものではなく、その内側で業務システムやWebシステムを動かす側の話です。境界機器のrootを取られていた場合、影響は下流のシステムにも及びます。

機器に保存された認証情報とVPN利用者のアカウントを入れ替える範囲

侵害調査で痕跡が出た、または調査に必要なログが残っておらず否定できない場合、機器に置かれていた秘密情報は漏れたものとして扱います。入れ替えの対象は少なくとも次の4つです。

• ゲートウェイと管理サーバーの管理者アカウントのパスワード
• LDAPやActive Directoryと連携するためのバインド用アカウント
• VPNの事前共有鍵と、ゲートウェイの証明書
• VPNを使う利用者のパスワード（機器上で認証が通っていた場合）

あわせて、機器のルールに業務システム向けの穴が勝手に足されていないかを、変更履歴と現行ポリシーの差分で確かめます。痕跡が見つかった機器は、自己調査を続けるより先にディスクとログを保全します。証拠を壊さない調べ方と外部への依頼の考え方はフォレンジック調査の流れと調査会社の選び方を参照してください。

個人情報を含む通信が経路上にあった場合の報告判断と診断の依頼範囲

侵害された機器を、顧客の個人情報を含む通信が通っていた場合は、漏えいのおそれとして個人情報保護委員会への報告が必要かを判断します。速報の期限や対象の類型は個人情報保護委員会への報告義務と速報・確報の実務で解説しています。

痕跡が無かった場合でも、今回の確認で「どの機器が外から何に到達できるか」を把握していなかったと分かったなら、そこが次の課題です。境界機器の露出と、その内側のWebアプリやAPIを一続きで点検するなら、脆弱性診断・セキュリティ診断で機器ごとの到達性と更新の優先順位をまとめて洗い出せます。診断の種類や外注時の判断基準は脆弱性診断の進め方と外注時の判断基準にまとめています。

Check Pointの脆弱性CVE-2026-123039対応でよく受ける質問と回答

CVE-2026-123039の対応を進める際に出てきやすい疑問に、2026年11月14日時点の一次情報の範囲で答えます。

遠隔から直接突けない脆弱性なのに、なぜKEVに登録されたのですか？

Check Pointが数十社規模の顧客に対する実際の悪用を確認しているからです。KEVは点数の高さではなく、悪用の事実で登録されます。NVDに記録されたCISAの評価でも、悪用は「active」、技術的な影響は「total」とされています。ローカルの前提は、別の遠隔の欠陥や盗まれた管理者アカウントで満たせるため、点数7.8だけで後回しにしないでください。

Spark FirewallやSmart-1 Cloudを使っている場合も対応が必要ですか？

sk1000362では、Spark FirewallとSmart-1 Cloudは影響を受けない製品とされています。この脆弱性についての対応は不要です。ただし、2026年9月に公表されたVPNの脆弱性CVE-2026-85102は、Spark Firewallでの悪用が確認されています。今回の対象外であっても、別のCVEに対する修正の適用状況は個別に確かめてください。

Jumbo Hotfixを適用すれば侵害調査は不要ですか？

不要にはなりません。修正Takeは今後の権限昇格を止めるもので、適用前にrootで実行された命令や、仕込まれたアカウント・鍵は残ります。CISAのKEVでは、この脆弱性はフォレンジックの初期調査が必要な項目という扱いです。dynamicCli.log の3つのgrepを済ませ、ログを退避してから更新に入る順番を勧めます。

R81.10やR81を使い続けている場合はどうすればよいですか？

R81.10とR81は対象バージョンに含まれますが、sk1000362に修正Takeは示されていません。当面は dbset で dynamic_server を止める回避策を入れ、ソケット経由の命令が実行されない状態にします。そのうえで、修正Takeが用意されているR81.20以降への更新を計画してください。サポート終了版は、次の脆弱性でも修正が出ない前提で扱う必要があります。

回避策でdynamic_serverを止めると通信や運用に影響はありますか？

sk1000362によれば、止めた場合に失敗するのはsk144112に載っているDynamic CLIのコマンドです。ファイアウォールのポリシーやVPNの通信処理が止まるという記述はありません。影響を受けやすいのは、Dynamic CLIのコマンドを呼ぶ運用スクリプトや監視の仕組みです。回避策の前に、自社の手順書とスクリプトでこれらのコマンドが使われていないかを確認しておきます。

関連記事

• 脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務を解説：今回のような脆弱性が公表から修正に至る流れの基礎を確認できます。
• VPN 脆弱性：機器の版確認コマンドとKEV照合スクリプト・パッチと移行の判断【2026年10月】：Check Pointを含むVPN機器の版確認とKEV照合を自動化する方法です。
• Ivanti Connect Secureの脆弱性：10月の悪用済み3件の対象版判定と侵害調査：別メーカーの境界機器で、対象版の判定と侵害調査を進めた例です。
• CTEMとは？脆弱性管理との違い・5つの段階と企業の導入判断を解説：単発の緊急対応でなく、入口機器の露出を継続的に管理する考え方です。
• API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策：境界機器の内側にある業務アプリのAPIで、侵入を広げさせない実装です。