タグ: Wordpress

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の発表には、修正に関わった人の名前がずらりと並んでいました。届いた修正を淡々と当て、そのたびに中身へ少し目を通しておく。地味ですが、それがいちばん確かな付き合い方だと考えています。

改ざんされたWordPressサイトで、怪しいファイルを消したのに数秒後には元どおり、という経験がある制作者は少なくないと思います。セキュリティ企業のSucuriが、まさにその状態を作り出すマルウェアの分析結果をブログで公開しました。注入されたコードに残っていた目印から「SC」と呼ばれています。

Sucuriによると、SCは同じ裏口を少なくとも8か所に分けて置いています。.user.ini の auto_prepend_file で毎リクエストの前に読み込まれるローダー、wp-content 直下の db.php と advanced-cache.php というドロップイン、有効なテーマの functions.php の末尾に足されたブロック、そしてキャッシュ系に見せかけた偽プラグインが mu-plugins と通常の plugins の両方に置かれていたそうです。どれか一つでも残っていれば、ほかの全部を書き戻す作りになっています。

やっかいなのはファイル以外の置き場所です。本体はオプションテーブルの行にも圧縮して保存され、サーバーの共有メモリにも書き込まれていたとされています。さらにWordPressのcronに再配置用のフックが登録され、関連する亜種ではデータベースのトリガーで管理者アカウントを作り直す例もあったとのことです。ファイルを完璧に掃除しても、次のアクセスでデータベースや共有メモリから全部よみがえるわけです。

削除より先に止める

裏口としての働きも一通りそろっています。プラグイン一覧や更新チェックから自分を隠し、ユーザー一覧に出ない管理者を作り、セキュリティ系プラグインを無効化して削除する指示も受け取れます。指示はブロックチェーンの公開ゲートウェイ約20か所を経由して読み取る方式で、一つを遮断しても残りが使われます。ネットショップでは決済画面に不正なスクリプトを差し込まれるおそれもあるとされています。

Sucuriが示す片付け方の要点は「順番」です。まず auto_prepend_file の読み込み先を無害な中身に置き換えてから設定を外します。PHPがこの値を最大300秒キャッシュするため、先に読み込み先を消すとアカウント内のPHPがすべてエラーになるからです。次にデータベースの行、共有メモリ、cron、トリガー、隠れた管理者といったファイル以外の複製を消し、最後にファイルを一度に片付けます。テーマの functions.php は、目印で囲まれた部分だけを削ってテーマ本来のコードは残します。

中小企業のサイトを預かる立場で覚えておきたいのは、消したファイルが戻ってきたら「掃除が終わっていない合図」と受け取ることです。同じファイルを何度も消すより、データベースやcron、ユーザーテーブルに目を向けるほうが近道になります。共有サーバーでは共有メモリをホスティング会社にしか消せない場合もあるので、早めに相談できる窓口を確かめておくと安心です。侵入のきっかけは既知の脆弱性が多いとされているので、更新を止めないことと、復旧後に関係するパスワードをすべて変えることもあわせて進めたいところです。

決済、メール送信、地図、予約システム。WordPressで作るサイトは、外部サービスとつながるたびにAPIキーやパスワードのような「鍵」を預かります。その鍵がどこにどう保存されているか、納品のときに意識したことはあるでしょうか。WordPress本体の開発チームが公開した次期版の計画に、この鍵の保管方法を根本から整える「Secrets API」が入っています。

いまはプラグインの設定と同じ場所に平文で置かれている

Make WordPress Coreに8月末に投稿された提案によると、現在のWordPressには「秘密の値」を扱う専用の仕組みがありません。APIキーを必要とするプラグインは、サイトのキャッチフレーズなどと同じオプションテーブルに、暗号化せずに書き込むしかないのが実情です。提案者も、これはプラグイン作者の落ち度ではなく、ほかに選択肢がないためだと書いています。

