タグ: Wordpress

WordPressでネットショップを動かしているなら、WooCommerceの次の版の中身は早めに見ておいて損はありません。WooCommerceの開発者向けブログで、11.3のベータ版の案内が公開されました。正式版は2026年11月9日の週に出る予定で、コミット数は1,310、参加した開発者は117人とされています。かなり大きな更新です。ここでは、お店の運営や制作の現場に関わりそうな変更を中心に拾ってみます。

セールのバッジに値引き額や割引率を出せる

店舗の担当者にいちばん分かりやすいのは、On-Sale Badgeブロックの変更です。これまでのバッジは「Sale」と表示するだけでしたが、11.3からは表示内容を3通りから選べるようになります。自由な文言、値引きの金額、割引率の3つです。

金額と割引率には前後に言葉を付けられるので、「最大」「お得」のような添え字を組み合わせた表示も作れます。バリエーションのある商品では、いちばん大きな割引を「Up to」付きで見せ、お客さまが色やサイズを選ぶと、その組み合わせの割引に切り替わる仕組みです。選んだものがセール対象でなければバッジは消えます。既定は今までどおり「Sale」なので、更新しただけで見た目が変わることはありません。

あわせて、Product、Featured Product、Product Categories Listなどのブロックに色や余白、枠線の設定が増え、商品ギャラリーのスマートフォンでのスワイプも指の動きに素直についてくるよう改善されたそうです。公式のブロックテーマPurpleがWordPressのテーマディレクトリから入手できるようになった点も、ブロックテーマでショップを組む人には覚えておきたい話です。

返品ポリシーのページを設定画面で指定できる

地味ながら実務に効きそうなのが、返金と返品のポリシーのページを「設定」の「高度な設定」にある「ページ設定」で選べるようになる変更です。選んだページは固定ページの一覧でも目印が付きます。

さらにWooCommerceが、そのページへの構造化データを自動で出力するとされています。返品条件をどこに書いているかを検索エンジンに伝えるために、これまでテーマやプラグインで独自にマークアップを足していた場合は、更新後に二重になっていないかを確かめておくと安心です。

注文の分析に決済方法が加わり、データベースにも手が入る

Analyticsの注文レポートに決済方法の列と絞り込みが加わります。クレジットカードと銀行振込でどれだけ売れたかを、追加のプラグインなしで見られるようになるわけです。CSVの書き出しにも列が入ります。

この機能のために、注文の集計テーブルに列と索引が追加されます。既存の注文には裏側の定期処理で500件ずつ値が埋められていく仕組みで、埋まるまでは古い注文の決済方法が空のまま表示されます。注文数の多いお店では索引を作る間にディスクの読み込みが増えるため、開発者ブログでは更新を落ち着いた時間帯に行うよう勧めています。MySQL 5.7のような古いデータベースでは、テーブル全体の作り直しが起きるとも書かれています。

もうひとつ、新しくWooCommerceを入れたサイトでは、古い「レポート」メニューが表示されなくなります。既存のお店には影響しませんが、マニュアルや社内の手順書で「WooCommerce、レポート」とメニューの位置を案内している場合は、新規の構築案件から書き換えが必要になりそうです。

来年のPHPの要件に向けた通知が出はじめる

11.3では、PHP 7.4または8.0で動いているお店の管理画面に、閉じられる形の通知が出るようになります。これは2027年2月に予定されている11.6で、必要なPHPの版が8.1以上に上がることへの予告です。11.3から11.5までは今のPHPのままでも更新でき、既存のショップが要件の変更で止まることもないと説明されています。

WooCommerceの集計では、PHP 7.4の店舗がおよそ7%、8.0が2%とのことです。少数とはいえ、長く運用している中小企業のショップほど古い環境のまま残っていることは珍しくありません。推奨は8.3以上とされているので、通知が出たら「WooCommerce」の「ステータス」でPHPの版を確かめ、検証用のコピーで決済、送料と税の計算、受注処理、テーマや拡張機能の動きを一通り試してから本番を切り替える流れが現実的です。年末の繁忙期を避けて要件の変更を2月に置いたのは、そうした準備の時間を見込んだものだと読めます。

制作会社の立場では、自社で手を入れた機能の確認も欠かせません。11.3では、REST APIで返金を作るときに明細の金額が検証されるようになり、矛盾した値はエラーで返るようになります。商品APIでセール中の絞り込みと商品の指定を組み合わせたときの結果も変わります。外部の在庫管理や会計の仕組みとつないでいるショップは、正式版が出る前にベータで動きを見ておくと、年末の売り場で慌てずに済みそうです。

PHPの次の版であるPHP 8.6は、11月19日の正式公開に向けてリリース候補の段階に入っています。PHPの公式wikiに載っている予定表では、9月22日に機能の追加が締め切られ、10月21日にRC4が出て、11月5日のRC5を経て正式版になる流れです。新しい書き方の話題も多い版ですが、WordPressやPHPで作った中小企業のサイトを預かる立場からすると、まず気になるのは「上げたときに何が変わるか」です。php-srcの変更点をまとめたUPGRADINGファイルと、Laravel Newsの解説をもとに、現場で先に確かめておきたい項目を並べてみます。

その1 セッションの既定値が安全側に変わる

いちばん影響がありそうなのが、セッションに関する設定の既定値です。php.iniで明示していない場合、session.use_strict_modeは1に、session.cookie_httponlyは1に、session.cookie_samesiteはLaxになります。セッションIDの固定化を防ぎ、JavaScriptからセッションのクッキーを読めなくし、ほかのサイトからのPOSTにはクッキーを付けないという、いまでは推奨とされる設定が最初から入る形です。

多くのサイトにとっては良い変化ですが、外部の決済サービスから戻ってくるときにPOSTでセッションを引き継ぐ作りや、JavaScriptでセッションのクッキーを読んでいる古い仕組みは、動きが変わる可能性があります。UPGRADINGでは、こうした作りではSameSiteをNoneにし、あわせてsecure属性を有効にするよう案内されています。独自のフォームや会員機能をPHPのセッションで作っているサイトは、検証環境で決済や問い合わせの流れを一度通しておくと安心です。

