国産WAF SiteGuard の穴が KEV 入り｜証拠を残して更新・個人と組織の対応

はじめに

2026年10月14日、EGセキュアソリューションズが、自社の WAF（Web アプリケーションファイアウォール）「SiteGuard Server Edition」に OS コマンドインジェクションの脆弱性 CVE-2026-106931 があると公表しました。同じ日に JVN と JPCERT/CC も注意喚起を出しています。公表の時点で、開発元はすでに悪用を確認していると書きました。悪用されると、製品が動くサーバーの上で root または SYSTEM の権限で任意の OS コマンドを実行されるおそれがあります。10月20日には、米 CISA が悪用の確認された脆弱性の一覧 KEV に載せました。

Web サイトを攻撃から守るための部品が、逆にサーバー全体の権限への足場になる。この記事のゴールは、読み終えたときに次の 3 つが分かっていることです。この穴が社会のどこに効き、放置すると何が起きるのか。更新で何が直り、何が残るのか。そして、個人と、事業者・自治体・ホスティングといった社会インフラの側で、それぞれ誰が何をすればよいのか。 状況は 2026年10月24日時点の一次情報で書いています。

🛡️ 1. SiteGuard とは ── サーバーに組み込む国産 WAF

WAF は「アプリの前に立つ検問」

WAF（Web Application Firewall）は、Web サイトに届くリクエストの中身を検査して、攻撃らしいものを止める仕組みです。ふつうのファイアウォールが「どの番号のポートへの通信を通すか」を見るのに対して、WAF は「フォームに入力された文字列に SQL の命令が紛れていないか」「スクリプトを埋め込もうとしていないか」といった、アプリの層の中身を見ます。

アプリそのものの脆弱性をすぐに直せないとき、WAF は時間を稼ぐ手段になります。開発元も製品ページで、WAF を「Webサイトの脆弱性を修正することが難しい場合の対策や万一の事態に備えた保険的対策」と位置づけています。

置き場所の 3 つの型

WAF は、どこに置くかで 3 つに分かれます。

• クラウド型: 事業者のネットワークを経由させて検査する。サーバー側に何も入れない
• ゲートウェイ型: Web サーバーの手前に置いたリバースプロキシで検査する
• ホスト型: Web サーバー（Apache・nginx・IIS）のモジュールとして同じサーバーの中で動く。ネットワークの構成を変えずに入れられる

SiteGuard シリーズには 3 つの型がそろっていて、今回の Server Edition はホスト型です。開発元の製品ページは「Webサーバーのモジュールとして動作するホスト型WAF（ソフトウェア）製品」と説明し、攻撃の検出状況を集計してグラフで見せる統計・レポートの機能を備えるとしています。今回の穴は、この統計機能の中にあります。

ホスト型の利点は、サーバーを増やさずに入れられることです。その代わり、守る仕組みが守られる側と同じサーバーの中で、同じ OS の上で動きます。この性質が、第 3 節の話の土台になります。

なぜ国内で多いのか

SiteGuard は国内の会社が開発する製品で、開発元はトップページで「導入実績150万サイト以上」「国内WAF市場シェアNo.1」と掲げています（どちらも 2023年12月期の市場調査にもとづく開発元の表記で、シリーズ全体の数字です）。JPCERT/CC も今回の注意喚起で「当該製品が国内で広く利用されていることを確認しています」と書いています。

広がった理由の一つは、ホスティング事業者がサーバーに標準で付けて配ったことです。開発元の過去の発表によると、2015年にはファーストサーバの「Zenlogic ホスティング」が採用し、さくらインターネットの「さくらの専用サーバ」と「さくらのクラウド」で標準提供が始まりました。さくらインターネットは 2020年の告知で、通常は数万〜数十万円かかる WAF が「さくらのVPS、さくらのクラウド、さくらの専用サーバ PHY、さくらの専用サーバでは無料でご利用いただけます」と案内しています。さくらの VPS のマニュアルは 2026年10月時点でも、配布しているインストールファイルと対応 OS（Ubuntu 22.04／24.04、AlmaLinux、Rocky Linux、Windows Server など）を載せています。

🗓️ 2. 何が起きたか ── 個別通知から KEV 入りまで

今回は、開発元が公表の 2 週間あまり前に、サポート契約のある利用者へ個別に知らせていた点が特徴です。