問題は、このテーブルがデータベースのダンプやバックアップ、ステージング環境の複製にそのまま含まれることです。制作会社が検証用にコピーしたデータベースにも、クラウドに置いたバックアップにも、本番の鍵が読める形で残ります。一部のプラグインは独自に暗号化していますが、方式はばらばらで、まとめて点検することができません。

提案されている仕組みの中身

提案では、wp_set_secret()とwp_get_secret()を中心とした少数の関数と、値を包むオブジェクトが用意されます。保存時の暗号化は常に有効で、無効にする設定はあえて設けないとされています。暗号化できる設定にしておくと、結局多くのサイトが平文のまま残るからだ、という理由です。

ほかにも実務で効いてきそうな設計がいくつかあります。

• 取り出した値はログやvar_dump()の出力では伏せ字になり、生の文字列を得るには明示的な呼び出しが必要
• 値を取り出す経路にはフィルターを置かない。フィルターがあると、どのプラグインでも全部の鍵を横取りできてしまうため
• 値の書き出し機能はなく、移行先やステージングでは入力し直す前提。確認用には値そのものではなく指紋(fingerprint)を使う
• 上書きしても直前の値を一つだけ残し、入力ミスや切り替え途中の不具合に備える
• WP-CLIからも扱えるようにし、コマンドの引数に鍵を書いてシェルの履歴に残る問題も減らす

既存の設定値を自動で移し替えることはせず、プラグイン作者が自分の判断で移す関数を用意する方針です。移した鍵には「作り直しが必要」という印が付きます。すでにバックアップに平文で残っている以上、暗号化しただけでは不十分で、鍵そのものを発行し直すのが本当の対策だという考え方です。

守れるものと守れないもの

提案は効果の範囲をはっきり線引きしています。守れるのは、データベースの流出、クラウドに置いたバックアップ、SQLインジェクションによる読み取り、設定画面のスクリーンショットやデバッグログからの漏れといった経路です。一方、WordPressの中でコードを実行されてしまった場合は防げません。鍵は使うために取り出せる必要があり、WordPressとして動くコードなら同じように取り出せるからです。

それでも、流出の多くはデータベースやバックアップ経由で起きるという前提に立てば、盗まれたデータベースの価値を下げる意味は大きいと考えられます。鍵へのアクセスが一か所にまとまるので、誰がいつ変えたかを記録できるようになる点も見逃せません。

7.2に入るかどうかと、制作現場の準備

9月18日に公開されたWordPress 7.2のロードマップでは、再認証を求める「sudoモード」やApplication Passwordsの強化と並んで、Secrets APIがセキュリティ面の柱に挙げられています。7.2のベータ1は10月20日から22日、正式版は12月上旬の予定です。ただしロードマップ自体が、掲載項目がすべて入るとは限らないと断っていて、提案でもベータ1までに間に合わなければ7.3へ見送るとしています。管理画面の設定画面は7.3以降に回し、まずはAPIとWP-CLIを固める段取りです。

本体に入ってもすぐに何かが変わるわけではなく、各プラグインが対応して初めて効果が出ます。それまでの間にできるのは、自分たちが納品したサイトにどんな鍵が保存されているかを把握しておくことでしょう。データベースを検証環境にコピーするとき、そこに本番の決済キーやメール送信の認証情報が入っていないか確かめるだけでも、事故の芽は減らせます。プラグインの更新履歴に対応の知らせが載りはじめたら、預かっている鍵を発行し直すよい機会になりそうです。

WordPress.orgから、WordPress 7.1.1の公開が案内されました。コアの不具合修正が17件、ブロックエディターの不具合修正が19件、そしてセキュリティ修正が11件含まれた保守・セキュリティリリースです。公式はセキュリティリリースであることから、すぐに更新するよう勧めています。自動バックグラウンド更新が有効なサイトでは、更新は自動的に始まるとされています。

ログインできる人が起点になる修正が多い