その2 日本語の正規表現で使うmbregexが非推奨になる

日本の制作現場で見落としやすいのがこれです。mbstringの正規表現機能(mbregex)が非推奨になりました。理由は、下支えしているOnigurumaというライブラリの保守が止まっているためとされています。mb_eregやmb_ereg_replaceは、日本語の文字列を扱う古いプラグインや自作の関数で使われていることがあります。すぐに動かなくなるわけではありませんが、非推奨の警告がログに出はじめるので、preg_系の関数への置き換えを計画しておくとよさそうです。

その3 細かな非推奨がまとめて入る

今回は小さな非推奨がかなり多く入っています。たとえばis_integer()やis_long()、is_double()、doubleval()といった別名の関数、spl_object_hash()、finallyの中でのreturn、define()の3番目の引数などです。どれも長く使われてきたものなので、年季の入ったテーマや自社で書いたコードに残っていることがあります。ログに警告が大量に出てディスクを圧迫する、という事故はPHPの版上げで毎回のように見かけるので、本番の前に検証環境でエラーログを眺めておきたいところです。

その4 文字列や配列の関数の振る舞いが少し変わる

非推奨ではなく、振る舞いそのものが変わるものもあります。trim()、ltrim()、rtrim()は、既定で改ページ文字も取り除くようになりました。array_filter()は、モードの引数に不正な値を渡すとエラーを投げます。preg_grep()は、正規表現の処理に失敗したとき途中までの配列ではなくfalseを返すようになりました。普段の使い方で困ることは少ないはずですが、入力値の整形やCSVの読み込みのような処理では、結果が変わらないかを確かめておくと確実です。

その5 書く側がうれしい新機能

もちろん新しい機能もあります。値を上限と下限の間に収めるclamp()関数が加わり、min()とmax()を組み合わせる書き方を置き換えられます。引数の一部だけを先に決めて関数を作る部分適用(partial function application)、時間の長さを表すTime\Durationクラス、readonlyのプロパティに既定値を持たせられる変更も入りました。テーマやプラグインの開発で使えるのは、WordPress本体や配布先の環境がPHP 8.6を前提にできるようになってからなので、当面は自社の案件や社内の道具で試すくらいが現実的です。

PHPの版上げは、レンタルサーバーやホスティングの管理画面で切り替えるだけに見えて、実際にはテーマ、有効なプラグイン、独自のコードのすべてが新しい版で動くかにかかっています。正式版が出てすぐに上げる必要はありませんが、セッションまわりとmbregexの2点だけでも、いまのうちに手元のサイトで使っていないかを確かめておくと、年明けからの移行がずっと楽になるはずです。

10月28日、WordPress 7.1.4がセキュリティ修正版として公開されました。公式の版ごとの解説ページによると、直した脆弱性は22件で、17項目に分けて記載されています。3週間前の7.1.3で直したのは7件だったので、件数だけを見てもかなり大きな修正版です。

ただ、今回の中身は数の多さより、どこに集まっているかのほうが興味深いものでした。ひとつはWordPressが自分を更新する仕組みそのもの、もうひとつは「投稿者」や「寄稿者」といった、記事を書ける権限から始まる不具合です。ここでは公式の記載と、Patchstackや海外のホスティング事業者が修正のコードを読んで書いた解説をもとに、論点を整理してみます。

短い間隔で続く7.1系の修正版

まず背景から。7.1系は9月に公開されてから、セキュリティ修正版が続いています。ある事業者のまとめでは、9月17日の7.1.1、9月22日の7.1.2、10月6日の7.1.3、そして今回の10月28日と、6週間で4本目です。月に1回まとめて更新する運用だと、修正が公開済みなのに古い版のまま過ごす期間が長くなる、という指摘もされていました。

また、同じ解説によると、10月29日の時点で今回の22件にはCVE番号や深刻度の点数がまだ付いていません。7.1.3の7件も同様だそうです。点数が出るのを待って対応を決める運用だと、判断が遅れることになります。この解説は、点数ではなく「攻撃する側が先に何を持っている必要があるか」で優先順位を考えるよう勧めていて、これは現場でもそのまま使える考え方だと思います。

更新作業の数秒間だけ開いていた入口

今回もっとも目を引くのは、アカウントがなくても狙える唯一の不具合が、WordPressの更新処理の中にあったことです。公式の記載では「コア更新中の競合状態(race condition)により、遠隔からコードを実行されるおそれ」とだけ書かれています。

Patchstackの解説によると、WordPressは本体やプラグインを更新するとき、配布ファイルをwp-content/upgrade/の下に展開してから所定の場所へ写します。このフォルダーはウェブサーバーから普通に見える場所にあり、しかも展開先の名前は推測しやすいものでした。さらに、事前の片付けの処理が、フォルダーの中身を一覧表示させないためのindex.phpまで消していたといいます。

その結果、更新にかかる数秒のあいだ、完全なWordPress一式が推測できる場所に置かれ、条件によっては一覧からも名前が読める状態になっていました。展開された一式には設定前のインストーラーも含まれるため、そこへ間に合えば、他人のサイトの中で自分の用意したデータベースに向けて導入を走らせることができた、というのがPatchstackの見立てです。

修正では、展開先のフォルダー名に16文字のランダムな文字列を付け、index.phpを作り直して消さないようにし、展開したフォルダーからwp-config.phpを写さないようにしました。Patchstack自身は、狙える時間が非常に短いことから「実用的な攻撃とは言いにくい」と評価しています。一方で、アカウントも操作も要らず、更新のたびに同じ時間帯が訪れる点は軽く見ないほうがよさそうです。

