SiteGuard Server Editionの脆弱性で悪用確認

合同会社ロケットボーイズの報道によると、EGセキュアソリューションズは、WAF製品「SiteGuard Server Edition」の統計機能に関する脆弱性「CVE-2026-106931」が悪用されたことを確認したと公表しました。脆弱なバージョンで統計機能が有効な場合、サーバー上でrootまたはSYSTEMの権限を使い、任意のOSコマンドを実行されるおそれがあると記事は説明しています。ただし、これは製品の全利用者が侵害されたという意味ではありません。影響を受ける条件は製品の種類やバージョン、統計機能の設定によって異なります。

記事によると、修正版はApache・Nginx・IIS版がVer8.00 Update5、FreeBSDのApache・Nginx版がVer7.00 Update6です。開発元は修正版への更新を勧め、直ちに更新できない場合は統計機能の無効化を案内したとされています。また、更新やパッチ適用で攻撃の痕跡が消える可能性があるとして、EGセキュアソリューションズは修正前に診断情報を取得・保管し、必要に応じて侵害の有無を調べるよう案内したと報じられています。

要は、まず自社の製品版・バージョン・設定が影響条件に当たるか確認し、修正前の情報を保全したうえで対策を進めるよう呼びかけられています。

ねえねえ、Xでは、公式の注意喚起や関連ニュースを情報共有として広げる反応が見られたよ。パッチ適用で攻撃痕跡が消えるかもしれない、と心配して、先に診断情報を保全しよう、という指摘もある。影響の条件や権限の上がり方を踏まえて、対象の環境を確認して、という声もあった。確認できた投稿の範囲だけどね。

城壁を守る門番自身が合鍵を持たれちゃったみたいな話で、聞いてるだけでゾワゾワしちゃう！

これって「修正前にログを保存しなきゃ」とか「直ちに更新できないなら機能をオフに」って言われると、現場の人は『えっ、うちのサーバーもすでに突破されて裏口作られてるんじゃ…！？』ってパニックになりそうじゃない？

それに、直接サポート契約を結んでいるところには一般公表よりも前に個別で通知がいっていたっていう報道もあるから、「じゃあ代理店経由や委託先任せにしてたうちは、その空白期間に狙われてたかも…！？」なんて疑心暗鬼が広がるのも無理ない気がするんだよね。

Xの反応を見て、あたしもほぼ同じところで引っかかった。いちばん共感したのは、パッチを当てたら攻撃の痕跡が消えるかもしれないから、先に診断情報を保全しようっていう指摘。現実的に考えて、現場って「早く直さなきゃ」で動いちゃうじゃない？ でも直した瞬間に、やられたかどうか調べる材料まで消えちゃうなら本末転倒だよね。順番を間違えないでって声が出るのは、すごく納得できる。

それから、影響条件や権限の話を踏まえて、まず自分の環境が対象かどうか確認しようっていう声にも賛成。流行りのニュースみたいに「やばい、拡散しなきゃ」で終わらせないで、うちのサーバーは当てはまるのかを落ち着いて見る人がいるのは頼もしいと思う。

公式の注意喚起や関連ニュースをみんなで共有して広げる流れも、地味だけど大事だと思う。気づかないまま放置されるのがいちばん怖いから、情報が回ること自体に意味があるよね。あたしも、直す前にまず保全、その次に対策っていう空気づくりに乗っかりたい。

俺っちが引っかかるのは、攻撃の痕跡が消えると言われて、直すより先に診断情報を取れという順番だ。開発元は一般公表の前に、直接サポート契約の利用者へ個別通知していたと報じられている。その知らせを受けた側は、診断情報を先に保管する段取りを踏めたのか。報道だけでは、そこが見えねえ。

知らせが届く差と、直すことで調査材料を失う怖さ。皆様が引っかかったのは、もっともでございます。ただ、不安をそのまま侵害の証拠にはできません。

今回、開発元の原文でも、一般公表に先立つ直接サポート契約者への脆弱性・対策の通知は確認できましたが、当時の通知に保全手順まで含まれていたかは分かりません。 アーサーさんの問いには、通知本文と受領・作業記録が必要です。

ミーアさんが重視した保全については、JPCERT/CCも開発元の説明を受け、診断情報を取得してから更新するよう勧めています。 ただし「痕跡が消える可能性」は、必ず全記録が消えるという意味ではございません。

ジェミーさんの心配する裏口の存在や、通知を受けなかった間の被害は、この資料では確認できません。Xで心配が共有されたこととも別問題です。悪用確認についても、JPCERT/CCは開発元の報告として記載しており、独立した被害認定が二つあるわけではありません。 通知の到達状況と個別環境の調査結果を分けて確かめることが、残る疑問への答えになります。