今回の修正一覧を眺めて目につくのは、何らかのアカウントでログインしていることが前提になる項目の多さです。たとえば、寄稿者(Contributor)以上の権限で任意の投稿を上書きできてしまう問題、下書きやレビュー待ちの投稿のスラッグが寄稿者から見えてしまう問題、ログインしたユーザーなら誰でもコメント(メモを含む)の親子関係を付け替えられる問題が挙げられています。テンプレートを扱うREST APIでは、認証済みユーザーによるパストラバーサル(本来見えない場所のファイルを指定できてしまう問題)も修正されました。マルチサイト環境で、サイト管理者がネットワーク専用のプラグインをネットワーク全体で有効化できてしまう問題や、XML-RPC経由でCSS編集権限の確認をすり抜けられる問題も含まれています。

一方で、ログインしていない訪問者が関わる項目もあります。本文の段落整形を担う wpautop() に、コメント経由でスクリプトを埋め込めるストアド型XSS(保存された悪意あるスクリプトが表示時に動く問題)があり、コメントが承認されることが条件とされています。ほかにも、カスタムヘッダーに対応した一部テーマでのXSSや、細工したURLによってWordPress.orgにある未有効化のテーマが自動でインストールされ、プレビューされてしまう問題などが並んでいます。

制作の現場から見ると、これは「管理者だけが使うサイト」より「複数人で更新するサイト」で気にしたい内容です。広報担当や外部ライターに寄稿者アカウントを渡している企業サイト、会員登録を受け付けているサイトでは、ログインできる人の範囲がそのまま影響範囲になります。更新を当てるのはもちろんですが、使われていないアカウントが残っていないか、必要以上の権限を渡していないかを、この機会に棚卸ししておくと安心です。コメント欄を開いているサイトなら、承認の運用を誰が担っているかも確認しておきたいところです。

セキュリティ修正は、修正を受け取れる対象の古いブランチ(現在は4.7まで)にも順次バックポートされるとのことです。ただし公式が積極的にサポートしているのは最新版だけだと改めて書かれているので、古い系統に留まっているサイトは、この機会に最新版へ上げる計画も立てておくのがよさそうです。次の大型版となる7.2は12月に予定されています。保守契約で複数サイトを預かっている場合は、自動更新が止められている環境がないかもあわせて見ておくと、取りこぼしを防げます。

WordPressのブロックエディターで段落を選び、Alt+Shift+2 を押すと見出し2に変わる。この操作自体は2022年から使えていたのだが、仕組みとしては少し変わった作りになっていた。変換の中身が非公開のコンポーネントに直接書き込まれていて、しかもそのコンポーネントを各エディターパッケージがそれぞれ描画する必要があった。つまり標準のブロックだけが持つ固定の挙動であって、外から足せるものではなかったということになる。自作ブロックに似た変換を用意したくても、正規の入り口が存在しなかった。

9月2日に公開された Gutenberg 23.9 で、この部分が宣言できるAPIに置き換わった。宣言の場所は二か所あり、渡す名前も異なる。ブロックのバリエーションを登録するときは shortcut という単数形のオブジェクトを渡し、変換(transforms)の側には shortcuts という配列を渡す。押すキーは keyCombination に修飾キーと文字を書き、あわせて画面に出る説明文も持たせる形になっている。ショートカット名は既存の命名にならって、どの機能に属する変換なのかが読み取れる文字列を付ける。

宣言できるようになると何が変わるか

変換側の定義には variationName も添えられる。これがあるおかげで、ひとつの変換定義に六つのショートカットを持たせても、ブロック切り替えメニューに同じ項目が六つ並ぶようなことにはならない。見出しのレベル違いのように、実体はひとつで見え方だけ複数あるブロックを扱うときに効いてくる部分だ。裏側の登録と、編集者が画面で実際に目にする選択肢を切り離して考えられるようになった、と言い換えてもいい。登録の都合が編集画面の見づらさとして表に出てこない、というのは地味だが大きい。

実務で効いてくるのは、制作側が用意したカスタムブロックにも標準ブロックと同じ操作感を持たせられる点だろう。記事や商品ページを日常的に更新する担当者にとって、よく使うブロックへの切り替えがキーボードだけで完結するかどうかは、思っているより作業時間に響く。これまで標準ブロックだけが持っていた快適さを、案件ごとに用意したブロックにも回せるようになる。マウスをあまり使わずに書く人にとっても、追加したブロックが操作の流れから外れずに済むという意味がある。