実務的に大事なのは、PHPで動くファイアウォール系のプラグインではこれを防げないという指摘です。展開された一式は自分のファイルからWordPressを起動するため、サイト側の防御の仕組みがそもそも読み込まれません。対策はウェブサーバーの側で行うもので、wp-content/upgrade/への外からのアクセスを断ち、フォルダーの一覧表示が無効になっているかを確かめるよう勧められています。ApacheであればOptions -Indexesの設定が該当します。共用のレンタルサーバーでは事業者の設定次第なので、気になる場合は問い合わせてみるのが確実です。

寄稿者の下書きが管理者の画面で動く

残りの大半は、ログインできるアカウントを持つ人が起点になる不具合です。Patchstackの一覧では、17項目のうち多くが「寄稿者(Contributor)以上」で成り立つ保存型のクロスサイトスクリプティング(XSS)でした。

寄稿者は記事を書いて承認待ちに出せますが、公開はできません。WordPressは、こうした権限の人が保存する内容からスクリプトを取り除く仕組みを持っています。今回の修正の多くは、その取り除く処理か、表示する処理のどこかをすり抜けていたものです。保存型のXSSは、その内容を開いた人のブラウザーで動きます。寄稿者の下書きを開くのは、たいてい承認する編集者や管理者です。

中小企業のサイトでは、外部のライターや社内の別部署に寄稿者のアカウントを渡しているところも少なくありません。権限を絞っているから安心、と考えていた運用ほど、今回の修正の意味は大きいはずです。Patchstackは更新に加えて、寄稿者以上のアカウントを誰が持っているかを見直すよう勧めています。使っていない外部アカウントが残っていないか、この機会に棚卸ししておくとよさそうです。

動くブロックとdata属性の盲点

寄稿者起点の不具合のうち、Patchstackによると17項目中7項目が、Interactivity APIという同じ仕組みに集中していました。これは、画像のライトボックスやナビゲーションのモバイル用メニュー、ページを読み直さずに次の一覧を出すクエリーループなど、標準のブロックをブラウザー上で動かすための仕組みです。

根っこは共通しています。WordPressのHTML検査(KSES)は、どんなdata-属性でも値を問わず通していました。そしてInteractivity APIの指示は、data-wp-interactiveやdata-wp-bind--hrefのように、すべてdata-属性で書かれます。そのため寄稿者が記事の中に指示を書き込むと、検査を素通りし、訪問者がページを開いたときにブラウザー側の処理がそれを実行してしまう、という構図でした。

そこから、リンク先にjavascript:の値を差し込む、サーバー側では断っていたonclickなどの属性に値を結び付ける、JavaScriptの基本的なオブジェクトに手が届く名前を使う、といった複数の抜け道が見つかっています。訪問者のブラウザーのタブを固まらせる不具合も含まれていました。修正は、検査の段階、PHPの処理の段階、ブラウザー側の処理の段階の三か所で行われています。

テーマやブロックを自作している制作者にとっては、更新後の動作も気になるところです。ある解説によると、影響が出るのは、今回断られるようになった属性(イベントの属性、javascript:のURL、object要素の危険な属性)に値を結び付けている場合に限られます。サーバー側で取り除かれた場合はデバッグログに通知が出るので、更新後に一度ログを確かめておくと安心です。

二つの読み手が食い違うと検査はすり抜ける

今回の修正を並べて読むと、もうひとつ共通する型が見えてきます。同じ内容を二つの処理が別の解釈で読み、片方で確かめたはずのものが、もう片方では違う意味になってしまう、という型です。

たとえばブロックの区切りは<!-- wp:paragraph -->のようなHTMLコメントで保存され、サーバーのPHPと編集画面のJavaScriptの両方で読まれます。Patchstackによると、両者は「空白」とみなす文字の範囲が違っていて、特殊な空白を使うと、PHPにはただのコメント、編集画面には属性付きの本物のブロックとして見えていました。修正後は、すべての読み手が同じ空白の文字だけを認めるようにそろえられています。

カテゴリーブロックでは、検査を通したラベルを後から書式の文字列として展開していたため、検査が終わった後に中身が変わっていました。画像と再生リストのブロックでは、正規表現の置換で特別な意味を持つ記号が展開されていました。カスタマイザーでは、ページ内の値をjQueryに渡したところ、jQueryがそれを検索の条件ではなく作るべきHTMLとして扱っていました。どれも「確かめた後に、別の処理が別の読み方をする」という点で共通しています。

WordPressは少し前から、HTMLを文字列として扱うのをやめ、構造として読むHTML APIへの置き換えを進めています。今回も画像と再生リストのブロックはHTML APIで組み直されました。読み手を一つにそろえる方向の作り直しが、こうした食い違いを減らしていくのだろうと感じます。

古い版のサイトと日々の運用で確かめたいこと

公式の記載では、修正は4.7系までさかのぼって提供されるとされ、版ごとの番号も載っています。たとえば6.9系は6.9.11、7.0系は7.0.8です。7.1系に上げなくても、自分の系統の最新版にすれば修正は入ります。なお、公開から約3時間後に確かめた事業者によると、その時点では6.5系以前の修正版はまだ配布が始まっていなかったそうです。古い系統のサイトは、管理画面で実際に更新が届いているかを確かめておくのが確実です。そもそも公式に支援されているのは最新版だけで、古い系統への修正は好意によるものとされているので、新しい系統への移行も計画に入れておきたいところです。

このほか、各解説が勧めていた点をまとめると、更新が自動で当たらない設定のサイトがないか確かめること、ステージングや開発用の複製も同じ更新の対象にすること、カスタマイザーで公開前の変更を下書き保存していた場合は外から見えていた可能性を前提に考えること、などが挙がっていました。カスタマイザーの件は、ログインしていない訪問者でも、公開前の変更の中身を見られたという不具合です。

今回の修正で印象に残るのは、サイトを守るための更新そのものに隙があり、しかもプラグイン型の防御では届かない場所だったことです。更新を急ぐことと並んで、ウェブサーバーの設定やアカウントの持ち方といった、WordPressの外側の地味な基本が効いてくる修正版だったといえそうです。