• 9月29日: 開発元が、直接サポート契約のある利用者へ、脆弱性の存在と対策（バージョンアップ・個別パッチ）を通知
• 10月14日: 開発元が「SiteGuard Server EditionにおけるOSコマンドインジェクションの脆弱性(緊急)」を公表し、「すでに悪用が確認されています」と明記。同日、JVN が JVN#88474777 を「緊急」として公開し、JPCERT/CC が注意喚起（JPCERT-AT-2026-0032）を出しました。JVN によると、情報セキュリティ早期警戒パートナーシップにもとづいて開発元が IPA に報告し、JPCERT/CC が調整した案件です。CVE も JPCERT/CC が採番機関として発行しています
• 10月20日: CISA が KEV に追加。同じ日に追加されたのは計 6 件でした
• 10月23日: KEV に記された、米国の連邦機関の対応期限（追加から 3 日）

2 つの深刻度 ── 「緊急」と「CVSS 8.5」

CVSS の評価ベクトルは AV:L/AC:L/AT:N/PR:L/UI:N、つまり「攻撃元はローカル（AV:L）、低い権限が要る（PR:L）、利用者の操作は不要」です。インターネットから認証なしで一撃、という評価ではありません。それでも JVN が「緊急」とし、CISA が KEV に載せたのは、実際に悪用されていることと、成功したときにサーバー全体の権限が取られることが重いからです。CISA が CVE レコードに付けた評価（SSVC）も、悪用「active」、技術的な影響「total（全面的な制御）」でした。

攻撃の具体的な手口、誰が攻撃したのか、被害の規模は、10月24日時点で開発元・JPCERT/CC・CISA のいずれも公表していません。本記事でも攻撃の手順や再現の方法には触れません。

🌐 3. 社会的影響 ── 守る部品が root への足場になる

「低い権限」と「root」の間にある段差

サーバーの上では、プログラムごとに権限が分かれています。Web アプリは通常、www-data や apache のような権限の低いアカウントで動き、乗っ取られても OS 全体には手が届かないようにしてあります。この段差が、侵入されたときの被害を一つのサイトの中に閉じ込める壁です。

今回の評価ベクトルが示すのは、その壁の内側に低い権限で入った者が、WAF の統計機能を通じて root または SYSTEM まで上がれるという形です。ここからは筆者の読みですが、低い権限の足場は、Web アプリの脆弱性、盗まれた FTP や SSH のアカウント、同じサーバーに同居する別のサイトなど、いくつもの経路で得られます。たとえば今週の PHP の重大な穴は、成功すれば Web のワーカーの権限でコードを動かせるものでした。単体では「低い権限」で止まる侵入が、同じサーバーに修正前の SiteGuard があると、サーバー全体に広がりうる。守るために入れた部品が、壁を越える段差になる構図です。

誰が困るか

ホスト型 WAF は、WAF を「入れなければならない」側、つまり個人情報や決済を扱い、セキュリティ対策を求められるサイトほど入っている可能性が高い製品です。国内でどの業種に何台あるかを示す一次の統計は見当たりませんでしたが、開発元の 150 万サイトという表記と、JPCERT/CC の「国内で広く利用」という確認から、影響の範囲が一部の組織にとどまらないことは言えます。

防御の製品が狙われるのは、今回が初めてではない

攻撃者にとって、防御のための製品は都合のよい標的です。インターネットとの境目に置かれ、広い権限を持ち、しかも「守る側の製品だから」と更新が後回しにされやすいからです。国内の事例では、ランサムウェアの侵入口の 6 割以上を VPN 装置が占めています（サイバー攻撃まとめの記事で整理しました）。

今回は、開発元が公表の前に契約者へ個別に知らせ、更新が難しい人のためにサポートが終わった版にもパッチを用意し、さらに証拠の残し方まで案内しました。守る側の製品の穴を、どう利用者の手元で閉じてもらうか。その段取りとしては、丁寧に組まれた対応だと筆者は見ています。

⚠️ 4. 対応しないとどうなるか ── KEV 入りの意味と前例

KEV に載るとは「実際に悪用された」ということ

KEV（Known Exploited Vulnerabilities）は、CISA が「実際に悪用された証拠がある」と判断した脆弱性だけを集めた一覧です。CVE は年に数万件発行されますが、KEV に載るのはその一部で、2026年10月23日版の収録は 1,756 件です。理屈の上で危ない穴ではなく、すでに誰かが使った穴の一覧だと考えると分かりやすいでしょう。

