2026.10.16 セキュリティ

SiteGuardの脆弱性CVE-2026-106931とは：対象版の確認コマンドと更新前の痕跡保全

EGセキュアソリューションズは2026年10月14日、ホスト型WAF「SiteGuard Server Edition」にOSコマンドインジェクションの脆弱性CVE-2026-106931があると公表しました。初期値で有効な統計機能を通じて、製品が動くサーバー上でrootまたはSYSTEM権限のコマンドを実行されるおそれがあり、開発元は悪用を確認しています。本記事の解説対象は、対象バージョンと修正版の選び方、自社サーバーに導入されているかを確かめるコマンド、更新の前に痕跡を残す手順、更新できない場合のパッチと回避策までを、サーバーを預かる実装者の目線で整理した対応手順です。記載内容は2026年10月16日時点の公開情報にもとづきます。

まとめ：SiteGuard Server Editionは診断情報を保存してから修正版へ更新する

CVE-2026-106931の対象は、SiteGuard Server Edition Ver2.20以降のうち、Apache版・Nginx版・IIS版ならVer8.00 Update5より前、FreeBSD版ならVer7.00 Update6より前のすべてです。統計機能は初期値で有効なので、設定を触っていない環境はそのまま当たると考えてください。

作業の順番は決まっています。まず管理画面から診断情報を取り出して保管し、次に修正版へ更新する順序です。開発元は、更新やパッチの適用で攻撃の痕跡が消える可能性があると明記しています。順番を逆にすると、侵害の有無を後から確かめられなくなります。

WAFは本来、Webアプリを守る側の製品です。そのWAF自身が管理者権限を奪われる経路になった以上、更新後もサーバーの中を点検する前提で計画を立てます。複数のサーバーにまたがって入れている場合は、外部の脆弱性診断で導入台数と版の棚卸しから始めると抜けが出にくくなります。

CVE-2026-106931の中身と修正版の公開から注意喚起までの時系列

SiteGuard Server Editionは、ApacheやNginx、IISのWebサーバーに組み込んで動かすWAF（Webアプリケーションファイアウォール）です。ネットワーク機器ではなくWebサーバーと同じホストに入るため、製品の不具合はそのままサーバーの権限に直結します。

初期値で有効な統計機能が条件となるOSコマンドインジェクション

EGセキュアソリューションズの告知によれば、脆弱性の型はCWE-78（OSコマンドインジェクション）です。統計機能が有効な場合に影響を受け、その統計機能は初期値で有効とされています。成功すると、製品が動作するサーバー上でrootまたはSYSTEM権限による任意のOSコマンド実行につながります。

統計機能は、攻撃の検出状況を集計してホーム画面やレポートに出す機能です。同社のレポート機能の説明には、集計が1時間ごと（毎時0分）に行われ、データの保存期間は既定で1年とあります。日常の運用で意識しない裏方の処理なので、「使っていないから関係ない」と判断しがちな点に注意が要ります。

どの入力がどのように統計処理へ渡ってコマンド実行に至るのかは、公表されていません。本記事でも手口の推測は書きません。

CVSS v4.0基本値8.5とAV:L・PR:Lのベクトルから読む前提条件

告知とJVNが示すCVSS v4.0のベクトルは AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H で、基本値は8.5です。v3.0では7.8となります。

ベクトルの読み方としては、攻撃元区分（AV）がローカル、必要な特権レベル（PR）が低となっています。ネットワーク越しに誰でも1回で成立する型ではなく、サーバー上で何らかの低い権限を持つ主体が、それをrootやSYSTEMへ引き上げる型と評価されていることになります。v3系の各指標の意味を確認する参照先はCVSSv3の評価基準と計算式です。

ここで「ローカルだから緊急度は低い」と読むのは誤りです。Webアプリの別の脆弱性でWebシェルを置かれれば、攻撃者はWebサーバーの実行ユーザーという低い権限を手に入れます。そこに今回の脆弱性が重なると、Webアプリ1本の侵害がサーバー全体の乗っ取りへ広がります。開発元が悪用を確認しているのは、まさにこの重なりが現実に起きうるからだと考えるべきです。

9月29日の個別通知から10月14日のJVN公表までの対応経緯

修正版は公表より2週間早く出ています。9月29日に公開されたのはVer8.00 Update5・Ver7.00 Update6で、表では両修正版として記載します。