WordPressのセキュリティ製品を手がけるMelapressが、毎年行っている調査の2026年版を公開しました。制作会社、開発者、デザイナー、サイト運営者など319件の回答をまとめたもので、10月に入ってからも内容が更新されています。数字を眺めていくと、守りの道具よりも「気づき方」と「戻し方」に課題が残っている様子が見えてきます。

まず、回答者の67.7%が少なくとも1回はセキュリティ上の被害を経験しており、2回以上という人も45.5%いました。被害の中身で最も多かったのはサイトの停止で、被害を受けた人の68.4%が挙げています。改ざんや情報の流出よりも先に、単純に「サイトが動かなくなる」ことが一番身近な損失になっているわけです。

最初に気づくのは誰か

今回の調査で目を引いたのは発覚のきっかけです。被害を受けた人のうち42.6%は、誰かがサイトの様子がおかしいと知らせてきたことで気づいたと答えています。ログや通知の仕組みで気づいた人は38.4%、ホスティング会社やサーバーからの通知が35.6%、マルウェアの検査ツールが30.1%でした。自前の監視よりも、訪問者や取引先の指摘のほうがわずかに多いという結果です。

さらに、検索エンジンの警告で発覚した被害は、その後の影響が大きくなる傾向が出ています。検索順位を落とした割合は、ほかの経路で気づいた場合の14.5%に対して45.9%でした。調査側も、警告が被害を大きくしたのではなく、警告が出るころには手遅れに近いほど進んでいる、という読み方をしています。Search Consoleの警告を見てから動くのでは遅い、ということは現場の実感とも重なります。

一方で、備えの数字はほとんど動いていません。侵害から立て直す計画を持っている人は27.9%で、前年の27%とほぼ同じです。運用を社内の担当者が見ている場合は35.5%が計画を持っていたのに対し、制作会社やフリーランスに任せている場合は22.8%にとどまりました。調査側は、外部の側では手順があっても依頼主にそれが伝わっていないだけかもしれない、とも書いています。

サイトの種類による違いも出ています。企業やブランドのサイトに関わる回答者は70.2%が操作の記録や監視を入れていて、そうでない回答者の46.6%を大きく上回りました。ネットショップに関わる回答者は立て直しの計画を持つ割合が35.8%と高めでしたが、被害を受けたときに検索順位を落とした割合も31.9%と、ほかの種類のサイトの倍以上でした。売上や顧客の信頼に直結するサイトほど、気づくのが遅れたときの痛手も大きいということでしょう。

受託で保守を受け持つ立場から見ると、この最後の点は耳が痛いところです。異変の通知を誰が受け取るのか、誰が復旧を判断するのか、取引先への連絡は誰がするのか。こうした分担を依頼主と言葉にして共有しておくだけでも、外から指摘されて慌てる場面は減らせるはずです。バックアップを取っているだけで、実際に戻したことがないという状態も、一度見直しておきたいところです。

WordPressの次の大きな版、7.2のベータ1が10月20日に公開されました。正式公開は12月8日の予定で、今年最後の大きな更新になります。ベータは試験用の環境だけで動かすもので、本番のサイトに入れるものではありませんが、ここから先は大きな変更が加わりにくい段階です。何が入るのかを今のうちに見ておくと、年末の更新の見通しが立てやすくなります。公式の発表と開発者向けブログの10月号から、地方の制作会社や中小企業のサイトに関わりそうな項目を並べてみます。

画像の縮小と変換をブラウザ側で済ませる

メディアライブラリへの画像の追加で、縮小・圧縮・形式の変換をアップロードの前にブラウザの中で行えるようになります。これまではサーバーに送ってからPHPの画像処理に任せていた工程で、共用サーバーのように画像処理の性能に制約がある環境では、大きな写真を何枚も上げると時間がかかったり失敗したりすることがありました。手元で小さくしてから送る形になれば、転送量もサーバーの負荷も減ります。スマートフォンで撮った写真をそのまま上げるようなサイトほど効き目が大きいはずです。

管理画面の読み込みの仕方が変わる

管理画面で使うスクリプトとスタイルシートは、これまで複数のファイルをまとめて一つにして配信していました。7.2ではまとめるのをやめて個別に読み込み、ブラウザのキャッシュが効きやすい形に変えます。あわせて、次に開きそうな画面を先回りして読み込む仕組みが入り、ダッシュボードから投稿一覧、編集画面へと移る動きが速くなるとされています。表側のページには関係のない変更ですが、管理画面の重さに不満を持っている利用者には地味に効く部分です。

新しい既定テーマは年の名前を外した

7.2には新しい既定テーマが同梱されます。名前はIpsumで、長く続いた「Twenty」と年号の組み合わせから離れました。開発者ブログによると、これからの既定テーマは暦ではなく設計の必要に応じて入れ替わる方針で、名前はダミーの文章として使われるlorem ipsumから取ったそうです。中身は意図的に控えめなブログ向けのテーマで、点線の下線と少数の書体の組み合わせが基本、ヘッダーやサイドバーは必要なときだけ出す作りになっています。スタイルの切り替えでは画像まで含めて全体の色味を変え、どの組み合わせでもWCAGのAA基準を満たすとしています。既定テーマをそのまま使う小規模なサイトでは、ここが出発点になります。

デザインの道具が増えて表示幅ごとの調整も広がる

7.1で入った表示幅ごとのスタイル指定が、7.2ではギャラリーの列数や切り抜き、縦横比など、より多くの設定に広がります。文字の影(text shadow)もブロックの設定から付けられるようになり、theme.jsonにプリセットとして定義しておけば、サイト全体で揃えた使い方ができます。フォームの部品をグローバルスタイルから整えられるようになる点も、お問い合わせページを持つ企業サイトには関係が深いところです。開発者ブログの10月号には、既定で付く影のプリセットを切って自前の値だけにする設定例も載っています。

編集者どうしの書き込みは余白に移る