今回の KEV の記載には、ふだんあまり見ない項目が付いています。

• 対応期限は追加から 3 日（10月20日追加、期限 10月23日）。2026年6月に出た CISA の拘束的運用指令 BOD 26-04 にもとづく期限です
• forensicTriage: Yes。BOD 26-04 は、これが付いた穴について、期限内の修正に加えて「システムが侵害されていないかを評価するフォレンジックのトリアージ」を求めています
• ランサムウェアでの利用は「Unknown（不明）」

BOD 26-04 が直接縛るのは米国の連邦機関だけです。それでも、「直す」と「侵入されていないか調べる」を同じ期限で求めるという CISA の扱いは、この穴の重さを示す物差しとして日本の利用者にも参考になります。JPCERT/CC も、対策とあわせて「侵害調査の実施を検討してください」と書いています。

root を取られたサーバーで起きること

root（Windows では SYSTEM）は、そのサーバーの上でできないことがほぼない権限です。一般に、そこから先は次のように広がります。

• 改ざん: そのサーバーにあるすべてのサイトのページを書き換えられる。決済画面を書き換えればカード番号の抜き取り（Web スキミング）にもつながる
• 情報窃取: 設定ファイルやデータベースから、会員情報や接続情報を持ち出せる。同居している別のサイトのデータも対象になる
• ランサムウェア: ファイルを暗号化し、盗んだデータの公開をちらつかせて脅す
• 裏口の常駐と踏み台化: OS の起動のたびに動く仕掛けを置いたり、ログを消したりできる。別の組織への攻撃の中継点にも使われる。root で置かれた裏口は、穴を塞いだあとも残る

前例：守る製品の穴は、修正後も尾を引く

境界の防御製品が悪用された例は、KEV に数多く残っています。そのうち、「修正版を入れれば終わり」にならなかった例を 1 つ挙げます。

Ivanti の VPN 装置の件で、CISA は緊急指令 ED 24-01 を出し、2024年2月2日までに該当する装置をすべてネットワークから切り離すよう連邦機関に命じました。理由として CISA は、攻撃者が「工場出荷時への初期化を経ても生き残るルートキット級の常駐」を置いている可能性を前提にすべきだと書いています。防御製品の上で高い権限を取られると、更新だけでは信頼を取り戻せないことを示した例です。

悪用までの速さも縮んでいます。Mandiant（Google Cloud）の分析では、悪用された脆弱性が実際に使われるまでの平均日数は、2018〜2019年の 63 日から、2023年には 5 日（外れ値を除く）まで短くなりました。今回はすでに悪用が確認された状態で公表されているので、「様子を見る」時間はもう残っていません。

🔧 5. なぜ更新が必要か ── 何が直り、何が残るか

更新の前に「診断情報」を保存する

今回の対応で、ふつうの更新と最も違うのがこの手順です。開発元は、アップデートやパッチを当てると「攻撃の痕跡が消える可能性があります」として、適用の前に「診断情報」をダウンロードして保管するよう求めています。場所はウェブ管理画面の［診断情報］→［診断情報をダウンロード］です。JPCERT/CC も、痕跡を保全したうえでのアップデートを推奨としています。

順番を逆にすると、侵入されていたかどうかを後から確かめる材料を、自分の手で消してしまうかもしれません。更新は穴を塞ぐ作業、診断情報の保存は過去を確かめる材料を残す作業で、目的が別です。

修正の中身と 3 つの選択肢

開発元によると、パッチは「統計処理の対象ファイルを差し替える」もので、サポートが終わった版にも提供されています。JPCERT/CC は、統計機能を無効化すれば影響を回避できるとしています。どの方法でも、穴の入口である統計機能の経路を閉じる、という点は同じです。

なお、SiteGuard には攻撃パターンの定義（トラステッド・シグネチャ）の更新が別にあります。今回の修正は製品のプログラム側の修正で、シグネチャの更新とは別の作業です。開発元は対策を「最新版へのアップデート、またはパッチの適用」と書いています。

「更新すれば大丈夫」の範囲と範囲外

🏢 6. 二層の対応 ── 個人と社会インフラ

同じ「更新する」でも、VPS を 1 台持つ個人と、多くのサイトや利用者のデータを預かる組織とでは、確かめる範囲と説明する相手が違います。

