>
>
公開日
「siteguard 脆弱性」で調べている情シス担当者向けに、SiteGuard Server Editionの悪用確認済みの問題を解説します。利用製品の特定、更新前の診断情報の保全、更新と侵害調査の判断を整理し、資産台帳や保守契約、管理画面の公開範囲まで、対応漏れを防ぐ実務の確認項目を示します。
SiteGuardの脆弱性とは
SiteGuard Server Editionの統計機能に、OSコマンドインジェクションの脆弱性（CVE-2026-106931）があります。開発元のEGセキュアソリューションズは2026年10月14日のお知らせで、すでに悪用が確認されていること、当該製品が動作するサーバ上でrootまたはSYSTEM権限で任意のOSコマンドが実行される可能性があることを公表しました。サポート契約のある利用者には、9月29日に個別に通知しています。
JPCERT/CCも注意喚起（JPCERT-AT-2026-0032）を出し、当該製品が国内で広く利用されていることを確認したとしています。開発元は、アップデートまたはパッチの適用によって攻撃の痕跡が消える可能性があるとして、適用前に「診断情報」を取得して保管するよう案内しています。
対象は、法人の情報システム部門の担当者・管理者です。SiteGuardの脆弱性への対応では、製品更新と侵害調査を分けて考えます。Webアプリケーションを保護するWAFの脆弱性だからこそ、更新だけで対応完了とせず、適用前の痕跡保全を起点にします。
最優先の5項目（初動チェックリスト）
製品確認：稼働中の製品がSiteGuard Server Editionか、影響を受ける版か、統計機能が有効かを確認します。
診断情報の取得：更新やパッチ適用の前に、ウェブ管理画面の［診断情報］→［診断情報をダウンロード］から取得し、保管します。
保全の確認：保存先、取得時刻、取得者を記録し、保存を確認してから更新担当へ連絡します。
更新またはパッチ適用：保全完了後に、修正版（Ver8.00 Update5、FreeBSD版はVer7.00 Update6）への更新、または更新が困難な環境向けのパッチを適用します。
侵害調査の起票：適用の完了とは別に、保全した診断情報を起点とする調査を起票します。
CVE-2026-106931は、この脆弱性を識別する番号です。OSコマンドインジェクションとは、攻撃者が入力などを通じて、本来意図しない命令をサーバのOSに実行させる問題です。JVNはJVN#88474777で、深刻度を表すCVSS 4.0基本値を8.5と評価しています。開発元はCVSS 3.0の基本値7.8も併記しています。これは脆弱性の深刻度の評価であり、自社が侵害されたことを示す数値ではありません。
すぐに更新やパッチを適用できない場合は、JPCERT/CCが回避策として案内している統計機能の無効化を検討します。無効化の手順は、開発元の最新の情報で確認します。侵害の有無は、適用とは別に調査します。
自社の利用製品と影響範囲の切り分け
製品名と管理主体の特定
「SiteGuard」という名称だけで判断せず、正式製品名と管理主体を特定します。
開発元とJVN（JVN#88474777）が対象としているのは、ホスト型WAFのSiteGuard Server Editionです。開発元の製品にはゲートウェイ型のSiteGuard Proxy Editionやクラウド型のSiteGuard Cloud Editionもあり、本件のお知らせが影響範囲に挙げているのはServer Editionです。契約書、管理画面、構成情報で正式名称を照合します。
自社管理なら管理担当が情報を回収し、運用委託やサービス経由の利用なら保守窓口・提供元へ照会します。契約上の名称と実際の稼働情報が一致しなければ、未確認として調査を続けます。
バージョンと機能設定の照合
利用状況は環境ごとに記録し、導入バージョンと統計機能の状態を別々に照合します。
次の表を環境ごとに作成します。空欄は残さず、不明な項目には「未確認」と記入すれば、追加調査の対象を区別できます。
確認項目 | 記入欄 |
|---|---|
正式製品名 | ＿＿＿＿ |
稼働先・導入環境 | サーバー、OS、Webサーバーなど：＿＿＿＿ |
導入バージョン | 更新番号を含む表記：＿＿＿＿ |
統計機能の有効状態 | 有効・無効・未確認：＿＿＿＿ |
管理担当 | 部署・担当者：＿＿＿＿ |
保守窓口 | 委託先・提供元・連絡先：＿＿＿＿ |
確認根拠 | 契約書、画面、構成情報、取得日時：＿＿＿＿ |
統計機能の状態は、現在の設定と過去の稼働状況を分けて記録し、過去の状態が不明な項目は「未確認」のまま台帳に残します。
対象判定と未確認事項
対象と一致する環境、情報不足の環境、別製品と特定できた環境を分けて管理します。
影響を受ける版と修正版は、開発元のお知らせに次のとおり記載されています。
区分 | Apache版・Nginx版・IIS版 | FreeBSD Apache版・Nginx版 |
|---|---|---|
影響を受ける版 | Ver2.20以降、Ver8.00 Update5より前 | Ver2.20以降、Ver7.00 Update6より前 |
修正版 | Ver8.00 Update5 | Ver7.00 Update6 |
IIS版のVer3.10からVer4.00 Update4は影響を受けません。影響を受けるのは統計機能が有効な場合で、統計機能は初期状態で有効です。設定を変えた記録がない環境は、有効の可能性があるものとして扱います。版が該当する環境は痕跡保全へ進み、該当しない環境は照合した根拠を台帳に残して本件の対象から分けます。
確認結果 | 対応判断 |
|---|---|
対象との一致を確認できた環境 | 痕跡保全と対策へ進みます。 |
製品や版が不明な環境 | 担当・提供元への照会と情報回収を並行します。 |
別製品と特定できた環境 | 本件と分けて管理します。 |
未確認を対象外に分類すると、調査待ちの環境が対応一覧から漏れます。対象と一致した環境は、更新作業に先立つ診断情報取得と痕跡保全へ進めます。
▲ 自社利用製品の対象判定と影響範囲の切り分けフロー
更新前の診断情報取得と痕跡保全
開発元は、アップデートまたはパッチの適用で攻撃の痕跡が消える可能性があるとして、適用前に「診断情報」を取得して保管するよう案内しています。JPCERT/CCの注意喚起も、痕跡を保全した上でのアップデートを推奨しています。更新やパッチ適用の作業の前に、診断情報の取得と保存確認を組み込みます。
ウェブ管理画面での診断情報取得
診断情報は、ウェブ管理画面の［診断情報］→［診断情報をダウンロード］から取得します（開発元のお知らせに記載の操作）。取得したファイルは、更新やパッチ適用の作業をするサーバとは別の場所に保管します。
取得から更新担当への引き継ぎまでは、次の流れで進めます。保管方法と記録の付け方は、社内の保管基準に合わせてください。
対象の製品名、サーバー、利用環境を特定します。
対象環境のウェブ管理画面で［診断情報をダウンロード］を実行します。
取得した診断情報で確認できる内容、対象範囲、取得時刻、取得者を記録します。
取得した資料を、関係者だけがアクセスできる保存先に保管します。
保存を確認したうえで、更新担当へ保全完了を連絡します。
保存先と取得記録の管理
社内の保管基準を適用できるなら、保存先と取得記録をひも付け、更新担当と調査担当が同じ資料を参照できる状態にします。取得端末に置いたまま引き継ぎを終える運用は避けます。
受け渡しには、対象環境、取得者、取得時刻、保存先、保存確認者を記載した記録を使えます。調査担当へ渡す場合は受領者と受領時刻も残し、保存した元の資料を維持できるなら、調査には作業用の複製を使います。次の表は、担当を割り当てられる場合の運用例です。
区分 | 作業 | 担当 | 残す記録 | 次工程へ進む条件 |
|---|---|---|---|---|
更新前 | 対象特定、診断情報取得、保存確認 | 取得担当・対応責任者 | 対象環境、取得時刻、取得者、保存先、取得結果 | 取得できれば保存確認後に更新へ進みます。取得不能なら保守窓口と責任者へ共有し、進め方を決めます。 |
更新時 | 保全完了の連絡を受けて更新 | 更新担当 | 引き継ぎ内容、更新時刻、作業結果 | 更新結果を記録し、調査担当へ引き継ぎます。 |
更新後 | 保全資料と作業記録の受け渡し | 調査担当・対応責任者 | 受領者、受領時刻、調査への引き継ぎ事項 | 資料の受領を確認し、侵害調査へ進みます。 |
取得不能時の対応判断
診断情報を取得できない場合は、保守窓口と対応責任者に理由を共有し、保全と対策の進め方を決めます。取得を試みた時刻、実施した操作、画面に表示された内容を記録できれば、取得不能の経緯も引き継ぎます。
保全のために対策を無期限に延期する運用は避けます。取得不能なら、責任者が保守窓口から得た回答とサービス影響を基に、再取得を試す期限と更新着手の判断を記録します。侵害が疑われ、担当を分けられるなら、更新担当は対策を、調査担当は保全・調査を並行して進めます。分けられない場合は、責任者が保全、サービス影響、対策を一括管理し、実施順と判断理由を残します。保全資料と更新記録を引き継げれば、更新後の侵害調査につなげられます。
▲ 更新前の診断情報保全から更新・侵害調査までの対応手順
修正版への更新と代替パッチの選択
対策は、修正版へのアップデートか、パッチの適用です。開発元は、バージョンアップが困難な利用者向けに、統計処理の対象ファイルを差し替えるパッチをサポート終了バージョンも含めて提供しています。
修正版への更新計画
修正版へ更新できる環境では、痕跡の保全完了を変更作業の開始条件にします。
保全担当から完了報告を受けてから、承認した作業時間と復旧方針に沿って変更へ進みます。
条件 | 対応 |
|---|---|
修正版への更新が可能 | 保全完了後、対象環境と更新先の適合を確認して変更作業へ進みます。 |
更新が困難 | 対象環境で利用できるパッチの適用条件を保守窓口と照合します。 |
対象判定に必要な情報が不足 | 適用可否を未確定として管理し、条件が確定するまで変更を開始しません。 |
修正版は、Apache版・Nginx版・IIS版がVer8.00 Update5、FreeBSD Apache版・Nginx版がVer7.00 Update6です。パッチの入手と適用手順は、開発元のサポート窓口に確認します。サポート窓口は、納品時に渡される契約内容確認書で確認するか、契約した販売店に問い合わせます。利用製品、版番号、OS、Webサーバの種類が分からない環境は、適用先を確定せず変更を開始しません。
更新困難時のパッチ適用
更新が困難な場合は、保守窓口との照合で適用条件が一致したパッチを変更計画に組み込みます。
パッチは統計処理の対象ファイルを差し替えるもので、対象ファイルと差し替え操作は開発元から入手する手順で確認します。条件が一致すれば保全後に適用へ進み、一致を確認できなければ作業を保留して不足情報を整理します。サポート終了版にパッチを適用した環境は、サポート対象の版へ移行する時期を残課題として管理します。
すぐに適用できない場合の回避策
JPCERT/CCは注意喚起で、統計機能を無効化すれば本脆弱性の影響を回避できると案内しています。無効化の手順は、開発元が提供する最新の情報で確認します。無効化は修正版やパッチを適用するまでのつなぎとして扱い、無効化した日時と担当を変更記録に残します。
適用結果と稼働状態の確認
変更作業の完了は、適用成功だけでなく、記録、稼働確認、残課題の引き継ぎまでを条件にします。
変更記録には、作業前後のバージョンまたは適用内容、実施担当、作業結果、製品の稼働状態、保護対象サービスの稼働状態を残します。パッチで版番号が変わらない場合も、何を適用したかを追跡できる形で記録します。
製品と保護対象サービスの双方が正常なら変更作業を完了とし、侵害調査は別に継続します。稼働確認に失敗した場合は完了扱いにせず、変更管理責任者と復旧方針を判断します。未解決事項には担当と対応期限を付け、更新後の調査担当へ引き継ぎます。
更新後の侵害調査と対応完了の判断
修正版やパッチの適用完了と、侵害の有無の判断は別々に管理します。
保全情報を用いた調査
更新後の調査では、取得済みの診断情報を起点に、確認できる資料と対象期間を整理します。
更新前に取得した診断情報は保全のための資料であり、それだけで侵害を自動判定できるとは扱いません。
関連ログを保持している環境では、ログの取得元、対象期間、欠落の有無を整理し、保全済み資料とともに調査担当へ渡します。依頼時は、社内の運用案として次のテンプレートで情報をそろえます。
対象環境：対象サーバーと用途、調査対象の範囲
製品と適用状況：製品名、更新前後のバージョン、パッチ適用の有無
診断情報の取得時刻：取得日時と時刻の基準
更新時刻：更新やパッチ適用を実施した日時
取得できた資料：診断情報、関連ログの一覧、対象期間と取得元
確認された事象：観測した内容、発生時刻、根拠となる資料
未調査事項：未確認の対象、資料の欠落、確認できない期間
担当窓口：情シス側と調査側の連絡先、判断責任者
調査範囲と判定の記録
調査結果は、確認した対象・期間・資料と、判断できない範囲を一組で記録します。
SiteGuardの脆弱性を修正した事実を、そのまま「侵害なし」の根拠にしてはいけません。調査担当から結果を受け取ったら、以下の分岐で扱います。
調査結果・資料の状態 | 判断と対応 |
|---|---|
侵害を疑う事象がある場合 | 根拠資料と未確認事項を添えてインシデント対応責任者へ連携し、追加調査や対処の判断を引き継ぎます。 |
資料が不足している場合 | 調査不能な対象・期間と理由を残し、追加資料の取得可否と次回判断の担当を決めて継続管理します。 |
確認した範囲で異常が見つからない場合 | 調査対象と限界を併記して報告し、「侵害がなかった」との断定には広げません。 |
対応完了と継続管理の条件
対応完了は、修正の適用記録と調査結果を分けたうえで、残る課題の扱いまで決めて判断します。
社内報告を作成する場合は、「確認できた事実」「未確認事項」「実施済み対策」「次の判断と担当」に分けます。攻撃の再現手順や被害企業名は記載せず、自社で確認できた範囲を伝えます。
修正の適用を確認できれば、脆弱性修正の作業は完了として記録します。一方、侵害を疑う事象への対処や資料不足が残る場合は、調査・対処まで一括で完了扱いにせず、担当と再評価時期を付けて継続管理します。調査・対処を完了とする場合も、判断責任者の承認内容と調査上の限界を記録に残します。
対応時の失敗パターンと判断上の注意点
更新前の保全漏れと、更新だけで対応完了とする判断は、別の失敗として防ぎます。
以下は、対応を設計する際に起こりやすい失敗パターンです。
保全前の更新による調査材料の不足
更新を急ぐ場合も、調査材料の保全を先に組み込みます。開発元は、アップデートやパッチの適用で攻撃の痕跡が消える可能性があるとしています。保全前に更新済みなら、残存資料を確保し、調査できない範囲も記録します。
製品名の混同による対象の見落とし
製品を特定できない場合は、対象外とせず管理主体へ引き継ぎます。本件の対象製品はSiteGuard Server Editionです。「SiteGuard」という名称だけで判断すると、調査対象を取り違えるおそれがあります。正式名称と導入先を照合できれば対象判定へ進み、不明なら調査対象に残します。
適用完了と侵害解消の混同
修正の適用と侵害調査の完了は、別々に判定します。更新できたことだけで調査を終えると、既存の侵害の有無を判断しないまま対応を閉じるおそれがあります。セキュリティ製品の利用や管理画面の非公開化だけでも完了とはしません。侵害が疑われる場合は、製品の更新確認に調査範囲を限定せず、影響を受けた可能性のある環境も調査対象に含めます。
失敗 | 起こり得る影響 | 代わりの行動 |
|---|---|---|
保全前の更新 | 調査材料の不足 | 残存資料を保全し、調査の限界を記録します。 |
名称だけで対象外と判定 | 対象の見落とし | 特定できなければ管理主体へ引き継ぎます。 |
適用だけで対応を終了 | 侵害調査の未実施 | 適用結果と調査結果を分けて記録します。 |
更新やパッチ適用を行う場合は、変更作業と稼働確認の負担も計画に含めます。情報を保全する場合は、保存先・アクセス権限・取り扱い担当を決めます。管理画面の公開範囲の見直しは一般的な運用改善です。本件の公式な回避策は、統計機能の無効化です。
▲ 対応時の失敗パターンと推奨される代わりの行動の比較
セキュリティ製品の資産管理と緊急対応体制
防御に使うセキュリティ製品も、利用状況と保守窓口を追跡する資産として管理します。
資産台帳への管理項目の追加
本件の対応を継続的な運用につなげるなら、資産台帳に製品情報と判断を担う担当者をひも付けます。資産台帳とは、利用中の製品や管理主体を記録する一覧です。次の項目を記入欄に設け、環境構成の変更時に更新する担当も決めます。
管理項目 | 記入内容 |
|---|---|
正式製品名 | 略称ではなく製品を識別できる名称 |
稼働環境 | 対象サーバー、OS、構成 |
バージョン | 更新番号を含む導入版 |
管理責任者 | 対応方針を決める担当者 |
保守窓口 | 契約先と連絡方法 |
契約状況 | 契約期間、支援範囲 |
更新方法 | 適用手順、作業権限を持つ組織 |
診断情報の保全先 | 保存場所とアクセス権限 |
管理画面の公開範囲 | 接続可能なネットワークや経路 |
保守契約と対応窓口の整理
委託環境では、作業権限を持つ組織と承認者を分けて記録します。製品の存在が分かっても、自社で更新できるとは限りません。管理責任者には、更新の承認を誰に求めるか、侵害調査を誰へ依頼するかまでひも付けます。
窓口の状況 | 対応の分担 |
|---|---|
保守窓口が判明 | 対策と調査の連絡を一本化し、作業担当と承認者へ共有します。 |
保守窓口が不明 | 契約管理担当と運用担当が契約書や構成資料から管理主体を特定し、管理責任者へ引き継ぎます。 |
対応管理表を使う場合は、各行に担当者・承認者・期限・完了日時を設けます。次の表の「更新前の保全」行は、痕跡が消えるのを避けるための工程です。更新完了だけで対応を閉じない管理にします。
対応順 | 判断・記録する内容 |
|---|---|
対象の把握 | 正式製品名、稼働環境、影響判定の根拠 |
更新前の保全 | 診断情報の取得日時、保全先、取得担当 |
対策の適用 | 承認者、実施内容、適用結果 |
侵害調査 | 調査担当、調査結果、追加対応の判断 |
台帳への反映 | 更新後の構成、残課題、記録の更新担当 |
管理画面の公開範囲と権限の管理
管理画面への接続元を制限できる環境では、運用上必要な経路に絞ります。制限できない事情がある場合は、理由・承認者・代替的な監視方法を記録し、例外を誰が認めたか追跡できる形にします。
管理画面の操作権限も台帳の責任分担と照合します。更新作業を委託するなら、利用する権限と作業後の扱いを承認者が決め、不要になった権限を残さない運用につなげます。
まとめ
SiteGuard Server Editionの統計機能にあるOSコマンドインジェクションの脆弱性（CVE-2026-106931）は、開発元が悪用を確認しています。最初に、稼働中の製品と版、統計機能の状態を確認します。
Ver2.20以降で、Apache版・Nginx版・IIS版はVer8.00 Update5より前、FreeBSD版はVer7.00 Update6より前なら対象です（IIS版のVer3.10〜Ver4.00 Update4は対象外）。統計機能は初期状態で有効です。
対象なら、更新やパッチ適用の前にウェブ管理画面の［診断情報］→［診断情報をダウンロード］で診断情報を取得し、保管します。
修正版への更新か、開発元のパッチを適用します。すぐに適用できない場合は、統計機能の無効化で影響を回避できます。
適用とは別に、保全した診断情報を起点に侵害の有無を調査します。
製品名・稼働環境・管理責任者・保守窓口を資産台帳にまとめておくと、次に同様の脆弱性が公表されたときに対象をすぐ特定できます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