注意しておきたいのは、これが現時点ではGutenbergプラグイン側の更新だという点だ。WordPress本体に入るのは次のメジャーである7.2で、ベータ版は10月20日から22日、正式版は12月8日から10日のあいだが予定されている。今すぐ本番のサイトで使う話ではないが、自社ブロックを抱えている制作者であれば、この秋のうちに書き方を確かめておいて損はない。内部に閉じていた挙動を公開された宣言に移していく流れは、インナーブロックのテンプレート指定がブロックタイプの設定側へ移ったことにも表れていて、7.2の開発が本格化するこれからしばらくは、同じ方向の変更が続きそうだ。

WordPressの公式ドキュメントであるCode Referenceで、掲載されているコード例をその場で実行できるようになった。9月上旬にMake WordPress Coreで告知されたもので、WordPress 7.1で最初の2件が公開され、7.2でさらに増える予定とされている。

対象になっているのは、たとえば WP_HTML_Processor::class_list() の解説ページだ。コードブロックに付いた実行ボタンを押すと、そのページの中で結果が表示される。ローカル環境を立ち上げたり、どこかにコピーして貼り付けたりする手間がいらない。ドキュメントを読みながら挙動を確かめられる、という形になった。

実行できるコード例は本体のコメントから作られる

興味深いのは、この実行できるコード例が、ドキュメント用に別途手作りされているわけではないところだ。WordPress本体のソースコードにあるDocBlock、つまり関数やメソッドの上に書かれているコメントの中に、そのまま書かれている。

通常のコード例との違いは、コードフェンスの言語指定を php interactive と書くことだけだという。書き方の詳細をまとめたハンドブックのページも、追って公開されるとされている。

ドキュメントとコードが離れた場所で管理されていると、更新のタイミングがずれて片方だけが古くなる。本体のコメントに書いておけば、コードを直した人が同じ場所で例も直せる。地味な話に見えるが、説明を長く正しい状態に保つうえでは効いてくる作りだ。

ブラウザの中でPHPを動かす仕組みが土台にある

実行を支えているのはWordPress Playgroundだ。もともとはブラウザの中でWordPress一式を動かすための仕組みで、WebAssemblyに移植したPHPが土台になっている。

この春に公開されたPlayground側の解説によると、<php-snippet> というカスタム要素が追加され、スクリプトタグをひとつ読み込むだけで、任意のウェブページに実行できるPHPの例を置けるようになったという。読者が実行ボタンを初めて押したときに、隠しiframeの中でPHPが読み込まれて動く仕組みで、ページを開いただけでは重い処理は走らない。

同じページに例が複数あるときは、条件が一致していれば同じ実行環境を使い回す。チュートリアルにサンプルをいくつも並べても、そのたびにPHP環境を立ち上げ直すことにはならないわけだ。既定のPHPバージョンは8.4、WordPressは最新版で、属性で指定すれば例ごとに変えられる。WordPressを読み込まず、PHPの言語機能だけを試す指定も用意されている。

自分たちのドキュメントに埋め込むこともできる

この仕組みはWordPress公式サイト専用の機能ではなく、外部のページでも使える。スクリプトを読み込み、要素の中にPHPを置くだけだ。実行前に想定される出力を先に表示しておく指定や、コードを別ファイルから読み込む指定、実行させずに色付け表示だけにする指定などもある。

Blueprintという設定用のJSONを併用すれば、実行前にmu-pluginを置いたり、オプションを設定したり、サンプルの投稿を用意したりといった下準備もできる。複数の例で同じBlueprintを共有すれば、環境を一度だけ用意して順に実行させられる。