左の流れは、サポート契約を通じて組織に届く経路です。右の流れは、契約の外にいる人が自分で告知を見つけなければならない経路です。個人の層の多くは、右の側にいます。

個人の層：「無料で付いてきた WAF」の持ち主として

個人で特に気をつけたいのは、VPS やクラウドで、事業者が無料で配っている SiteGuard を自分で入れた場合です。さくらの VPS のマニュアルは、製品のバージョンアップについて「お客様にてバージョンアップの実行を行っていただきます」と書いています。入れたのは自分なので、更新するのも自分です。数年前にスタートアップスクリプトで入れて、そのまま忘れている、というのがいちばん危ない状態です。

レンタルサーバーで、管理画面から「WAF」を ON にしているだけの場合は、WAF の本体を管理しているのは事業者です。どの製品が使われているかは事業者ごとに違い、筆者が確認した範囲（さくらインターネット、ロリポップ！、KAGOYA の告知の一覧）では、10月24日時点で今回の CVE に触れた告知は見つかりませんでした。気になる場合は、契約している事業者の告知を確認します。

社会インフラの層：組織として、委託先と事業者まで

• 自社で運用しているサーバー: 資産台帳から SiteGuard Server Edition（旧 SiteGuard Lite を含む）の入ったサーバーを洗い出し、診断情報の保存 → 更新 → 侵害調査の順に進めます。JPCERT/CC は、侵害調査の実施の検討もあわせて求めています
• 委託先: サイトの制作や保守を外部に任せている企業や自治体は、委託先に「SiteGuard を使っているか」「版と更新の完了日」「診断情報を保存したか」「侵入の痕跡を調べた結果」を聞きます。個人情報保護法は委託先への監督を求めています。委託先を起点にした漏えいの経緯はサイバー攻撃まとめの記事で整理しています
• ホスティング・クラウド事業者: SiteGuard を標準搭載や無料提供の形で配った事業者は、自社で管理している分の更新に加えて、利用者が自分で入れた分に更新を促す立場にあります。利用者の多くは、9月29日の個別通知の外にいます
• 基幹インフラ事業者: 2026年10月1日に施行された能動的サイバー防御法のもとで、重要なシステムのインシデントを国に報告する義務を負っています。制度の概要はサイバー攻撃まとめの記事にまとめました

🔍 7. 確かめ方（要点だけ）

• 入れているか: 自分で入れた覚えがあるか、スタートアップスクリプトや構築メモに SiteGuard の名前がないか、サーバーに SiteGuard のウェブ管理画面があるかを確かめます。旧名の「SiteGuard Lite」も同じ系譜です
• 対象の版か: Ver2.20 以降で、Apache・nginx・IIS 版は Ver8.00 Update5 より前、FreeBSD 版は Ver7.00 Update6 より前なら対象です。ただし IIS 版の Ver3.10〜Ver4.00 Update4 は対象外です
• 統計機能: 初期値は有効です。無効にしていなければ対象と考えます
• 更新の前に: ウェブ管理画面の［診断情報］→［診断情報をダウンロード］で保存してから、更新かパッチに進みます

CVE レコードで対象として挙がっているのは、Server Edition の Apache 版・nginx 版・IIS 版と、FreeBSD の Apache 版・nginx 版です。同じ「SiteGuard」の名前を持つ WordPress 用のプラグイン「SiteGuard WP Plugin」や、クラウド型の Cloud Edition、ゲートウェイ型の Proxy Edition は、対象の一覧に入っていません。

🔧 技術者の所感

✅ まとめ

• CVE-2026-106931 は、ホスト型 WAF「SiteGuard Server Edition」の統計機能にある OS コマンドインジェクション。低い権限を持つ攻撃者が root・SYSTEM の権限で OS コマンドを実行しうる。開発元が悪用を確認し、CISA が 10月20日に KEV に載せた
• 開発元の表記で導入実績 150 万サイト以上、JPCERT/CC も国内で広く利用と確認。ホスティング事業者が無料・標準で配ってきた経緯もあり、守るための部品がサーバー全体への足場になる
• 放置すれば、改ざん・情報窃取・ランサムウェア・裏口の常駐。防御製品の穴は、Ivanti の例のように更新後も尾を引く
• 修正版は Ver8.00 Update5（FreeBSD 版は Ver7.00 Update6）。パッチと統計機能の無効化もある。更新の前に診断情報を保存し、更新後に侵入の痕跡を調べる
• 個人は「自分で入れた WAF を思い出して更新」、社会インフラは「棚卸し・委託先の確認・侵害調査・報告」まで

