KUSANAGIでprovisionしたWordPressのNginx設定に、HTTPヘッダーインジェクションの脆弱性CVE-2026-117477が2026年11月9日に公表されました。細工されたURLを開いた利用者への応答に、任意のヘッダーを差し込まれるおそれがあります。この記事では、影響を受ける版と修正版、未修正の設定行を見つけるコマンド、更新できない環境やKUSANAGI 7・8で行う書き換えの手順を整理します。この記事の内容は、11月10日時点で公開されている情報にもとづくものです。
まとめ：KUSANAGI 9は更新後に設定行を確認、7と8はrewrite行の書き換え
KUSANAGI 9は、Free・Business・Premiumが9.12.3-1以降、Security・Enterpriseが10.7.3-1以降で修正済みです。KUSANAGI 7と8にアップデートは提供されないため、rewrite行の$uriを$request_uriに書き換えます。Apache httpdで動かしている環境は対象外です。
更新のあとは、全プロファイルの設定に古いrewrite行が残っていないかをgrepで確かめてください。CVSSは6.1で利用者のクリックを要するため、夜間の緊急停止までは不要と判断します。reloadなら接続を切らずに反映できるので、今週中に片づける案件です。多数のサイトを点検しきれないときは、脆弱性診断・セキュリティ診断で設定とアプリケーションの確認を受け付けています。
CVE-2026-117477の影響を受ける版とApache httpdが対象外となる条件
JVNVU#92635551とGMOプライム・ストラテジーのセキュリティ告知は、対象をKUSANAGI 7・8・9でprovisionしたWordPressのプロファイルとしています。OSやミドルウェアの欠陥ではなく、プロファイルに書き込まれるNginx設定の問題です。
KUSANAGI 7・8・9のエディション別に見る影響版と修正版の対応表
| 系列 | エディション | 影響を受ける版 | 対応 |
|---|---|---|---|
| KUSANAGI 9 | Free・Business・Premium | 9.12.2-1以前 | 9.12.3-1以降へ更新 |
| KUSANAGI 9 | Security・Enterprise | 10.7.2-1以前 | 10.7.3-1以降へ更新 |
| KUSANAGI 7・8 | 全エディション | 上記の版以前 | 緩和策のみ |
11月9日時点の最新はKUSANAGI 9の9.12.6-1とEnterprise・Security向けの10.7.6-1です。修正版より新しいので、これから更新するなら最新まで上げれば足ります。
Apache httpdは対象外、httpd-behind-nginxは設定行で判定
告知は「Apache httpdを使用している場合は対象外」と明記しています。問題の行がNginxの設定にあるためです。一方、Apache httpdの前段にNginxを置くhttpd-behind-nginxモードについて、告知に個別の記載はありません。この構成では対象外と決めつけず、後述のgrepで該当行の有無を見て判断します。
CVSS基本値6.1と5.1の読み方とクリックを要する攻撃の前提条件
CVSS 3.1の基本値は6.1、CVSS 4.0では5.1です。どちらも認証は不要ですが、利用者の操作が前提になっています（3.1のUI:R、4.0のUI:A）。攻撃者が細工したURLを踏ませる必要があり、サーバーへ直接侵入される種類の欠陥ではありません。JVNと告知に、悪用が確認されたとの記載は11月10日時点でありません。
注意したいのは脆弱性スキャナの扱いです。同日時点でNVDのAPIには本CVEが登録されておらず、NVDのデータに頼るスキャナでは検出できない可能性があります。「スキャンで何も出なかった」を対応済みの根拠にせず、版番号と設定行を直接見てください。
Nginxのrewrite行で$uriのCRLFがLocationヘッダーへ入る仕組み
告知が示す修正前の行は、次の1行です。/wp-adminへのアクセスを、末尾にスラッシュを付けたURLへ301で転送しています。転送の基本はリダイレクトの種類とNginxでの設定方法で確認できます。
rewrite /wp-admin$ $scheme://$host$uri/ permanent;正規化された$uriと元の値を保つ$request_uriの違いをnginx仕様で確認
nginxの公式文書によると、$uriは正規化された現在のURIです。正規化では%XX形式のエンコードが復号されるため、改行を表す文字列を含むURLは、$uriの中で本物のCRとLFに変わります。対して$request_uriは、引数を含む元のリクエストURIをそのまま保持します。
Nginx設定の静的解析ツールgixyのHTTP Splitting解説も、rewriteなどの指示子で$uriを使う箇所を要注意とし、$request_uriへの置き換えを勧めています。告知の修正内容もこれと同じ考え方です。
行頭の指定がない/wp-admin$の一致範囲と挿入ヘッダーが招く被害
正規表現/wp-admin$には行頭の^がありません。URLの末尾が/wp-adminであれば途中のパスは問われず、そこに含まれた改行が$uriを通ってLocationヘッダーに出力されます。これがCWE-113に分類される理由です。
CWE-113の解説は、この種の欠陥から派生する攻撃としてクロスサイトスクリプティングやキャッシュ汚染を挙げています。今回の告知が述べている影響は、応答への任意のヘッダー挿入までです。CDNや共有キャッシュを前段に置くサイトは、応答が保存されて他の利用者へ広がる経路があるぶん、優先順位を上げてください。
手元のKUSANAGIで版番号と未修正のrewrite行を調べる確認コマンド
調査は読み取りのみで、サービスに影響しません。版番号と設定行は別々に確かめます。
rpmで版番号を読みautoupdateの設定状態を確認する手順
rpm -q kusanagi
kusanagi autoupdate status1行目の結果を、対応表の影響版と比べます。2行目はSecurity EditionとEnterprise Editionで使えるautoupdate statusです。「autoupdate is on.」と出ていれば、自動更新が有効と分かります。
grepで全プロファイルの該当行を洗い出して修正漏れを検出する方法
告知が示す設定ファイルの場所は、KUSANAGI 9と7・8で異なります。次のコマンドは、修正前の文字列をそのまま探します。
# KUSANAGI 9
grep -nF 'rewrite /wp-admin$ $scheme://$host$uri/' /etc/opt/kusanagi/nginx/conf.d/*.wp.inc
# KUSANAGI 7・8
grep -nF 'rewrite /wp-admin$ $scheme://$host$uri/' /etc/nginx/conf.d/*_http.conf /etc/nginx/conf.d/*_ssl.conf1行でも出力されれば、そのプロファイルは未修正です。何も出なければ、告知どおりの形の行は残っていません。独自に書き換えた設定は文字列が一致しないことがあるので、$uriを含むrewrite行を目視でも確かめておくと確実です。
KUSANAGI 9をdnf upgradeで更新し設定行の修正まで確かめる手順
更新できる環境では、緩和策よりパッケージ更新を選びます。手作業の編集が残らず、次回以降のprovisionにも修正が効くからです。
dnf upgrade kusanagiの実行後に版番号と該当行を再確認する順番
dnf upgrade kusanagi
rpm -q kusanagi
grep -nF 'rewrite /wp-admin$ $scheme://$host$uri/' /etc/opt/kusanagi/nginx/conf.d/*.wp.inc告知に、更新時に既存プロファイルの設定がどう書き換えられるかの説明はありません。だから3行目のgrepを省かないでください。更新後も行が残っていた場合は、次章の緩和策で直します。
Security EditionとEnterprise Editionで自動更新する条件
両エディションは、kusanagi autoupdateでミドルウェアの自動更新を有効にしていれば、この修正が自動で適用されると告知に書かれています。有効かどうかは前章のkusanagi autoupdate statusで分かります。ただ、有効でも更新の失敗には気づきにくいものです。版番号とgrepの確認は同じように行います。
更新できない環境とKUSANAGI 7・8で行うrewrite行の書き換え手順
変更は$uriを$request_uriにする1か所だけです。ただし設定ファイルはプロファイルごとにあるので、複数サイトを載せたサーバーでは全件に行います。
KUSANAGI 9の緩和策で編集する.wp.incとreloadまでの実行手順
対象はプロファイルごとの{プロファイル名}.wp.incです。PROFILEを実際の名前に置き換え、控えを取ってから編集します。
cp -p /etc/opt/kusanagi/nginx/conf.d/PROFILE.wp.inc /root/PROFILE.wp.inc.20261110
# 修正前
rewrite /wp-admin$ $scheme://$host$uri/ permanent;
# 修正後
rewrite /wp-admin$ $scheme://$host$request_uri/ permanent;
kusanagi nginx --test
kusanagi nginx --reloadkusanagi nginxの公式文書によると、--testは設定の確認のみを行い、--reloadは既存のセッションを切らずに設定を読み直します。--reloadに対応していない版では、告知のとおりオプションなしのkusanagi nginxで再起動してください。
KUSANAGI 7・8の_http.confと_ssl.confを両方直す緩和手順
書き換える内容は同じですが、対象は/etc/nginx/conf.d/の{プロファイル名}_http.confと{プロファイル名}_ssl.confの2ファイルです。片方だけ直すと、残ったプロトコル側に欠陥が残ります。
cp -p /etc/nginx/conf.d/PROFILE_http.conf /root/PROFILE_http.conf.20261110
cp -p /etc/nginx/conf.d/PROFILE_ssl.conf /root/PROFILE_ssl.conf.20261110
# 両ファイルのrewrite行を書き換えたあと
nginx -t
kusanagi nginx告知が7・8で案内している反映方法は、kusanagi nginxによる再起動です。短時間の再起動を伴うので、アクセスの少ない時間帯を選びます。
クエリ付き/wp-adminの転送先が変わる点を確かめるcurlの手順
修正後の$request_uriは引数まで含むため、スラッシュはクエリ文字列の後ろに付きます。加えてnginxのrewriteの仕様では、元の引数が転送先へ足されます。告知はこの点に触れていません。/wp-adminにクエリを付けて開く導線があるサイトは、転送先を見ておいてください。
curl -sI https://example.com/wp-admin
curl -sI "https://example.com/wp-admin?check=1"1行目のLocationが/wp-admin/を指していれば、通常の転送は保たれています。本番のURLに改行を含む文字列を送って試す必要はありません。設定行の確認のほうが確実で、ログも汚しません。
判断：緩和策で済ませてよいKUSANAGI 7・8と移行へ進むべき環境の条件
今回の欠陥そのものは1行の変更で塞げます。難しいのは、塞いだあとの環境をどうするかです。
緩和策で止めてよいのは廃止日が決まっている環境だけという判断
KUSANAGI 7・8で緩和策のままにしてよいのは、サイトの廃止や移行の日付がすでに決まっている場合に限ります。告知のとおりアップデートは提供されないため、次の欠陥が見つかったときに修正版を待つ選択肢がありません。問い合わせフォームや会員機能を持つサイト、ログイン利用者が多いサイトは、今回の緩和策とあわせてKUSANAGI 9または別基盤への移行計画を立ててください。
WAFで改行を含むURLを止めるだけの対応は、採用しません。規則の抜けや経路の迂回が残り、設定を直す手間はわずかだからです。設定の修正を先に行い、WAFは追加の層として扱います。
新規provisionとバックアップ復元で古い行が戻る失敗の防ぎ方
告知は影響をprovisionしたプロファイル単位で定めています。修正前の版のまま新しくプロファイルを作ると、該当行を持つ設定が増えると考えるのが自然です。先に更新してからprovisionします。設定ファイルをバックアップから戻した場合や、別サーバーからプロファイルを移した場合も、古い行が復活しかねません。
対策としては、grepの1行を定期点検の項目に入れるのが手軽です。WordPress本体やプラグインの更新と違い、Nginx設定の差分は管理画面に出てきません。点検項目全体の組み立てはWordPressセキュリティ対策の攻撃面ごとの設定、社内で回すか外注するかの線引きはWordPress保守運用の作業範囲と判断基準にまとめています。
よくある質問
KUSANAGIの脆弱性CVE-2026-117477について、運用の現場で迷いやすい点に答えます。
KUSANAGIのFree Editionも対象ですか？
対象です。Free Edition、Business Edition、Premium Editionは9.12.2-1以前が影響を受け、9.12.3-1以降で修正されています。更新に使うコマンドはdnf upgrade kusanagiです。エディションによる違いは修正版の番号で、Security EditionとEnterprise Editionは10.7.2-1以前が対象、10.7.3-1以降が修正版にあたります。Apache httpdで動かしている環境は、どのエディションでも対象外です。
dnf upgradeを実行すれば対応は完了しますか？
更新は告知が示す対策ですが、既存プロファイルの設定がどう書き換わるかまでは説明されていません。完了の判定には、更新後の版番号の確認に加えて、該当するrewrite行が残っていないかのgrepまで含めてください。行が残っているプロファイルがあれば、緩和策と同じ手順で$request_uriに書き換え、Nginxをreloadします。
緩和策を入れればKUSANAGI 8を使い続けてもよいですか？
今回の欠陥に限れば緩和策で塞げますが、使い続ける理由にはなりません。KUSANAGI 7と8はサポートを終了しており、アップデートは提供されないと告知に明記されています。次に別の欠陥が公表されたとき、修正版を受け取れない状態が続きます。廃止の日付が決まっていないサイトは、移行の計画を立てる前提で緩和策を入れてください。
すでに攻撃を受けたかどうかは調べられますか？
告知とJVNに、侵害の痕跡や判定方法の記載はありません。告知が述べる影響は応答へのヘッダー挿入で、サーバー上のファイルの改ざんには触れていません。確認するなら、プロファイルのアクセスログで、末尾が/wp-adminのURLのうち%0dや%0aを含むリクエストを探します。ただし、見つかっても攻撃の成否までは判定できません。
WEXALやリバースプロキシを併用している環境も対象ですか？
告知は、WEXALやプロキシ運用の有無で対象を分けていません。判定の基準は、影響版のKUSANAGIでprovisionしたプロファイルかどうかと、Apache httpdのみで動かしていないかどうかです。プロキシ運用では複数のNginxが動くため、対象ファイルにgrepをかけて該当行を確認し、反映はkusanagi nginxの公式文書に沿って行ってください。
関連記事
- CVE-2026-119977：WordPress更新中のRCEと全25系列の修正版・安全な更新手順：WordPress本体側の欠陥と更新の進め方を扱います。
- WordPressの高速化手順：原因の切り分けとキャッシュ・DB・画像の改善【7.1系対応】：KUSANAGIを選ぶ動機になる表示速度の改善手順です。
- API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策：Webサーバーの設定より内側にあるAPIの防御をまとめています。
- nginxの最新バージョンは1.31系（安定版1.30）｜バージョン確認コマンド・更新手順と変更点【2026年10月】：Nginx本体の版と更新手順の確認に使えます。
- WordPressのバックアップ設計：WP-CLIでの取得・世代管理・復元テストの手順【7.1系対応】：設定を変える前の控えと復元の考え方を解説しています。