導入時の注意点も挙げられている。Content Security Policyを厳しく設定しているサイトでは、Playground側から配信されるスクリプトと隠しiframe、そこから読み込まれる各種ファイルを許可する必要がある。それが難しい環境では、スクリプトを自前で配信して参照先を切り替える方法も案内されている。うまく動かないときは、開発者ツールで失敗している通信を確認するのが早い。

手元に環境がない相手に説明するときに効く

制作会社の立場で考えると、使いどころは社外向けの説明だろう。クライアントや外部の協力者に「この関数はこう動く」と伝えたいとき、手順書を書いてローカル環境の構築から始めてもらうのは相手の負担が大きい。動くものをページに置いておけば、読む側は押して確かめるだけで済む。

自社の技術メモや、配布しているプラグインの説明ページに、短いサンプルを実際に動かせる形で残しておくのも現実的だ。文章で説明した挙動と実際の出力が食い違っていないか、書いた側が自分で確かめられる点も含めて、書く手間に見合うものはありそうに思える。

サイトの引っ越しやバックアップで広く使われているプラグイン、All-in-One WP Migration and Backup に深刻な脆弱性が見つかり、開発元の ServMask がバージョン 7.110 で修正した。識別番号は CVE-2026-19949、影響を受けるのは 7.109 までのバージョンで、深刻度の指標は 8.8 とされている。有効インストール数が 500 万件を超える定番だけに、預かっているサイトのどれかに入っている、という制作者は少なくないはずだ。

見つけたのはセキュリティ研究者の Jack Taylor 氏で、Wordfence を通じて 8 月半ばに開発元へ伝えられ、8 月 20 日に修正版が公開された。報じられている Wordfence の説明によると、原因はアーカイブを復元する際にデータベースの中身を書き換える処理にあり、エスケープされたバックスラッシュや引用符の解釈が正しくなかったという。

仕込みと発動がずれているところが厄介

この脆弱性が少し変わっているのは、攻撃が二段構えになっている点だ。ログインしていない第三者でも、トラックバックを使って細工したデータを投稿に紐づけて置いておける。置かれた時点では何も起きない。管理者がサイトを書き出し、別の環境に取り込んだその瞬間に、保存されていた文字列が SQL として動き出す。

その結果、プラグインが内部で使う取り込み用の秘密キーが公開コメントとして表に出てしまう可能性がある。キーを手に入れた側は、実行可能なコードを含んだ .wpress ファイルを取り込ませることができ、最終的にサイトを掌握される恐れがあると説明されている。バックアップと復元はこのプラグイン本来の用途そのものなので、いつかは引かれる引き金だと考えておいたほうがいい。

BleepingComputer の集計では、修正版が出てしばらく経った時点でも更新を済ませたのは利用者のおよそ 3 割で、残る 325 万件ほどが古いまま動いていた。バックアップ系のプラグインは普段の運用で触らないぶん、入れたまま忘れられやすい。停止していれば危険度は下がるものの、一時的に有効化すれば同じ経路が開くとも指摘されている。移行の予定がなくても、管理画面を開いてバージョンを確かめる価値はある。自動更新を切っている運用では、ここが抜けたままになりやすい。

実務でもうひとつ気をつけたいのが、手元に残っている古いアーカイブの扱いだ。細工されたデータは投稿に紐づく形でデータベースに入るため、すでに書き出した .wpress の中に紛れ込んでいる可能性がある。修正版に上げてから取り込めば処理する側は安全になるが、まずテスト環境に流して様子を見るくらいの慎重さはあってよいと思う。複数のサイトを預かっている制作会社であれば、このプラグインが入っている案件を洗い出すところから始めるのが早い。移行や復旧のために入れて、そのまま残っているケースも案外あるはずだ。

WordPressのブロック開発まわりの月次まとめが公開されていて、9月分にはテーマを書く側や制作会社の実務に効きそうな変更がいくつか入っていた。派手な新機能というより、納品したあとのサイトをどう保つかに関わる調整が多い。

背景として、8月に出たWordPress 7.1では、ホバーやフォーカスといった状態のスタイルと、画面幅ごとのスタイルを管理画面から指定できるようになった。CSSを書かずに見た目を触れる範囲が広がったわけだが、これは同時に、制作側が整えたデザインを運用側が意図せず崩せる範囲も広がったということでもある。