投稿に注記を残せるNotesの機能は、編集画面の余白に表示されるようになり、ブロックの設定パネルと同時に開いておけるようになります。絵文字での反応や、ツールバーからの呼び出し、折りたたんだ表示も加わります。複数人で原稿を回す体制のサイトでは、確認のやり取りを外のチャットに持ち出さずに済む場面が増えそうです。なお、複数人が同時に同じ投稿を編集する共同編集そのものは、7.2の計画には意図的に入れていないと明記されています。

プラグインの作り手が先に確かめておきたいこと

開発側に関わる変更もいくつかあります。APIキーなどを暗号化して預けるSecrets APIは、保存の層だけが7.2に入り、管理画面はその先の版に回されました。管理バーとメニューのアイコンは古いDashiconsからWordPressのアイコンライブラリに置き換わります。アイコンの描き方も塗りから線に変わっているため、管理画面のCSSでsvgのfillを指定して色を変えていたコードは効かなくなります。部品のライブラリでは、Divider、ResponsiveWrapper、Scrollable、ZStack、Elevationの五つが7.2で非推奨になり、7.4で外される予定です。データベースの接続では、WordPress自身のセッションからNO_BACKSLASH_ESCAPESというSQLモードが外されます。ほとんどのサイトには影響しませんが、このモードに頼った処理があるなら、db.phpのドロップインからしか戻せない点に注意が要ります。

ベータ1は、ベータテスター用のプラグインか、WP-CLIのwp core update --version=7.2-beta1、ブラウザだけで動くPlaygroundの7.2用の環境で試せます。テーマやプラグインに手を入れているサイトだけでも、11月17日のリリース候補版までに一度動かしておくと、12月の更新を落ち着いて迎えられそうです。

10月21日に、PHPの修正版がいつもと違う出方をした。前日のうちに、翌日の14時(UTC)に重大な修正版を出すという予告が流れ、その予告には、詳細が漏れたり攻撃が始まったりしたら前倒しで出す、とまで添えられていた。PHPの開発チームがこういう告知を出すのは珍しい。そして実際に、予告の日のうちに詳細が外へ漏れ、Cloudflareは修正版が出る数時間前に攻撃の通信を観測したと伝えている。

出たのは PHP 8.5.12、8.4.27、8.3.36、8.2.35 の4本で、CVE-2026-109618 と CVE-2026-109619 の2件を直している。どちらも CVSS v4.0 で 9.2 という高い評価がついていて、ログインなしで遠隔からコードを動かされる可能性があるとされる。通称は PHP2Shell。WordPressのサイトを預かる立場として、何がどこまで自分たちの話なのかを整理しておきたい。

穴はWordPressの下の層にある

今回の2件は、プラグインやテーマの不具合ではなく、PHPという言語の実行環境そのものの問題だ。PHPの公式の告知によると、1件目はメモリ不足でPHPの処理が途中で止まったとき、まだ準備の終わっていない内部データを後片付けの処理が正しいものとして扱ってしまうという内容。2件目は、あるリクエストで使った内部の状態がメモリを解放した後も残り、同じ作業プロセスが次のリクエストを処理するときにその古い状態を使ってしまうという内容だ。

どちらも、PHPがリクエストを受け取ってから、WordPressの最初の一行が動くまでの間に起きる。Sansec の解説では、PHPのアップロード進捗を扱う処理がアプリケーションの手前で走るため、サイト側が何もしていなくても攻撃が成り立つとされている。さらに、解放済みのメモリの中身が PHPSESSID のクッキーに乗って返ってくる経路もあり、そこには他のリクエストが使ったパスワードやトークン、APIキーが含まれうるという。Patchstack は、Wiz Research が「Hello World」を表示するだけのPHPアプリでも成立することを示したと伝えている。

つまり、WordPressやプラグインをどれだけこまめに更新していても、この穴は塞がらない。WordPress.org もこの件でWordPress側の更新は出さないと明言していると、Codeable が伝えている。直すのはサーバーのPHPで、それ以外に完全な対策はないというのがPHP側の立場だ。

影響を受けるのはどの動かし方か

PHPの告知は、ウェブのリクエストを受けるPHPはすべて対象だとしている。PHP-FPM、Apache の mod_php、php-cgi、FrankenPHP、LiteSpeed のいずれも含まれる。その中で最も危険度が高いとされたのが mod_php で、認証のないリクエスト1本で、アプリケーションのコードが動く前に攻撃できることが実証されている。

PHP-FPM なら安全というわけでもない。Qualys のまとめによると、FPM は起動時の挙動のおかげでメモリ不足を使う経路のひとつは防げるものの、セッションまわりの経路での遠隔コード実行はFPMでも確認されている。Sansec も、既定の設定のままで脆弱であり、問題のコードは2012年の PHP 5.4.0 から入っていたと書いている。14年前から同じ場所に穴があったことになる。

直すのは誰かという問題

ここからが実務の話になる。Codeable の整理が分かりやすいので、それに沿って考えてみる。マネージドのWordPressホスティングなら、PHPの更新は事業者側が行う。共用のレンタルサーバーも、サーバー全体のPHPを事業者が差し替える。この2つの形態では利用者が触れる設定はほとんどなく、できるのは事業者の告知を確かめることと、自分のサイトがどの版のPHPで動いているかを把握することくらいだ。

一方、VPSやクラウドのサーバーに自分で環境を作っている場合、あるいは制作会社がサーバーごと預かっている場合は、誰も代わりに直してくれない。パッケージを更新してPHPを再起動し、すべての作業プロセスが新しい版で動いていることを確かめるところまでが仕事になる。配布元によって更新が届く速さが違う点にも注意がいる。Ubuntu の公式パッケージや Sury のリポジトリは当日中に出たが、RHEL 系で広く使われる Remi のリポジトリは当日は更新を出さないとPHP側が告知しており、別の入手経路を考える必要があった。