この記事で、今回の穴が社会のどこに効き、更新で何が直って何が残り、自分がどちらの層で何をすればよいかまで、たどり着けたはずです。次の一手は、個人なら自分の VPS やサーバーに SiteGuard が入っていないかを確かめ、入っていれば診断情報を保存してから更新すること。組織なら、委託先と事業者に、版と更新の完了日と、侵害調査の結果を確かめることです。

よくある質問（FAQ）

Q. レンタルサーバーの管理画面で WAF を ON にしています。自分で何かする必要はありますか？

A. 共用のレンタルサーバーでは、WAF の本体を管理しているのは事業者で、利用者が SiteGuard を更新する手段はふつうありません。どの WAF 製品を使っているかは事業者ごとに違います。筆者が確認した範囲（さくらインターネット、ロリポップ！、KAGOYA）では、2026年10月24日時点で今回の CVE に触れた告知は見つかりませんでした。気になる場合は契約している事業者の告知やサポートで確かめます。VPS やクラウドで自分で SiteGuard を入れた場合は話が別で、更新は自分の仕事です。

Q. WordPress の「SiteGuard WP Plugin」を使っています。対象ですか？

A. CVE レコードで対象として挙がっているのは、SiteGuard Server Edition の Apache 版・nginx 版・IIS 版と FreeBSD 版だけです。WordPress 用のプラグイン「SiteGuard WP Plugin」は名前が似ていますが、対象の一覧には入っていません。プラグインはプラグインとして、ふだんどおり最新に保っておきます。

Q. 実際に悪用されていますか？

A. はい。開発元は 10月14日の公表の時点で「すでに悪用が確認されています」と書き、CISA は 10月20日に KEV に載せました。CVE レコードに付いた CISA の評価も悪用「active」です。ただし、攻撃の手口や被害の規模は、10月24日時点で公表されていません。ランサムウェアでの利用は KEV で「Unknown（不明）」です。

Q. すぐに更新できないときはどうすればいいですか？

A. 開発元は、版を上げにくい人向けに、統計処理の対象ファイルを差し替えるパッチを提供しています（サポートが終わった版を含む）。JPCERT/CC は、統計機能を無効にすれば影響を回避できるとしています。どちらの場合も、先に診断情報を保存してから作業します。

Q. 更新の前に診断情報を保存するのはなぜですか？

A. 開発元が、アップデートやパッチの適用で「攻撃の痕跡が消える可能性があります」と書いているためです。今回は悪用が確認された状態で公表されているので、自分のサーバーがすでに攻撃されていたかどうかを後から確かめる必要があります。その材料を、更新の作業で消さないための手順です。

Q. WAF を入れると、かえって危ないのでしょうか？

A. WAF そのものを外すべきだ、という話ではありません。SQL インジェクションのような攻撃を手前で止める効果は、今回の件で変わっていません。言えるのは、WAF も他のソフトウェアと同じく、更新し続けて初めて守りになるということです。入れたら、OS や Web サーバーと同じ更新の対象に数え、使っていない機能（今回なら統計機能を使っていないなら、その機能）を止めておくと、攻撃が届く場所を減らせます。

関連記事

• PHP に重大な RCE 2件｜8.4.27 などへ今夜更新・自分のサーバーの確かめ方 — 同じ週の Web サーバーの穴と、二層の対応
• 日本企業はどこから破られたのか｜2025〜2026年の侵入口とAI時代の守り方 — 入口の 6 割が VPN 装置、委託先、能動的サイバー防御法
• PwnEscape（CVE-2026-99999）｜VMのパケットがホストを書き換える穴と確かめ方 — 権限の壁を越える、もう一つの穴

参考

• EGセキュアソリューションズ「SiteGuard Server EditionにおけるOSコマンドインジェクションの脆弱性(緊急)」
• JVN#88474777
• JPCERT/CC 注意喚起（JPCERT-AT-2026-0032）
• CVE-2026-106931（CVE レコード）
• CISA KEV の JSON フィード
• CISA BOD 26-04
• さくらの VPS マニュアル「SiteGuard Server Edition（WAF）」
• CISA ED 24-01（Ivanti Connect Secure）