状態スタイルの編集をテーマ側で閉じられる

Gutenberg 23.8で、ブロックの状態スタイル編集と、画面幅ごとの編集のそれぞれにオプトアウトの設定が追加された。blockStatesEditingEnabledとresponsiveEditingEnabledの2つで、どちらも既定は有効、block_editor_settings_allフィルターからfalseにできる。

使えると感じたのは、無効にしても表示が壊れない点だ。theme.jsonやグローバルスタイル、ブロックのstyle属性ですでに定義してあるスタイルは、どちらの設定でもそのまま出力される。編集画面から触れなくなるだけなので、作り込んだデザインを保ったまま運用担当者に渡せる。サイトを納品して、その後の更新はお客様側で、という進め方をしている案件では出番がありそうだ。

運用者が見る画面まわりでは、投稿の編集画面とウィジェット編集画面が、管理画面で選んだ配色を引き継ぐようになった。あわせてgetAdminThemeColors()が公開の関数として使えるようになっていて、管理画面の本文クラスから配色を読み取り、主要色と背景色を返す。独自の管理画面を追加しているプラグインでも、同じ二行の囲みを入れておけば利用者が選んだ配色に合う。細かい話ではあるが、追加した画面だけ色が違うという座りの悪さは減らせる。

グローバルスタイルで扱える要素が広がった

Gutenberg 23.9では、theme.jsonの要素スタイルにlabelが加わった。styles.elements.labelで指定でき、label要素を出力するマークアップ全般に効く。コアでは検索、フォーム入力、コメントフォーム、アーカイブ、カテゴリーの各ブロックが対象で、サードパーティ製のブロックにも適用される。

引用元表示のcite、テキスト入力、セレクトの3つは、以前からtheme.jsonでは指定できたものの、エディター上のスタイル画面からは触れなかった。これがタイポグラフィと色のパネルから編集できるようになっている。グループブロックはブロック間隔の対応を縦横それぞれに宣言するようになり、theme.json側では文字列だけでなくtopとleftを持つオブジェクトも受け取る。リストブロックの幅広と全幅、クエリーループのブロック間隔といった細かい対応追加も入った。

theme.jsonが無効扱いされる場面が減る

7.1で入った状態スタイルは、記述を検証するスキーマのほうが追いついていなかった。Gutenberg 23.8では、スタイルバリエーション向けの状態、状態が要素ではなくブロックに固有である点、擬似クラス指定の誤りといった箇所に修正が入っている。コードエディターでtheme.jsonを開いたときに、正しい記述が無効として警告される場面が減るという話だ。地味な変更だが、テーマを書いている時間にはそのまま効いてくる。

公式ドキュメントの例をその場で動かせる

もうひとつ、開発者向けリファレンスに載っているコード例が、ブラウザ上で実行できるようになった。関数のページで実行ボタンを押すと、Playgroundで動く本物のWordPressに対してスニペットが走る。例はDocBlockの中にphp interactiveという名前のコードフェンスで書かれていて、ドキュメントと関数の定義が同じファイルに並ぶ形になっている。挙動を確かめるために手元へ環境を作らなくてよくなる分、調べ物の往復は短くなるはずだ。

次のWordPress 7.2は、ベータ版が10月下旬、正式版が12月上旬の予定とされている。独自ブロックを持っている場合、内部ブロックのテンプレート指定がInnerBlocksのプロパティからブロックタイプの設定へ移り、従来の書き方は非推奨になった点は早めに手を入れておきたい。複数人が同時に編集する機能への対応が理由とされていて、今後この種の書き換えはもう少し続きそうだ。

WordPress 7.1が公開されたのは8月19日だった。それからひと月も経たないうちに、次に来る修正版である7.1.1の日程が公表されている。9月2日に出た告知には、バグを仕分ける作業日の日取りから一般公開の予定日までが一覧で並んでいる。大きな更新のニュースは目にしても、その後始末の予定まで公開されていることは意外と知られていない。

