GMOプライム・ストラテジーは2026年11月9日、KUSANAGIで用意したWordPressの環境に、HTTPヘッダーインジェクションの脆弱性「CVE-2026-117477」があると公表しました。対象は、一定の旧バージョンで作成されたWordPress向けのNginx設定です。Apache httpdを使用している場合は対象外とされています。開発元の案内・JVNの脆弱性情報
自社サイトの管理を外注している場合は、「WordPressを最新にしているか」だけでなく、KUSANAGIの利用有無、Webサーバーの種類、対象設定への対応を保守担当者に確認してください。KUSANAGI 9には修正版があり、サポート終了済みの7・8には設定を書き換える緩和策が案内されています。
自社サイトは対象？ WordPressの利用だけでは決まらない
KUSANAGIは、WordPressなどのCMSを動かすためのサーバー環境です。今回問題になったのは、KUSANAGIがWordPress用に作成する設定のうち、Nginxのリダイレクトルールです。リダイレクトとは、アクセスしたURLから別のURLへ自動的に移動させる仕組みを指します。
開発元とJVNが挙げているのは、KUSANAGI 7・8・9の次の版・エディションで作成されたWordPressのプロファイルです。プロファイルは、ここではサイトごとの設定のまとまりと考えると分かりやすくなります。
- Free／Business／Premium Edition： 9.12.2-1およびそれ以前
- Security／Enterprise Edition： 10.7.2-1およびそれ以前
加えて、Apache httpdを使っている場合は対象外です。NginxとApache httpdは、ブラウザーからの要求を受けてページなどを返すWebサーバーのソフトウェアです。対象条件の原文
「WordPressを使っている」「Nginxを使っている」という情報だけで、今回の対象とは判断できません。保守担当者には、KUSANAGIで用意したWordPressの設定なのか、どの版・エディションで作られたものか、該当する設定が残っていないかを確認してもらいましょう。同じサーバーで複数のサイトを運営している場合は、サイトごとの確認が必要です。
起きるおそれがあることと、分かっていないこと
JVNは、利用者が攻撃者の細工したURLにアクセスすると、サーバーが返すHTTPレスポンスに任意のヘッダーを挿入される可能性があると説明しています。
HTTPヘッダーは、ページ本文とは別に、ブラウザーへ応答の扱い方などを伝える情報です。HTTPヘッダーインジェクションは、この情報に意図しない内容を差し込まれる問題を指します。今回の脆弱性は、URLを開く利用者の操作が成立条件に含まれています。
JVNの評価は、CVSS v4.0で5.1、v3.1で6.1です。評価方式が異なるため、同じ尺度の数値として比較するものではありません。JVNの説明と評価
本稿で確認した公表資料では、実際の悪用や被害の有無は示されていません。影響の確認は、点数や目に見える不具合だけでなく、自社の構成と設定に基づいて進めてください。
KUSANAGI 9は修正版へ。更新できない場合は設定の修正を相談
KUSANAGI 9で、この脆弱性が修正された版は次のとおりです。
- Free／Business／Premium Edition： 9.12.3-1以降
- Security／Enterprise Edition： 10.7.3-1以降
これは今回の修正を含む最初の版です。実際の更新先は、作業時点の最新案内と利用環境を照合して決めます。開発元は、KUSANAGIのパッケージを更新する方法を案内しています。WordPress管理画面で本体やプラグインを更新する操作とは、確認する対象が異なります。修正版と作業方法
Security／Enterprise Editionでは、KUSANAGIのミドルウェア自動更新を有効にしている場合、この修正は自動的に適用されるとされています。自動更新を契約名だけで判断せず、有効化の状況と実際の適用結果を担当者に確認してもらいましょう。
すぐに更新できないKUSANAGI 9には、各WordPressプロファイルのNginx設定を書き換え、Nginxをリロードまたは再起動する緩和策があります。対象は /etc/opt/kusanagi/nginx/conf.d/{プロファイル名}.wp.inc です。設定変更を行う担当者に公式手順を渡し、反映と動作確認まで依頼してください。
KUSANAGI 7・8には更新の提供なし。緩和策と移行を分けて考える
KUSANAGI 7・8はサポートを終了しており、今回のアップデートは提供されません。開発元は、各WordPressプロファイルの次の設定ファイルを修正し、Nginxを再起動する緩和策を案内しています。
/etc/nginx/conf.d/{プロファイル名}_http.conf/etc/nginx/conf.d/{プロファイル名}_ssl.conf
7・8と、更新できない9の緩和策は、該当する転送ルール内の変数 $uri を $request_uri に置き換えるものです。設定ファイル内の文字列を一括置換する指示ではありません。 対象の行とファイルを公式の修正前・修正後の例で照合し、技術担当者が作業してください。
緩和策の完了とは別に、サポート中の環境へ移す計画も相談しましょう。今回の設定を直しても、サポート終了済みの環境全体が継続的に保守されるようになるわけではありません。
保守会社からは、対象サイトと対応結果を受け取る
事業者側では、次の内容が分かる形で回答してもらうと、対応漏れを確認しやすくなります。
- 対象の有無と理由： KUSANAGIの利用有無、7・8・9の区別、エディション、Webサーバーの種類、確認したサイト。
- 実施する対処： 更新するパッケージと版、または公式の緩和策。すぐに対応できない場合の予定と当面の扱い。
- 作業前の準備： 設定と必要なデータのバックアップ、サイトへの影響、問題が出た場合の復旧方法。
- 反映と確認の結果： 各サイトの対象設定を確認したか、緩和策で必要なリロード・再起動を終えたか、作業後にエラーがないか。
- 残る課題： 旧環境の移行など、今回の作業では完了しない対応と担当者。
作業後の確認例は、サイトの表示、WordPress管理画面への移動・ログイン、問い合わせや注文など事業に関わる機能です。設定修正が関わるURLの転送も、技術担当者に確認してもらってください。注文や決済を試す場合は、実際の請求が発生しない検証手順を使います。
サイトの更新を誰に頼み、作業前後に何を確認するかは、関連ガイドの「WordPressとPHPの更新は別。サイト運営者が確認したい役割と進め方」でも整理しています。今回はPHPではなくKUSANAGIのNginx設定が対象ですが、更新対象と保守の担当範囲を分けて確認する考え方は共通です。
情報確認日：2026年11月10日。作業時は、開発元とJVNの最新案内を確認してください。