自分のサイトのPHPの版は、WordPressの管理画面の「ツール」から「サイトヘルス」を開き、「情報」タブの「サーバー」の欄で確かめられる。ただし、Linuxのディストリビューションが配るPHPは、版の数字を変えずに修正だけを取り込むことが多い。表示されている数字が古く見えても、未対応とは限らない。迷ったら、10月21日の修正が当たっているかを事業者に直接聞くのが確実だ。

古いPHPのまま動いているサイト

今回の件で、もうひとつ重みを持つのが、サポートの切れたPHPで動いているサイトの扱いだ。PHPの開発チームが修正版を出すのは 8.2 以降だけで、8.1 以前には公式の修正版が出ない。例外として、自分でソースからPHPを組み立てる人向けに 7.4、8.0、8.1 の最小限の修正を公開しているが、これは一般のサイト運営者が使う形のものではない。

では 8.1 以前のサイトは見捨てられたのかというと、そうでもない。Codeable が集めた各社の対応を見ると、Plesk は 8.2 から 8.5 の修正版を出したうえで 8.0 と 8.1 を準備中、cPanel は 7.4 まで含めた修正パッケージを出している。Pantheon は長期サポートの事業者を通じて古い版にも修正を当て、OVHcloud は 7.4 から 8.5 までを自社のクラスタで修正済みとしている。つまり、どこまで面倒を見てもらえるかは、使っている事業者と管理ツール次第という状態だ。

国内の中小企業のサイトには、数年前に作ったまま PHP 7.4 や 8.0 で動いているものが少なくない。動いているから触らないという判断は理解できるし、古いテーマやプラグインが新しいPHPで動かなくなる心配も現実にある。ただ、今回のように実行環境そのものに穴が見つかると、版を上げる以外の選択肢が事業者頼みになってしまう。先送りしてきたPHPの版上げを、検証用のコピーで試してから本番に反映する手順ごと、予定に入れる時期だと思う。

いったん止めるという判断

今回、目を引いたのが、修正版が出るまでサイトを止めた組織が相次いだことだ。Patchstack の時系列によると、オランダでは行政のログイン基盤や下院のサイト、国のサイバーセキュリティセンター自身のサイトまでが一時的に停止した。WordPressのSEOプラグインを作っている The SEO Framework も自社サーバーを止めたという。国内でも大手のレンタルサーバーやウェブサービスが緊急メンテナンスに入ったことが、同じ記事で触れられている。

注意したいのは、WordPressのメンテナンスモードでは意味がないという点だ。Sansec が指摘するとおり、PHPはアプリケーションがメンテナンス中かどうかを確かめる前にリクエストを解析してしまう。止めるなら PHP-FPM を停止して、ウェブサーバーに静的なページを返させる形になる。完全に止められない場合の次善策として、Sansec は multipart/form-data のリクエストをウェブサーバー側で拒否する方法と、GET と HEAD 以外のメソッドを受け付けない方法を挙げているが、いずれもファイルのアップロードやフォームの送信が止まる。あくまで修正版を当てるまでの時間稼ぎだ。

Cloudflare を前段に置いているサイトでは、無料プランも含めて既定で防御の規則が有効になっている。公開の9時間ほど前から配備を始め、今回のために、リクエストとレスポンスの両方を見て判定する新しい仕組みまで用意したという。ただし Cloudflare 自身が、これは多層防御の一枚であってPHPの更新の代わりにはならないと繰り返している。サーバーが Cloudflare 以外からの通信も受け付けていれば、迂回されてしまうからだ。

制作会社として確かめておきたいこと

預かっているサイトが多いほど、見落としが怖い。Patchstack と Qualys の助言を合わせると、まずやるべきは棚卸しだ。本番だけでなく、検証用の環境、コンテナ、PHPを同梱しているアプライアンスや他のソフトまで含めて、PHPが動いている場所を全部数える。更新したあとは、コマンドラインの php -v ではなく、実際にウェブのリクエストを処理しているPHPが新しい版かを確かめる。1台のサーバーに複数の版のPHPが入っていることは珍しくなく、主に使っている版だけ直して他が残る、ということが起きやすい。

更新がすぐにできないサーバーには、PHPが示した暫定の設定がある。session.upload_progress を無効にする、memory_limit の上限を外して post_max_size を小さくする、といった内容だが、PHP自身がこれらは特定の経路を塞ぐだけで安全にはならないと念を押している。memory_limit を外すと1本のリクエストがサーバーのメモリを食い尽くせるようになるため、修正版を当てたら元に戻す作業もセットで考えたい。

狙われた形跡を探す手がかりも、Patchstack が Wiz Research の見解として挙げている。普段と違う multipart のリクエストの直後にメモリ上限のエラーや 500 が続く、応答に妙に大きい PHPSESSID のクッキーが含まれる、PHPの作業プロセスが説明のつかない再起動をしている、といった兆候だ。これらは証拠にはならないが、見つかったら更新だけで終わらせず、そのサーバーが持っていた資格情報の入れ替えまで考えたほうがいい。メモリの中身が読み出される経路があった以上、何が漏れたかは後からでは分からない。

PHPの修正はふだんは地味な作業で、サイトの見た目には何も起きない。だからこそ、どのサーバーで誰がいつ当てるのかが決まっていないまま今回のような日を迎えると慌てることになる。預かっているサイトの一覧に、PHPの版と更新の責任者の欄を足しておく。それだけでも、次に同じことが起きたときの初動はだいぶ違ってくるはずだ。

WordPressには、投稿やコメントに含まれるHTMLから危ないものを取り除く wp_kses() という関数があります。テーマやプラグインの中でも広く呼ばれていて、普段は意識することのない裏方です。この関数の中身を丸ごと作り直す変更について、10月7日付でコア開発者のDennis Snell氏が公式の開発ブログに経過を報告しました。開発版にはすでに取り込まれていて、テストの結果しだいでWordPress 7.2か7.3に入る見込みとされています。

古い作りのままだった理由と作り直す理由

