WordPressの実行環境として使われる「KUSANAGI」に、HTTPヘッダーインジェクションの脆弱性（CVE-2026-117477）が見つかりました。開発元のGMOプライム・ストラテジーとJVNが2026年11月9日に公表しています。原因は、KUSANAGIがWordPressのプロファイル用に作るNginxの設定ファイルの、/wp-admin へのリダイレクトルールです。KUSANAGI 9は修正版（Free / Business / Premium Edition 9.12.3-1、Security / Enterprise Edition 10.7.3-1）へのアップデートで直り、サポートが終わったKUSANAGI 7・8は設定ファイルを1行書き換える緩和策で対応します。Apache httpdで動かしている場合は対象外です。
KUSANAGIの脆弱性 CVE-2026-117477、影響するバージョン
対象は、KUSANAGI 7・8・9で、次のバージョン以前の環境で作成（provision）したWordPressのプロファイルです。
| エディション | 影響を受けるバージョン | 修正版（KUSANAGI 9） |
|---|---|---|
| Free / Business / Premium Edition | 9.12.2-1以前 | 9.12.3-1以降 |
| Security / Enterprise Edition | 10.7.2-1以前 | 10.7.3-1以降 |
脆弱性の種類は「HTTPヘッダーにおけるCRLF文字の不適切な無害化（CWE-113）」です。深刻度は、CVSS v4.0の基本値が5.1、CVSS v3.1の基本値が6.1とされています。想定される影響は、攻撃者が細工したURLにアクセスすると、HTTPレスポンスに任意のヘッダーが挿入される可能性がある、というものです。
CVSSのベクトルを見ると、攻撃に認証は不要（PR:N）ですが、利用者が細工されたURLを開くといった操作が必要（UI:R、v4.0ではUI:A）で、機密性・可用性への直接の影響は評価されていません。いきなりサイトを乗っ取られる種類の脆弱性ではありませんが、ヘッダーを差し込まれることで、閲覧者側に影響する攻撃の足がかりになりうるため、放置してよいものでもありません。
問題は /wp-admin のリダイレクトで $uri を使っていたこと
公式の告知によると、問題の行は、WordPressのプロファイルのNginx設定にある次のリダイレクトルールです。/wp-admin で終わるURLに、末尾のスラッシュを付けて転送するためのものです。
rewrite /wp-admin$ $scheme://$host$uri/ permanent;修正後は、転送先の組み立てに $uri ではなく $request_uri を使います。
rewrite /wp-admin$ $scheme://$host$request_uri/ permanent;Nginxの $uri は、リクエストのURIをデコード・正規化したあとの値で、$request_uri はクライアントが送ってきた元のURIです。URLに改行を表すコード（CRLF）をエンコードして含めると、デコード後の値をそのままLocationヘッダーに入れた場合に、ヘッダーの区切りとして解釈されてしまうおそれがあります。今回の修正は、この転送先にデコード前の値を使うように変えたものと読み取れます（この仕組みの説明は、告知の修正内容とNginxの変数の仕様から整理したもので、告知自体は修正前後の行だけを示しています）。
KUSANAGI 9は dnf upgrade、7・8は設定の書き換えで対応
KUSANAGI 9：修正版へアップデート
KUSANAGI 9は、全エディションで修正版が出ています。アップデートは次のコマンドで行います。
# dnf upgrade kusanagiSecurity EditionとEnterprise Editionで、kusanagi autoupdate コマンドによるミドルウェアの自動更新を有効にしている場合は、この修正は自動で適用されるとされています。自動更新にしているつもりでも、設定が有効になっているかは一度確かめておくと安心です。
すぐにアップデートできない場合は、各WordPressプロファイルの /etc/opt/kusanagi/nginx/conf.d/{プロファイル名}.wp.inc にある上記の行を修正後の形に書き換え、kusanagi nginx --reload（--reload に対応していない場合は kusanagi nginx）でNginxをリロードまたは再起動します。
KUSANAGI 7・8：サポート終了のため緩和策のみ
KUSANAGI 7と8はサポートが終わっていて、アップデートは提供されません。各プロファイルの /etc/nginx/conf.d/{プロファイル名}_http.conf と /etc/nginx/conf.d/{プロファイル名}_ssl.conf の2つのファイルで同じ行を書き換え、kusanagi nginx でNginxを再起動します。
注意したいのは、緩和策が「プロファイルごと」の設定だという点です。1台のサーバーで複数のWordPressサイトを動かしている場合は、すべてのプロファイルの設定ファイルを直す必要があります。7・8はファイルが http と ssl の2つに分かれているので、片方だけ直して終わりにしないようにしましょう。
自分のサーバーが対象か確かめる手順
- Webサーバーが Nginx か Apache httpd かを確認する（Apache httpd なら対象外）
- KUSANAGIのメジャーバージョン（7・8・9）とエディションを確認する
- KUSANAGI 9なら、インストールされている kusanagi パッケージのバージョンが修正版以降かを確認する
- 各プロファイルの設定ファイルで、
/wp-admin$のrewrite行が$uri/のままになっていないかを検索する
最後の確認は、アップデートや書き換えを済ませたあとの見直しにも使えます。設定ファイルを独自に編集している環境では、アップデートで上書きされない場合も考えられるので、実際の行を目で見ておくのが確実です（アップデート時に独自編集した設定がどう扱われるかは、告知には書かれていません）。
WordPress本体の問題ではないが、運用側で見落としやすい
今回の脆弱性は、WordPress本体やプラグインではなく、実行環境が自動で作る設定ファイルの1行に原因があります。WordPressの管理画面からは見えず、プラグインの脆弱性スキャンでも引っかかりにくい場所なので、「WordPressもプラグインも最新だから大丈夫」と考えていると見落としやすいタイプだと考えます。
特に気になるのは、サポートが終わったKUSANAGI 7・8で動き続けているサイトです。更新が来ない以上、今回のように設定を手で直す対応がこれからも必要になりえます。今回の修正を機に、サーバーのミドルウェアがいつまでサポートされるのかを確認し、移行の予定を立てておくのがよいでしょう。当サイトでは先日、WordPressの更新処理のRCE脆弱性が悪用された件や、WordPressもBrotliの脆弱性の影響を受けうる件も取り上げました。本体だけでなく、PHPやWebサーバーなど足回りの更新もあわせて点検しておきたいところです。
出典（一次情報）
- KUSANAGI「KUSANAGIにおけるHTTPヘッダーインジェクションの脆弱性について（CVE-2026-117477）」（2026年11月9日）
- JVN「JVNVU#92635551 KUSANAGIにおけるHTTPヘッダーインジェクションの脆弱性」（2026年11月9日）
2026年11月11日時点の情報です。
コメント