修正版の日程は前もって示される

公表された予定では、9月3日と4日、8日、9日、15日にバグの棚卸しにあたる作業日が置かれ、9月10日にリリース候補版、9月17日に7.1.1の一般公開という並びになっている。時刻はいずれも協定世界時での目安で、実際の時間は担当者の都合によって前後する可能性があるとも添えられている。

この予定が出る前、8月20日の時点では「9月1日から24日のあいだ」という幅のある見通ししか示されていなかった。報告されたバグの深刻さと数を見てから時期を決めるという方針があるためだ。公開後に寄せられた報告の量と深刻さから、修正版は習慣的に準備すべきだと判断された、という書き方になっている。幅のある見通しが具体的な日付へ絞り込まれていく過程が、そのまま外から追える状態に置かれている。

入るものと入らないものが決まっている

7.1.1はバグ修正だけの修正版だと明記されている。対象になるのは7.1の開発期間中に持ち込まれた不具合か、7.1の締め切りの時点で意図的に先送りされた項目に限られる。新しい機能はここには入らない。何が候補になっているかは、不具合の追跡システムの一覧や編集画面まわりの作業ボードから追えるようになっている。

7.1は機能の追加が多い版だった。表示まわりでは画面幅ごとの指定が入り、切り替えの基準となる幅をテーマ側で決められるようになっている。投稿の編集画面も枠内で読み込む形に一本化された。触る範囲が広い更新のあとに報告が集まりやすいのは自然なことで、修正版の枠が早めに用意されるのはその裏返しでもある。

目を引くのは、9月8日の作業日に7.1.2の枠を開き、そこで一部の項目を先送りすると最初から告知している点だ。締め切りに間に合わないものは次に回すという判断が、あらかじめ日程に組み込まれている。直すべきものを溜め込まず、期限で区切って次の枠へ送る。規模の小さい制作現場の案件管理にも、そのまま持ち込める考え方だと思う。

少人数で回っている工程

大型更新の体制と比べると、修正版のチームはかなり小さい。担当者は1人から3人程度になることが多いと説明されている。仕事の中身は、コミッターや各機能の担当と連携してバグを仕分けること、公開のお知らせを書くこと、公開当日の作業を準備して進めること、そして次回のために手順書を更新することとされている。

大型更新に関わった人がそのまま残ることが多いものの、必須ではなく、大型更新の経験がなくても志願できると書かれている。バグの棚卸しは公開された相談部屋で行われ、自分で棚卸しの場を開いてもよいとされている。翻訳が足りていない言語があるという案内も添えられていた。ふだんは使うだけの側から見ると、公開までの手順がここまで読める状態になっていること自体が珍しい。

受け取る側の準備

小さな更新は自動で当たる設定のまま運用しているサイトが多いはずだ。実際、7月17日に出た7.0.2では深刻度の高い問題が含まれていたため、影響を受けるバージョンに対して強制的な更新が実施されている。8月6日の7.0.3では、さらに十数件の修正が入った。放っておいても当たる前提で組まれている以上、現場の役目は「更新するかどうか」ではなく「当たったあとで崩れていないか」を見に行くほうへ寄る。

更新の当たり方はサイトごとに違う。保守を受けている環境では自動更新を止めている場合もあるし、逆に管理する側で一括して当てている場合もある。どちらであっても、修正版が出る日が前もって分かっていれば、確認の予定をその前後に寄せておける。

その意味で、リリース候補版が出る9月10日から一般公開までのおよそ一週間は、手元のプラグインやテーマを新しい版に当てて試せる期間でもある。7.1では、投稿一覧の表で見出しにあたるセルの位置が長年の形から変わるといった、地味ながら影響範囲の広い変更も入っていた。修正版でどこが動くのかを先に眺めておけば、公開後に原因を探して回る時間は減らせる。日々の運用を預かる立場なら、公開日の前後で表示と管理画面を一度通しで確認しておくくらいの構えでちょうどいい。