kses はもともと独立したライブラリで、名前はXSSとアクセスを組み合わせたものだそうです。書かれたのはHTML5で構文解析のルールが厳密に定まる前で、HTMLを手で打つのが当たり前だった時代でした。そのため、打ち間違いや貼り付けの崩れを整える役目と、信頼できない入力から危険を取り除く役目の二つを担ってきました。

報告によると、今はブロックエディターのような編集画面から書くのが普通になり、主な役目は後者に絞られています。一方で中身は、正規表現と文字列処理をいくつも連ねた複雑な作りのままでした。新しい実装は、WordPressが整備を進めてきたHTML APIの構文解析器を土台にして、入力をいったん構造として読み取り、そこからHTMLを書き出し直す方式に変わります。報告では、より堅牢で速く、メモリの消費も少ないとされています。

出力されるHTMLはどう変わるのか

関数の呼び出し方は変わらないため、プラグインやテーマの側で書き換えは要らない、というのが基本の説明です。ただし処理の考え方が根本から変わるので、出てくるHTMLの細部は変わります。報告に挙がっている例のうち、制作の現場で目にしそうなものを拾ってみます。

• タグ名は小文字にそろい、属性値は二重引用符で囲まれ、<img /> の末尾のスラッシュは付かなくなる
• 本文中に「<500ドル」「>5年」のような不等号を書くと、これまではタグの書きかけと誤解されて間の文章ごと消えることがあったが、新しい実装では正しく残る
• 許可されていない script や style は、タグだけでなく中身ごと取り除かれる。これまでは中のJavaScriptが文字として画面に残っていた
• 途中で切れた入力は、タグの書きかけに見える末尾を捨てる
• SVGやMathMLの埋め込みで解析が複雑になる書き方は、その手前で打ち切られる

文章が消えにくくなる方向の変更が多い一方で、条件によっては、これまで残っていたものが残らなくなる場合もあります。報告では、この関数が信頼できない入力を扱うものである以上、本来は問題のない入力の一部を拒否してでも、危ない入力を確実に止める側に寄せると説明されています。

アンパサンドの書き方は見直しどころ

地味ですが気をつけたいのが、& の扱いです。HTMLにはセミコロンを省略しても認識される文字参照があり、本文中に ?preview=true&section=... のようなURLをエスケープせずに書くと、&sect の部分が節記号の § に置き換わります。ブラウザがもともとそう解釈する仕様なので、新しい実装もそれに合わせました。報告では、アンパサンドは常に & とエスケープし、文字参照には必ずセミコロンを付けるよう勧めています。記事中でURLの例を紹介することが多い技術ブログやマニュアルのページは、一度見ておいて損はなさそうです。

試す手段と制作会社としての備え

移行期間のあいだは、古い実装に戻すためのフィルター wp_kses_force_legacy_parser が用意されています。add_filter( 'wp_kses_force_legacy_parser', '__return_true' ); の一行で以前の動きに戻せますが、報告では、テストで大きな問題が出なければ7.2の正式版の時点で古い実装ごと取り除かれる可能性にも触れています。戻し道があるうちに、手元で確かめておくのがよさそうです。

確認の手段としては、開発者のRyan Welcher氏が、同じHTMLを新旧の両方に通して並べて表示するデモ用のプラグインを公開しています。WordPress Playgroundを使ってブラウザ上で動く版もあり、気になるHTMLを貼り付けるだけで違いを見比べられます。

制作会社の立場で気になるのは、カスタムHTMLブロック、投稿者権限のユーザーが書く記事、フォームの入力内容を表示する部分、そして独自に wp_kses() を呼んでいるテーマやプラグインです。古い案件ほど、以前の挙動を前提に組まれた処理が残っていることがあります。7.2のベータ版が出たら、ステージング環境で代表的なページを表示して、文章が欠けていないか、余計なコードが見えていないかを確かめておくと、本番の更新で慌てずに済みそうです。

10月6日、WordPress 7.1.3が公開されました。セキュリティ修正7件と不具合修正4件を含む保守版で、公式は早めの更新を勧めています。7.1系では、9月17日の7.1.1、9月22日の7.1.2に続いて、ひと月足らずのあいだに三度目のセキュリティ修正となりました。

間隔がこれだけ詰まると、正直なところ「また更新か」と感じます。ただ、三つの修正版の中身を横に並べてみると、どこが繰り返し狙われているのか、運用のどこを見直せばよいのかがかなり具体的に見えてきます。今回は公式の発表と各版の変更内容をもとに、中小企業のサイトを預かる立場から読み解いてみます。

九月半ばから続いた修正版の流れ

まず時系列を整理しておきます。9月17日の7.1.1は大きめの保守版で、セキュリティ修正11件に加え、コアの不具合修正17件、ブロックエディターの不具合修正21件を含んでいました。報告されたセキュリティ上の問題の多くは、ログインしたユーザーによる操作が前提のものです。

その5日後、9月22日に出た7.1.2は修正1件だけの版でした。ただしその1件は、ページテンプレートの解決処理におけるパストラバーサルで、認証なしで狙え、条件次第ではリモートからのコード実行につながるという重いものです。変更されたファイルも wp-includes/template.php ひとつに絞られており、急ぎで出された修正だったことがうかがえます。

そして10月6日の7.1.3です。今回は1件ごとの深刻さよりも、管理画面、書き出し、埋め込み、問い合わせ処理と、触れている範囲の広さが目立ちます。

7.1.3で直された箇所

公式の発表に挙がっている修正は次のとおりです。

• コメント管理画面での保存型XSS。承認待ちのコメントを経由して悪用できるもので、Trail of Bitsの研究者が報告
• WP_Http::make_absolute_url() メソッドでのサービス妨害(DoS)
• WordPress標準の書き出し機能(WXR形式)での二次的なSQLインジェクション
• 投稿者(Author)権限のユーザーが記事を先頭に固定できてしまう弱点
• 非公開や未公開の投稿に付いたコメントが、認証なしで見えてしまう問題。Patchstackの研究者が報告
• Imgurの埋め込みでのXSS
• {status}_{type} フックに渡る引数を偽装でき、アクション名の衝突につながる問題。WordPressのセキュリティチームが報告

