KUSANAGIのWordPress設定にヘッダー注入の脆弱性 更新と旧版の緩和策を確認

GMOプライム・ストラテジーは2026年11月9日、KUSANAGIで作成したWordPressプロファイルのNginx設定に、HTTPヘッダーインジェクションの脆弱性があると公表しました。CVE-2026-117477として管理され、細工されたURLへアクセスすると、HTTPレスポンスに任意のヘッダーを挿入される可能性があります。対象のKUSANAGI 9は修正版へ更新し、更新できない環境やサポート終了済みの7・8では、公式の緩和策を実施してください。

対象はKUSANAGI上でWordPressサイトを保守する管理者や、複数プロファイルを運用する制作・運用チームです。WordPress本体やプラグインを更新するだけで済ませず、Nginxのリダイレクト設定を確認する必要があります。Apache httpdを使用する構成は対象外です。以下は開発元のSecurity AdvisoryとJVNの公表情報を確認したニュースと対応手順の整理で、本サイトが攻撃再現や実環境試験を行ったという意味ではありません。

影響範囲はOS名よりプロファイルとWebサーバーで確認する

開発元は、KUSANAGI 7・8・9のうち、Free／Business／Premium Editionの9.12.2-1以前、Security／Enterprise Editionの10.7.2-1以前でプロビジョニングしたWordPressプロファイルを影響対象としています。数字の9と10はエディションごとのパッケージ系列であり、KUSANAGI 9という製品世代と同じ軸で比較しないようにします。

確認の単位は仮想マシン一台だけではありません。同じサーバーに複数のWordPressプロファイルがあるなら、利用するWebサーバーと設定ファイルをプロファイルごとに整理します。Apacheで動くサイトが一つあることを理由に、同居するNginx側のサイトまで対象外とは判断できません。構成を保守会社へ委託している場合は、サイト名とプロファイル名を対応づけて確認を依頼します。

• KUSANAGIの世代とエディション、導入済みパッケージの版を記録する
• 各WordPressプロファイルがNginxかApache httpdかを確認する
• Nginxの対象設定に公式告知のリダイレクト行があるかを確認する
• 更新または緩和策の反映状況をプロファイルごとに記録する

公式告知の影響はHTTPレスポンスへのヘッダー挿入です。任意コード実行やWordPressへの無条件の管理者ログインまで確認されたと広げてはいけません。公表資料には今回の悪用確認の記載はなく、被害件数や攻撃期間も示されていません。認証情報の強制変更など、公式が求めていない対応を一律の必須作業にはしません。

原因はリダイレクト先に使うURIの扱い

問題の箇所は、WordPress管理画面のパスに末尾のスラッシュを付けるNginxのrewriteルールです。公式の修正は、リダイレクト先に含める変数を$uriから$request_uriへ変更します。入力を受け取るPHPコードの修正ではなく、Webサーバーがレスポンスを作る段階の設定変更です。

修正前:
rewrite /wp-admin$ $scheme://$host$uri/ permanent;

修正後:
rewrite /wp-admin$ $scheme://$host$request_uri/ permanent;

NGINXの変数仕様では、$uriは正規化された現在のURI、$request_uriは引数を含む元の要求URIです。同じURLに関係する変数でも保持する値が違うため、リダイレクトの出力先で交換可能なものとして扱えません。この性質は設定を理解するための説明であり、独自の置換案を作る根拠にはしないでください。修正は開発元が指定する行を基準にします。

NGINXのrewrite仕様では、置換先がhttp://、https://、$schemeで始まる場合にクライアントへリダイレクトを返し、permanentは301応答を返します。そのため、管理画面の表示だけでなく、リダイレクト応答のLocationと通常の遷移を確認することが、今回の修正後の検査につながります。

KUSANAGI 9はエディション別の修正版へ更新する

KUSANAGI 9のFree／Business／Premium Editionは9.12.3-1以降、Security／Enterprise Editionは10.7.3-1以降が修正版です。開発元は次の更新コマンドを案内しています。作業前に現在の設定とパッケージ版を保存し、通常の保守手順に従ってバックアップと復旧方法を確認してください。

dnf upgrade kusanagi

Security EditionとEnterprise Editionでは、kusanagi autoupdateでミドルウェアの自動更新を有効にしている場合、この修正は自動適用されると案内されています。ただし「自動更新を契約している」と「当該環境で有効になって実行された」は別です。保守担当者は導入済みの版と実行結果を確認し、自動更新という名称だけで対応済みと記録しないようにします。