日付（2026年）	出来事	出典
9月29日	両修正版を公開	サポートバージョン情報
9月29日	サポート契約のある利用者へ個別に連絡	EGセキュア・JVN
10月14日	告知を公開（緊急・悪用確認）	EGセキュア
10月14日	JVN#88474777と注意喚起を公開	JVN・JPCERT/CC

JPCERT/CCの注意喚起（JPCERT-AT-2026-0032）は、本製品が国内で広く使われていることを確認していると述べています。JVN#88474777は、情報セキュリティ早期警戒パートナーシップを通じてIPA経由で報告された案件だと記しています。なお、10月15日付のCISAの既知の悪用脆弱性（KEV）カタログには、本CVEは載っていませんでした。国内中心の製品なので、KEVに無いことを悪用が無いことの根拠にしてはいけません。

SiteGuard Server Editionの対象版とOS別の修正版選定基準

更新先は、Webサーバーの種類とOSで1つに決まります。迷いやすいのはIIS版とFreeBSD版です。

Apache版・Nginx版・IIS版・FreeBSD版ごとの対象範囲と更新先

告知とJVNが示す対象と修正版を、同社のサポートバージョン情報のリリース日と合わせて並べます。対象の下限はいずれもVer2.20以降で、表の対象欄は影響を受ける版の上限を示します。更新先の公開日は共通で2026-09-29です。Apache版・Nginx版とIIS版はVer8.00 Update5、FreeBSD版はVer7.00 Update6が更新先となります。

版	対象	更新先（公開日は本文参照）
Apache版・Nginx版	Ver8.00 Update5未満	Ver8.00 Update5
IIS版	Ver8.00 Update5未満	Ver8.00 Update5
FreeBSDのApache版・Nginx版	Ver7.00 Update6未満	Ver7.00 Update6

FreeBSD版だけは8.00系が無く、7.00系の中で更新します。「最新は8.00だから7.00 Update6は古い」と読み違えないよう、OSと版を組にして確認してください。

IIS版Ver3.10〜4.00 Update4の例外とVer7.00系のサポート期限

告知は、IIS版のVer3.10からVer4.00 Update4までは影響を受けないとしています。ただし、これらはいずれも製品サポートを終えた版です。対象外だからと据え置く理由にはなりません。

IIS版のVer7.00系（Update4・Update5を含む）は、サポートバージョン情報で2026年11月30日がサポート終了日です。IIS版は今回の修正版もVer8.00 Update5なので、7.00系を使っているなら、パッチで急場をしのぐより8.00 Update5への移行を一度で済ませるほうが手戻りが少なくなります。

Proxy EditionとSiteGuard WP Pluginの対象区分

同じSiteGuardの名前を持つ製品は他にもあります。今回の告知が対象として名指ししているのはServer Editionだけで、ゲートウェイ型のProxy Editionへの言及はありません。

「SiteGuard 脆弱性」で調べる方の中には、WordPressのプラグイン「SiteGuard WP Plugin」を使っている方もいるはずです。こちらは別の製品で、2026年8月にCVE-2026-61982（1.8.6以前の認証不要のクロスサイトスクリプティング）が公開されています。WordPress.orgのAPIで確かめた現行版は1.8.9です。WP Pluginの更新は、プラグインの更新手順を含むWordPress保守運用の作業範囲の中で扱います。

自社サーバーでSiteGuardの導入有無と稼働中の版を確かめるコマンド

最初の壁は「どのサーバーに入っているか分からない」ことです。構築を外部に任せた環境や、VPSの初期設定スクリプトで入れた環境では、担当者が導入に気付いていないことがあります。

Linuxでプロセス・パッケージ・管理画面ポートから導入有無を洗い出す

次のコマンドはどれも読み取りだけで、設定を変えません。さくらのVPSのマニュアルでは、SiteGuard Server Editionの管理画面は https://FQDN:9443/ で開くと案内されています。

# 1. 管理画面のポート（さくらのVPSの案内では9443）を待ち受けるプロセス
sudo ss -ltnp | grep ':9443'

# 2. SiteGuard の名前を含むプロセス（[s] は grep 自身を除くための書き方）
ps -ef | grep -i '[s]iteguard'

# 3. パッケージとして入っていれば名前と版が出る
rpm -qa | grep -i siteguard      # RHEL・Rocky Linux 系
dpkg -l | grep -i siteguard      # Debian・Ubuntu 系

# 4. 複数台をまとめて調べる（hosts.txt に1行1台のホスト名）
while read h; do
  echo "== $h"; ssh -n "$h" "ps -ef | grep -ci '[s]iteguard'"
done < hosts.txt