変更されたファイルの一覧には、wp-admin/js/common.js、wp-admin/includes/export.php、REST APIの投稿コントローラー、カスタマイザー関連、class-wp-http.php、class-wp-oembed.php、class-wp-query.php、post.php が並びます。どれも日常的に動いている部品で、特定の設定をしているサイトだけの話ではないと考えておくほうが安全です。

コメント欄はずっと入口であり続けている

三つの版を並べて最初に気づくのは、コメントまわりの修正が何度も出てくることです。7.1.3では、承認待ちコメントを経由した管理画面での保存型XSSと、非公開投稿のコメントが認証なしで見える問題が直されました。さかのぼると7.1.1でも、段落の整形処理を経由した認証不要の保存型XSS(コメントの承認が条件)や、ログインしたユーザーなら誰でもコメントの親子関係を付け替えられる問題が修正されています。

ここで押さえておきたいのは、「承認しなければ表に出ないから安全」とは言い切れないという点です。報告の説明を読むかぎり、承認前のコメントが管理画面に表示される段階が関わっています。つまりスパムの山を確認するために管理画面を開く、その日常の作業が攻撃の起点になりうるわけです。

実務の面では、コメント機能をそもそも使っていないサイトなら、設定でコメントの受け付けを止めておくのがいちばん手堅い対策です。会社案内が中心の中小企業サイトでは、テーマの初期設定のままコメント欄が開いていて、誰も読まないスパムが溜まり続けているという例を今でもよく見かけます。使っているサイトでも、古い記事のコメント受け付けを一定期間で閉じる設定は検討する価値があります。

権限の低いアカウントと書き出し機能

二つ目の傾向は、投稿者や寄稿者(Contributor)といった、権限の低いアカウントを前提にした問題が続いていることです。7.1.3の「投稿者が記事を先頭に固定できる」件は影響こそ限られますが、7.1.1では寄稿者以上の権限で任意の投稿を上書きできる問題や、下書きと承認待ち記事のスラッグが寄稿者以上に見えてしまう問題が直されています。REST APIのテンプレート処理での、認証済みユーザーによるパストラバーサルも同じ版に含まれていました。

外部のライターに寄稿者アカウントを発行している、退職した担当者のアカウントが残っている、といった状況は珍しくありません。こうしたアカウントのパスワードが漏れれば、権限が低くても修正前の穴を突く足がかりになります。更新とあわせて、使われていないアカウントを整理しておくと安心です。

もうひとつ見落としやすいのが、書き出し機能での二次的なSQLインジェクションです。二次的というのは、先にデータベースへ保存された値が、あとで別の処理に使われる段階で問題を起こす型を指します。WXR形式の書き出しは、サーバー移行やサイトの複製、バックアップの代わりとして制作会社がよく使う機能です。普段は誰も触らない機能でも、移行作業のときに一斉に使われる、という点は意識しておきたいところです。

古い系統への移植と「支援の対象は最新版だけ」

WordPressには、修正を古いメジャー版にも移植するという慣例があります。7.1.1のときは、7.0から4.7までのすべての系統に修正版が出ました。発表によると、7.0から6.7までは11件すべての影響を受け、系統が古くなるにつれて影響を受ける件数は減り、4.7では6件だったとされています。7.1.2の1件は、4.7までのすべての系統が影響を受けていました。4.6以前には、もうセキュリティ修正は届きません。

7.1.3についても、修正は厚意として、セキュリティ修正の対象となっている4.7までの系統に必要に応じて移植され、準備ができ次第出していくと説明されています。ここで公式が毎回添えているのが、「積極的に支援しているのは最新版だけ」という一文です。古い系統に修正が届くのはあくまで厚意であり、不具合修正までは届きません。

PHPの版や、更新の止まったプラグインとの相性を理由に、古い系統に据え置いているサイトは今もあります。移植版が出ている以上、すぐに危険というわけではありませんが、最新版より遅れて届く可能性があることや、修正の範囲がセキュリティに限られることは、据え置きを選ぶときの前提として持っておくべきでしょう。

続く修正版を受け止める段取り

では、短い間隔で届く修正版にどう付き合えばよいのでしょうか。制作会社として保守を受け持つ立場から、確認しておきたい点を挙げます。

まず、マイナー版の自動更新が有効になっているかどうかです。公式の発表でも、バックグラウンドでの自動更新に対応しているサイトでは更新が自動で始まるとされています。自動更新を止めて手作業で管理している場合は、修正版の公開から適用までに何日かかっているかを一度振り返ってみてください。7.1.2のように認証なしで狙える重い修正が出たとき、その日数がそのまま無防備な期間になります。

次に、更新後に何を確かめるかです。今回の7.1.3は、管理画面のスクリプト、書き出し、カスタマイザー、埋め込み、投稿の問い合わせ処理に手が入っています。ステージング環境がある場合は、管理画面のコメント一覧、カスタマイザーでの表示確認、外部サービスの埋め込みを含むページ、記事一覧の並び順あたりを見ておくと、思わぬ表示崩れに早く気づけます。

そして、更新とは別に続けたいのが、コメント機能とアカウントの棚卸しです。三つの版を通して、コメントと低い権限のアカウントが繰り返し入口になっていることを考えると、使っていない機能を閉じ、使っていない人のアカウントを消すことは、修正版を待つ以外にこちらから打てる数少ない手立てです。

修正版が続くのは落ち着かないものですが、裏を返せば、外部の研究者やセキュリティ企業からの報告が受け止められ、数十人規模の協力で修正が形になっている表れでもあります。7.1.3の発表には、修正に関わった人の名前がずらりと並んでいました。届いた修正を淡々と当て、そのたびに中身へ少し目を通しておく。地味ですが、それがいちばん確かな付き合い方だと考えています。