更新後は、対象プロファイルの設定を確認し、通常の管理画面への転送が維持されるかを調べます。独自のテンプレートや構成管理から設定を配布している場合、その配布元に古い行が残っていないかも点検することを本サイトは提案します。現在のファイルが正しくても、次の再配備で過去の設定へ戻れば対応が持続しないためです。

更新できないKUSANAGI 9の緩和策

KUSANAGI 9をすぐに更新できない場合、公式告知は各WordPressプロファイルの次のファイルを対象に、前述のrewrite行を変更するよう案内しています。{プロファイル名}は実環境の名前へ読み替えます。対象の行以外をまとめて書き換えたり、同名変数を全ファイルで一括置換したりする手順ではありません。

/etc/opt/kusanagi/nginx/conf.d/{プロファイル名}.wp.inc

変更後はNginxをリロードまたは再起動します。公式のコマンドは次のとおりです。--reloadへ対応していない環境では後者を使用します。再起動が必要な場合は、受付中の通信や監視への影響を考慮して作業時間を決めてください。

kusanagi nginx --reload

# --reloadに対応していない場合
kusanagi nginx

NGINXのコマンドライン仕様では、-tは構文と参照ファイルの検査、-Tは検査に加えて設定内容を出力する機能です。反映前の検査は有用ですが、KUSANAGI環境の実際の実行ファイルと設定先を指定できていることが前提です。別に導入されたnginxを検査して、稼働中の設定を検査したつもりにならないようにします。出力には環境情報が含まれるため、共有先も限定します。

KUSANAGI 7・8は緩和と移行を分ける

KUSANAGI 7と8はサポート終了済みで、今回のアップデートは提供されません。開発元は各WordPressプロファイルのHTTP用とSSL用の設定ファイルを変更し、Nginxを再起動する緩和策を案内しています。一方だけを修正して終わらせず、利用している両方の設定を確認します。

/etc/nginx/conf.d/{プロファイル名}_http.conf
/etc/nginx/conf.d/{プロファイル名}_ssl.conf

# 指定のrewrite行を変更後
kusanagi nginx

今回の行を直すことは、この脆弱性への緩和です。サポート終了を解消したり、他の問題へ更新が提供される状態に戻したりするものではありません。本サイトの提案として、緩和策の実施日と担当者を記録したうえで、サポートされる環境への移行計画を別の作業として管理してください。移行前にはPHPやDB、プラグインの互換性を検証し、今回の緩和を移行完了まで先延ばしにしないことが重要です。

修正後は設定と通常応答を対で確かめる

以下は本サイトが提案する確認方法です。自分が管理する検証環境で、まず設定の差分と読み込み対象を確認し、次に通常のURLで応答を比較します。攻撃用の文字列を本番や第三者のサイトへ送る必要はありません。正常系の試験は脆弱性が絶対に残らないことの証明ではなく、設定変更で通常運用を壊していないかを確認する工程です。

curl -sS -D - -o /dev/null https://example.com/wp-admin

example.comは管理下の検証用ドメインへ置き換えます。Locationの転送先が意図するサイトとパスであるか、想定外のループがないか、通常の管理画面操作が継続できるかを確認します。外部公開側にCDNやロードバランサーがある場合は、外部からの応答と管理下のオリジン側の結果を対応づけます。途中の装置が返した301を見て、KUSANAGI側の修正を確認したとしないためです。

リロードの成功も確認してください。NGINXの公式プロセス制御資料では、設定再読込時に構文や適用を確認し、失敗した場合は古い設定で動き続ける挙動を説明しています。サービスが停止しなかったことだけでは、新設定が有効になったとは判断できません。作業ログとエラーログを確認し、失敗していれば設定を修正して再検査します。

最終記録は、サイト名、プロファイル名、KUSANAGI世代・エディション、更新前後の版、対象ファイル、反映方法、通常遷移の結果を一組にします。複数台構成では全台、HTTPとHTTPSでは各経路を確認し、未対応の対象を残したままサーバー全体を完了扱いにしないようにします。

今回の対応で混同しないこと

本件はKUSANAGIのWordPress向けNginx設定に関する問題です。NGINX本体の修正版への更新だけ、WordPress管理画面へのアクセス制限だけ、あるいはWordPress本体の更新だけで公式対策を置き換えたとは扱いません。対象プロファイルを特定し、KUSANAGI 9は対応版へ更新し、更新できない環境は指定行の変更と反映を完了させることが中心です。

CVSSはJVNと開発元が4.0で5.1、3.1で6.1を示しています。本記事の構造化メタにはCVE-2026-117477のCVSS 4.0基本値5.1を使用します。方式が違う値を混ぜて深刻度が上がった、下がったと解釈せず、実際に影響するプロファイル数と更新可否から保守作業を決めてください。