2か4で1以上の数が出たホストは、導入済みとして台帳に載せます。3で何も出なくても、インストーラーで入れた環境はパッケージ管理に載らないことがあるため、1と2の結果を優先する判断が必要です。稼働中の正確な版は、管理画面にログインして確認し、前章の表と突き合わせます。

Windows Server（IIS版）の導入版をPowerShellで確認

IIS版は、Windowsのインストール済みプログラムの情報から版を読めることが多いです。

# 64bit・32bit 両方のアンインストール情報から SiteGuard を探す
$keys = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
        'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
Get-ItemProperty $keys -ErrorAction SilentlyContinue |
  Where-Object { $_.DisplayName -match 'SiteGuard' } |
  Select-Object DisplayName, DisplayVersion, InstallDate

何も表示されなければ、IISのモジュール一覧や管理画面で導入の有無を確かめます。表示された版がIIS版のVer3.10〜4.00 Update4なら今回の対象外ですが、前章のとおりサポート外の版なので、更新の計画は別に立てます。

更新前に診断情報と痕跡を保全する作業順序と更新できない場合の回避策

開発元とJPCERT/CCがそろって強調しているのが、更新の前の保全です。ここを飛ばすと、侵害されていたかどうかを後から判断できなくなります。

管理画面の診断情報とWebサーバーのログを更新前に退避する理由

告知が案内する手順は、Web管理画面の［診断情報］から［診断情報をダウンロード］を実行し、そのファイルを保管するというものです。あわせて、Webサーバー側のログも同じタイミングで外へ出しておくと、診断情報だけでは追えない時間帯を補えます。

# 更新前に Web サーバーのログをまとめて退避し、改ざん検知用のハッシュを残す
TS=$(date +%Y%m%d%H%M)
sudo tar czf "/root/evidence_${TS}.tar.gz" /var/log/httpd /var/log/nginx
sha256sum "/root/evidence_${TS}.tar.gz" | sudo tee "/root/evidence_${TS}.sha256"

# 退避先は対象サーバーの外（例：運用端末へ scp）
scp "server:/root/evidence_${TS}.*" ./

ログのディレクトリはディストリビューションと構成で変わるので、存在しないパスは除いてください。保全が終わったら、修正版への更新に進みます。作業順は次のとおりです。

管理画面から診断情報をダウンロードして保管する
Webサーバーのログを退避し、ハッシュを記録する
Ver8.00 Update5（FreeBSD版はVer7.00 Update6）へ更新する
管理画面で稼働中の版を確認し、更新記録を残す

更新後にroot権限での不審な実行痕跡とcron・アカウントを点検する

更新は脆弱性を塞ぐだけで、すでに入り込んだ攻撃者を追い出しません。rootで任意のコマンドを実行できた攻撃者が残しやすいのは、定期実行の仕込み、新しいアカウント、外への常時接続です。

# 定期実行の仕込み（root と各ユーザーの crontab、cron.d）
sudo crontab -l
sudo ls -la /etc/cron.d /var/spool/cron

# 新しく増えたアカウントとログイン履歴
awk -F: '$3 >= 1000 {print $1, $3, $7}' /etc/passwd
sudo last -n 30

# 外へ張られたままの接続と、その接続元プロセス
sudo ss -tnp state established

見慣れない定期実行やアカウントが1つでも出たら、その場で消さずに保全を優先します。証拠を壊さずに調べる進め方はデジタルフォレンジックの調査の流れにまとめています。

統計処理ファイル差し替えパッチと統計機能の無効化を選択する条件

すぐに版を上げられない場合の手段は2つあります。1つは開発元が提供する、統計処理の対象ファイルを差し替えるパッチで、サポートを終えた版にも用意されています。もう1つは、JPCERT/CCが回避策として挙げる統計機能の無効化です。

選択の判断軸は、更新に伴う動作確認の所要期間とパッチの入手経路です。版を上げると業務アプリの動作確認に数週間かかるなら、パッチを当てて修正版への移行を別に計画します。パッチの入手にも時間がかかる、またはサポート契約が切れていて入手経路が無いなら、統計機能を止めてしまいます。無効化の具体的な操作は告知本文に載っていないため、開発元の最新情報で確認してください。

無効化は応急処置です。統計を止めると攻撃の検出状況の集計とレポートも止まり、WAFの効き目を数字で追えなくなります。修正版へ上げた時点で元に戻す前提で使います。

SiteGuard Server Editionの継続利用の判断基準と更新体制

守る側の製品で悪用が確認されたため、「WAFごと入れ替えるべきか」という相談が出るのは自然です。結論は、製品より更新体制で決まります。

サポート契約と更新体制がある環境でSiteGuardを継続利用する条件

使い続けてよいのは、サポート契約があり、9月29日の個別連絡か10月14日の公表から数日以内に修正版を当てられた環境です。この条件なら、別のWAFへ移る作業と検知ルールの作り直しのほうが、リスクも費用も大きくなります。

見直しを勧めるのは、次のどれかに当たる環境です。

サポート契約が切れていて、9月29日の個別連絡を受け取れていない
サポートを終えた版（Ver6.00系以前）のまま、更新の担当者がいない
どのサーバーに入っているかを、前章のコマンドで初めて把握した

この条件では、次の脆弱性でも同じ遅れが出ます。製品を替えるより先に、担当と契約と台帳を整えるのが本筋です。

VPSやクラウドの付属WAFで事業者と利用者の更新責任を確かめる

SiteGuard Server Editionは、VPSやクラウドの事業者が導入スクリプトやパートナー製品として提供していることがあります。この場合、事業者が用意するのは入れる手段までで、入れた後のサーバーの中の更新は利用者の作業になるのが通例です。さくらのVPSのマニュアルも、管理者向けの手順は開発元のご利用ガイドを参照するよう案内しています。

一方、レンタルサーバーなどで事業者がWAFを機能として提供し、利用者がサーバーに入れない形なら、更新は事業者の作業です。自社の契約がどちらに当たるかを、事業者の告知と契約書で確認してください。

入口の製品の更新が遅れて、その先の業務アプリまで侵害が広がる構造は、プラグインの脆弱性でも同じです。同じG30で扱ったEC-CUBE AmazonPayプラグインの脆弱性でも、修正版の確認と侵害調査を組で進める手順を整理しました。CMS本体の例としては、Movable Typeの脆弱性CVE-2026-96408で版の確認コマンドとCGIの遮断手順をまとめています。複数のサーバーと下流のWebアプリをまとめて点検するなら、脆弱性診断・セキュリティ診断で外からの到達性と導入製品を棚卸しすると、更新の優先順位を決めやすくなります。

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

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

統計機能を使っていないつもりでも更新は必要ですか？

必要です。統計機能は初期値で有効なので、意図して無効にした記録が無い限り、有効と考えるべきです。ホーム画面のグラフやレポートを見ていなくても、集計は毎時0分に裏で動いています。管理画面で設定を確かめるより先に、対象の版なら更新の計画を立ててください。無効化はJPCERT/CCが回避策として挙げていますが、あくまで更新までの応急処置です。

SiteGuard WP Pluginを使っている場合も今回の対象ですか？

対象ではありません。今回の告知はWebサーバーに組み込むSiteGuard Server Editionのもので、WordPressのプラグインであるSiteGuard WP Pluginは別製品です。ただしWP Pluginにも、2026年8月に1.8.6以前を対象とするCVE-2026-61982（クロスサイトスクリプティング）が公開されています。WordPressの管理画面で版を確かめ、1.8.6以前なら更新してください。

CVSSの攻撃元区分がローカルなら、外部から直接攻撃されませんか？

ネットワーク越しに単独で成立する型とは評価されていません。ただし、Webアプリの別の脆弱性やWebシェルでサーバー上の低い権限を得られると、そこからrootやSYSTEMへ上がる足がかりになります。開発元は悪用を確認しており、JPCERT/CCも注意喚起を出しています。攻撃元区分を理由に更新を後回しにする判断は取らないでください。

更新する前に診断情報を保存し忘れた場合はどうすればよいですか？

更新で消えた痕跡は戻りません。残っている材料で調べます。Webサーバーのアクセスログ、OSの認証ログ、cronやアカウントの変化、外への接続を、9月29日より前の期間までさかのぼって確認します。不審な点が1つでも見つかったら、自己調査を続けるよりディスクとログの保全を優先し、外部の調査を検討してください。

サポートが終了した古い版を使っている場合はどうすればよいですか？

告知によれば、統計処理の対象ファイルを差し替えるパッチはサポート終了版も対象です。まず販売店かサポート窓口にパッチの入手方法を問い合わせ、入手までの間は統計機能を無効にします。そのうえで、Ver8.00 Update5（FreeBSD版はVer7.00 Update6）への移行を計画します。IIS版の7.00系は2026年11月30日にサポートを終えるので、移行先は8.00系です。