タグ: Wordpress

WordPressの次のバージョンにあたる7.1のベータ3が7月22日に公開された。71件を超える修正が入った通常のベータ更新だが、告知の中に少し珍しい一文が混ざっていた。いったんコアに取り込まれていた、アルファベット以外の文字を含むメールアドレスへの対応が、7.1には入らないことになったという内容だ。

対象になっていたのは、@より前のローカル部分に日本語や各国の文字が入ったアドレスである。ドメイン側はPunycodeという変換の仕組みで以前から扱えていたが、ローカル部分は長く対象外で、WordPressの検証関数が不正なアドレスとして弾いていた。今回の変更では、データベースの文字コードがutf8mb4であればis_email()やsanitize_email()が非ASCIIのアドレスを受け付けるようになり、アドレスをローカル部とドメイン部に分けて扱えるWP_Email_Addressというクラスも加わっていた。元になったチケットが立てられたのは2015年で、11年越しで前に進んだ案件でもある。

取り込んだあとで外すという判断

その機能が、コアにマージされてから6週間ほどで外された。挙げられている理由は、Unicodeを受け入れることで確認しなければならない範囲が一気に広がることと、それに伴うセキュリティ面の影響だ。Unicodeには見た目がほとんど区別できない別の文字が数多くあり、ログイン用のアカウントや通知メールの宛先が絡む場所では、取り違えやなりすましの入口になりうる。公式の告知では、開発はコミュニティプラグインとして続け、互換性やセキュリティ、データの扱いをより広くテストしていくとされている。

日本の制作現場への直接の影響は、いまのところ小さい。国内で非ASCIIのメールアドレスを実際に運用している取引先はほとんど見かけないし、7.1に入らないのであれば当面の挙動も変わらない。気に留めておきたいのは、問い合わせフォームや会員登録の入力チェックを自前の正規表現で書いているサイトのほうだ。将来コア側が受け入れる文字の範囲が広がったとき、フォーム側だけが古い基準で弾き続ける、という食い違いが起きうる。プラグインとして先に試せる形になるのであれば、その前に手元で挙動を確かめておける。

もうひとつ、この話が示しているのは、メールアドレスの扱いがWordPress単体で完結しないことだ。仮にコア側が受け付けても、その先の送信サーバーやメール配信サービス、受け取る側のメールソフトがそろって対応していなければ、通知が届かないという形で問題が出る。ウェブ側だけを新しい仕様に合わせても意味がない領域で、慎重に進める判断そのものは理解しやすい。

11年動かなかった機能が入り、6週間で外れる。読んでいて印象に残るのはむしろ判断の速さのほうで、世界中のサイトが乗っている土台に何を入れるかという線引きが、機能の完成度とは別の基準で引かれていることがよく分かる。7.1そのものは8月19日の公開予定で、こちらは通常どおりの日程で進んでいる。

ボタンにマウスを載せたら色が変わる、リンクにキーボードのフォーカスが当たったら枠線が出る。ウェブサイトではごく当たり前の動きですが、WordPressのブロックエディタでこれを整えようとすると、これまでは追加CSSの欄にセレクタを書き足すか、テーマのスタイルシートを直接触るしかありませんでした。次のバージョンで、ここに標準の指定方法が入ります。

7月15日に公開された7.1のベータ1の告知では、ブロックが操作にどう反応するかを、サイト全体の設定と個々のブロックの両方で共通のコントロールから指定できるようになる、と説明されています。派手さはありませんが、制作側と運用側の分担にじわじわ効いてくる種類の変更です。正式リリースは8月19日、WordCamp USに合わせた日程が示されています。

これまでは追加CSS頼みだった領域

ホバーやフォーカスといった状態ごとの見た目は、CSSでは擬似クラス(:hover、:focus、:active)で書く領域です。ブロックエディタのサイドバーには色やタイポグラフィの入り口はあっても、状態別の入り口はありませんでした。結果として、テーマが用意した見た目をそのまま受け入れるか、追加CSSで上書きするかの二択になります。

後者はセレクタの書き分けが面倒でした。サイト全体のボタンをまとめて変えるのは比較的簡単でも、あるページの一つのボタンだけ挙動を変えたいとなると、そのブロックに固有のクラスを振り、そのクラス向けの記述を足すことになります。運用担当の方が触れる範囲ではなく、結局は制作会社への小さな依頼として積み上がっていく部分でした。

この標準化はGutenbergのリポジトリで数年前から要望が出ていたもので、ようやく本体に入る形になります。

全体にも一つのブロックにも当てられる

今回の仕組みで押さえておきたいのは、適用範囲が二段構えになっている点です。グローバルスタイル側で指定すればサイト全体のボタンの反応が揃い、個別のブロック側で指定すればその一つだけが別の反応になります。テーマの土台は崩さないまま、例外だけを局所的に作れるということです。

もう一つ、フォーカス時の見た目を編集画面から扱えるようになる意味は小さくありません。キーボードだけでサイトを操作する人にとって、今どこにいるかを示す枠線は迷子にならないための唯一の手がかりです。装飾を優先してこの表示を消してしまう実装は今も見かけますが、逆に言えば、消すのではなく背景色に対して見やすい色に調整するという判断を、コードを触らない担当者でもできるようになります。

対応するブロックはまず限られる

期待しすぎないほうがよい部分もあります。ベータの段階で状態指定に対応しているのはボタンとナビゲーションリンクなど、対象はまだ絞られています。すべてのブロックに広がるのはこの先の版で、本体側でも段階的に範囲を広げていく方針が示されています。

また、テーマ開発の側ではtheme.jsonから擬似要素を扱えるようにする整備も並行して進んでいます。編集画面のコントロールとテーマの定義ファイル、両方から状態のスタイルを扱えるようにしていく流れの一部と見ておくと、位置づけを取り違えずに済みます。開発者向けの月次まとめでも、この周辺は7.1の柱の一つとして扱われています。

更新前に確認しておきたいところ

実務で気をつけたいのは、既存サイトで追加CSSを使ってホバーの見た目を上書きしている場合です。新しいコントロールから指定した内容と、これまで書いてきた記述が重なると、どちらが勝つかは書き方次第になります。更新のタイミングで、追加CSSにどんな状態指定が残っているかを一度洗い出しておくと、後から原因を探す手間が減ります。

本番にいきなり当てるのではなく、複製した検証環境で主要なページを一通り見てから、というのはこの種の更新では毎回変わらない手順です。ボタンとナビゲーションが対象である以上、影響が出るとしたら問い合わせ導線やグローバルメニューという、サイトの中でも動いてほしくない場所になります。

小さな見た目の調整を運用側で完結できる範囲が広がるのは、更新を続けていくサイトにとっては地味に効きます。制作時に決めた見た目を固定するのではなく、運用しながら少しずつ手を入れられる状態にしておく。ブロックエディタが年々進んでいる方向は、おおむねそこに向いているように見えます。

更新の通知が来たらできるだけ早く当てる。WordPressサイトを預かる立場では長く正しい習慣として語られてきましたし、その前提はいまも変わりません。ただ2026年に入ってから表面化したいくつかの事例は、その習慣が暗黙に置いている「配信されてくる更新そのものは信頼できる」という部分に、これまでとは違う角度から光を当てました。

狙われたのはプラグインのコードに残っていた穴ではなく、プラグインが利用者の手元に届くまでの経路のほうです。脆弱性を探して突くのではなく、正規の更新に紛れ込んで入ってくる。防ぐ側から見ると、注意を向ける場所が一段ずれる話になります。

所有者が変わったあとに仕込まれた休眠コード

4月初旬に問題になったのは、Essential Pluginという作者名で公式ディレクトリに並んでいた30本あまりのプラグインでした。カウントダウンタイマー、クリックで開くポップアップ、お客様の声の表示といった、小規模サイトで気軽に足される種類のものが並んでおり、合計の稼働数は数十万件規模とされています。

経緯として報じられているのは、この一群がまとめて売買され、開発者が交代していたという点です。WordPress.orgのプラグインは、作者が変わっても配布の枠組みはそのまま引き継がれます。利用者側の管理画面には、以前と同じ名前のプラグインに更新が来たようにしか見えません。

不正なコードが加えられたのは2025年8月、互換性対応をうたった版でした。そこから約8か月のあいだ、そのコードは何もしないまま眠っていたと分析されています。動き出したのは2026年4月上旬で、外部から指示を受け取って処理を実行する経路が有効になり、検索エンジンのクローラーに対してだけ表示されるスパムや転送が仕込まれました。WordPress.orgのプラグインチームは4月7日に該当する全プラグインの配布を停止し、翌日には強制的な更新で通信部分を無効化しています。

公式ディレクトリの外でも同じ形が起きた

6月には別の形の事例が公表されました。ShapedPluginという開発元の有償版プラグイン、具体的にはWooCommerce向けの商品スライダー、お客様の声、投稿一覧表示の三製品で、開発元自身のビルドと配信の仕組みが侵害されていたというものです。

こちらで問題になったのは、公式ディレクトリに置かれている無償版ではなく、開発元のサーバーから直接配信される有償版のほうでした。つまり影響を受けたのは、対価を払って正規に自動更新を受けていた利用者だけということになります。混入は5月下旬、利用者からの報告が上がり始めたのが6月上旬、開発元が事実を認めたのが6月中旬という流れでした。

盗み出されたとされる情報は、管理者のログイン情報、二段階認証の秘密鍵、データベースの接続情報、メール送信サービスの認証情報、そして受注データにまで及びます。セキュリティメディアの報道では、一連の侵害はCVE-2026-10735として整理されています。有償版だから安全、公式ディレクトリだから安全、という単純な線引きが成り立たないことを、二つの事例は逆方向から示した形です。

気づくまでに時間がかかる理由

Essential Pluginの件で目を引くのは、仕込まれてから発覚するまでのおよそ8か月という長さです。仕込む側からすれば、加えた直後に動かす必要はありません。しばらく普通に動く版を配り、更新が行き渡り、疑いが薄れたころに起こせばよい。監視する側の目線に合わせて時間をずらされると、更新直後の挙動を見るだけでは捕まえられなくなります。

もうひとつは、公式ディレクトリに所有者交代を扱う仕組みが用意されていないという構造の問題です。プラグインが売買されて委譲されても、利用者に通知が飛ぶわけではなく、新しい担当者による最初の更新に追加の審査が入るわけでもありません。稼働数の多いプラグインは、それ自体が売り物として価値を持ちます。数万件のサイトに更新を届けられる立場が、市場で取引できてしまうという事実のほうが、個々の脆弱性より扱いが難しい部分かもしれません。

被害の出方が静かであること

今回のような侵害でやっかいなのは、サイトを見ている限り異変がわからないところです。Essential Pluginの件で配られたスパムは検索エンジンのクローラーにだけ見せる作りで、運営者が自分のサイトを開いても、いつも通りのページが表示されます。気づく糸口は検索結果の見え方や、Search Consoleの警告、ホスティング側からの連絡といった、サイトの外から届く信号のほうになります。

認証情報の窃取はさらに静かです。抜かれた時点では何も起きず、しばらく経ってから別の入口として使われます。管理画面のログイン履歴に見覚えのないものが混ざる、送信していないメールが自社ドメインから出ている、といった形で後から現れることが多く、そのころには最初の原因までたどるのが難しくなっています。

運用側でできる現実的な備え

まず効くのは、入れているプラグインの数を減らすことです。装飾のために一つ、フォームのために一つ、と足していった結果として、10本20本と並んでいるサイトは珍しくありません。一本ごとに、その開発元の更新経路を信頼するという判断が積み上がっていると考えると、使っていない機能のために枠を空けておく理由はあまりありません。

次に、自動更新をどこまで任せるかの線引きです。本体のマイナー更新は自動に任せるとして、プラグインについては稼働数の多いもの、更新頻度の高いものほど、当てる前に一拍置く運用にも意味があります。ただし更新を止めれば安全という話ではなく、既知の脆弱性を放置するほうが確率としてははるかに危ないので、遅らせるとしても数日という幅に留めるのが現実的でしょう。

加えて、更新の中身を軽く確かめる習慣も持っておきたいところです。プラグインの更新画面には変更内容へのリンクが並んでいますし、公式ディレクトリなら開発の記録も公開されています。毎回すべてを読む必要はありませんが、しばらく静かだったプラグインに突然大きな更新が来た、作者名の表示が変わっている、といった違和感は、目を通していれば引っかかります。今年の二件も、外形的な変化としては読み取れる材料が残っていました。

三つ目は、変化に気づける状態を作っておくことです。ファイルの改変を検知する仕組み、wp-config.phpや読み込み処理の周辺に見慣れない記述が増えていないかの確認、そして管理者アカウントの棚卸し。侵入を完全に防ぐ前提ではなく、入られたあと早く気づく前提で組んでおくほうが、この種の攻撃には噛み合います。

依存の数を意識するという話

WordPressの強みは、必要な機能をプラグインで足していける柔軟さにあります。制作会社としてもその恩恵は受けてきましたし、ゼロから作るより速く安く仕上げられる場面はいくらでもあります。ただ、その柔軟さは同時に、他人が書いたコードを自動で受け取り続ける関係を何本も抱えることでもあります。

プラグイン単体の良し悪しだけでなく、誰が作っていて、どういう経路で更新が届いていて、その開発元がいまも同じ人たちなのか。ここまで気にして選ぶのは手間ですが、今年の二件はその手間が無駄ではないことを示しています。次に一本足そうとしたとき、それが本当に必要かどうかを一度考えてみる。当たり前のようでいて、いちばん効く判断はそのあたりに残っている気がします。

WordPress本体に、ログインしていない相手がサーバー上で任意のコードを実行できてしまう脆弱性の組み合わせが見つかり、開発チームが緊急の修正版を公開しました。プラグインやテーマ側ではなく本体そのものの問題で、特別な設定や特定の拡張を入れていないサイトも対象になります。

公開は2026年7月17日。研究者が付けた「wp2shell」という呼び名で各所のセキュリティメディアが報じており、公開から数日のうちに実際に狙われている事例も確認されています。WordPressを扱っている制作者としては、いったん手を止めて手元の案件を見直しておきたい内容です。

本体だけで成立してしまう経路

今回問題になったのは二つの弱点です。ひとつは、WordPress 6.9で導入されたREST APIのバッチ処理用エンドポイントで、複数のリクエストをまとめて処理する際に権限の確認が正しく働かない場合があるというもの。もうひとつは、WP_Queryのauthor__not_inというパラメータに残っていたSQLインジェクションの穴で、こちらは6.8の系統から存在していたとされています。

単独で見ればどちらも即座に致命傷というわけではないのですが、順につないでいくと、認証を一切通らないまま任意のコードの実行まで到達します。プラグインを一つも入れていない素のWordPressでも成立する点が、今回いちばん重く受け止められている理由です。REST APIは投稿画面やブロックエディタが日常的に使っている入口なので、単純に閉じてしまえば済むという性質のものでもありません。

対象になる版と修正が入った版

修正版として出ているのは 7.0.2、6.9.5、6.8.6 の三つです。7.0.0から7.0.1、6.9.0から6.9.4、そして6.8系の古い版が対象に含まれます。自分の案件がどの系統で止まっているかによって、上げるべき先が変わる形です。

数年前に納品してそのまま動いている中小企業のサイトほど、メジャー更新を意図的に止めているケースが多いはずです。テーマや古いプラグインとの相性を心配して更新を保留する判断自体は珍しくありませんが、今回のように本体側で認証を通らない経路が見つかった場合は、その保留がそのまま危険の持ち越しになります。

なお、SQLインジェクション側の穴は6.8の系統から存在していたとされる一方で、実際に危険な連鎖として成立するのはREST APIの入口が加わった6.9以降です。古い版だから安全という話ではなく、修正版が出ている以上はどの系統でも上げておくのが素直な対応になります。

強制的な自動更新という対応

WordPress.orgは、対象となるサポート中のインストールに向けて自動更新を強制的に配信する措置を取りました。マイナー更新が自動で当たる仕組みは以前から用意されていましたが、深刻度に応じてここまで踏み込んだ形で運用されるのは、それだけ状況が急いでいるという合図と読めます。

ただし、この仕組みに全面的に寄りかかるのも避けたいところです。自動更新を明示的に無効化している環境、ファイルの書き換えを禁止している構成、独自の配置で運用しているサイトなどでは、そもそも配信が届きません。届いているつもりで届いていない、という状態がいちばん危ないパターンです。

受託で複数のサイトを預かっている立場だと、更新方針が案件ごとにばらばらというのもよくある話です。どのサイトが自動更新に任せてあって、どのサイトが手動運用なのか。今回のような場面で真っ先に効いてくるのは、その一覧がすぐ出てくるかどうかという、地味な管理の部分だったりします。

制作者側で確認しておきたいこと

まずは管理している各サイトのバージョンを実際に開いて確認するのが先です。更新が当たっているサイトはそれで終わりですが、当たっていないサイトが一つでも出てきたら、その環境で自動更新が働いていない理由を確かめておく価値があります。サーバー側で遮断する運用を取っている場合は、バッチ処理用のエンドポイントへの外部からのアクセスを一時的に止める手も選択肢に入ります。

抜けやすいのは、日常の運用から外れているサイトです。検証用に残したままの複製、しばらく更新していない古い案件、担当が変わって誰も見ていないサブドメイン。攻撃する側は運用の熱心さで対象を選り好みしないので、忘れられているサイトほど先に踏まれます。案件一覧を開いて、更新の当たり具合を一通り眺めておくだけでも、この週末の作業としては十分に意味があります。

WordPressのブロックエディタに、ブロック単位でタブレット表示とモバイル表示のスタイルを指定できる仕組みが入ろうとしています。開発版プラグインのGutenberg 23.5に含まれた変更で、8月19日に予定されているWordPress 7.1に向けた作業の一部です。7月3日にはコアチームからテスト協力の呼びかけも出ており、いまが仕様に意見を出せる時期でもあります。

これまでブロックエディタの画面幅切り替えは、デスクトップ、タブレット、モバイルという固定の三択でした。しかも切り替えられるのは見え方の確認だけで、余白や文字サイズといった値そのものを画面幅ごとに変えることはできません。細かく詰めたい場合は、テーマ側でCSSを書くか、追加CSSクラスを当てて自前のメディアクエリを用意するのが定番の逃げ道でした。今回の変更は、その前提を編集画面の側から作り直そうとしています。

プレビューの幅を自由にドラッグできるようになった

まず目に見えて変わるのが、エディタキャンバスの幅です。従来のプリセット三択はドロップダウンに残ったまま、キャンバス自体が任意の幅にドラッグできるリサイズ可能なものに変わりました。ドロップダウンとリサイズハンドルは連動していて、プリセットの幅に一気に飛ぶこともできれば、ハンドルを掴んで数十ピクセル単位で詰めることもできます。

実務では、崩れるのは決まってプリセットの三点ではなく、その間のどこかです。タブレット表示は問題ないのにやや狭い幅でボタンの文字が折り返す、といった話は日常的に出てきます。幅を連続的に動かせるだけで、そうした境目を編集画面の中で見つけやすくなります。ブロックにビューポート別の設定が入っている場合は、幅を動かすとその境目で表示と非表示が実際に切り替わるため、確認の粒度も上がります。

ブロックごとにタブレットとモバイルの値を持たせる

本題はスタイル側です。プレビューのドロップダウンにレスポンシブ編集の切り替えが追加され、これを有効にすると、そのとき選んでいる画面幅に対してスタイル変更が適用されるようになります。つまりタブレット幅で余白を変えれば、それはタブレットだけの指定として保存され、デスクトップの値は元のまま残ります。同じブロックにタブレットとモバイルで別々の値を持たせ、それぞれが独立して記憶される作りです。

対象は文字サイズだけではありません。テスト呼びかけの中でも、グループやボタン、画像といった異なるブロックで、余白や色を含む複数のプロパティを試してほしいと案内されています。加えて、ブロックの表示と非表示をタブレットだけ切り替えるといった指定も扱えます。これまで追加CSSクラスと自作のメディアクエリで運用していた類の調整が、エディタの標準機能の側に寄ってくることになります。

ブロックの作り手にとっての線引き

制作会社の視点で押さえておきたいのは、恩恵が自動で行き渡る範囲がはっきり分かれている点です。標準のブロックサポートを使って実装されたブロックは、特別な対応をしなくてもレスポンシブなスタイル指定に対応します。一方で、独自のコントロールを自前で組んでいるブロックは対象外で、追いつくには手を入れる必要があります。自社製のカスタムブロックや、独自UIを持つプラグインを抱えているサイトほど、この線引きは効いてきます。

もう一点、useResizeCanvas() というフックが非推奨となり動作しなくなりました。getDeviceType() と setDeviceType() は引き続き使えます。エディタの幅制御に手を入れているテーマやプラグインを持っているなら、7.1が出る前に一度検索をかけておくと安全です。この手の変更は、リリース後に管理画面が白くなってから気づくのがいちばん厄介なので、ベータ期間のうちに確認できるのはありがたいところです。

運用の現場でどう効いてくるか

中小企業のサイトでは、公開後の細かな見た目の調整をお客様自身が行う場面が少なくありません。そのとき、スマートフォンだけ余白を詰めたいという要望に対して、これまでは制作側がCSSを書き足すしかありませんでした。ブロックの設定として持てるようになれば、依頼の往復が一段減ります。地方の小さな制作体制ほど、この手の細かい差し戻しが積み上がって時間を食っている実感があります。

ただし現時点ではまだテスト段階で、仕様も細部が動く可能性があります。本番サイトの開発版プラグインで試すのではなく、ステージング環境や検証用サイトで触るのが前提です。逆に言えば、いま試して違和感を報告すれば、8月のリリースに反映される余地があります。ブロックテーマを使っているサイトを一つ用意して、手持ちのブロックがどこまで追従するかを見ておくと、7.1が出たときの案内が具体的になります。

ウェブサイトの土台としてWordPressを使っている制作者や事業者にとって、次のバージョンで何が増えるかは気になるところです。2026年7月15日に、次期版となるWordPress 7.1のベータ1が公開されました。正式リリースは8月19日が予定されています。今回のバージョンはブロックの追加とデザイン調整の作り込みが目立ちます。今回は編集画面に加わる新しいブロックを中心に、実際の制作でどう役立ちそうかという視点で並べて紹介します。ベータは開発中の段階なので、ここで挙げた仕様は正式版までに変わる可能性がある点は念頭に置いてください。

タブ切り替えを標準ブロックで作れる

これまでタブ形式の表示は、プラグインや独自のJavaScriptに頼るのが一般的でした。7.1ではTabsブロックが標準で加わり、料金プランの比較や、よくある質問の分類などを、コードを書かずにタブでまとめられるようになります。標準機能として編集画面に組み込まれているため、表示のためだけに入れていたプラグインを一つ減らせる場面も出てきます。プラグインが増えるほど更新や不具合対応の手間もかさむので、保守を軽くしたい中小企業のサイトとは相性がよさそうです。

目次ブロックは7.1では見送られた

長い記事に目次を付けたいときも、これまでは専用プラグインが定番でした。7.1のロードマップにはTable of Contents(目次)ブロックも挙がっていましたが、正式版に入った新しいブロックはTabsとPlaylistで、目次ブロックは見送られました。標準ブロックで目次を組めるようになるのは、先の版を待つことになります。

音声をまとめて並べるプレイリスト

Playlist(プレイリスト)ブロックは、複数の音声ファイルを一覧として並べ、続けて再生できるようにするものです。ポッドキャストの配信ページや、社内向けの音声資料をまとめるページなどで使い道があります。あわせて、複数の画像を柔軟に扱えるギャラリーの新しい型も実験的に用意されており、メディアを見せる場面での表現の幅が広がりつつあります。動画や音声を扱うページはこれまで外部の埋め込みサービスに頼りがちでしたが、標準ブロックで完結できれば表示の速さや管理のしやすさの面でも扱いやすくなります。

画面幅ごとに見た目を細かく調整できる

ブロックそのものだけでなく、デザインを整える仕組みにも手が入っています。レスポンシブスタイリングによって、同じブロックでもパソコンとスマートフォンで余白や配置を分けて指定できるようになります。加えて、サイト全体のデザイン設定(グローバルスタイル)に文字の影が加わり、グリッドやフレックスで組んだ並びが意図せず縮んだり崩れたりしにくくする調整も入りました。これまでCSSを直接書いて対応していた細かな見た目の調整が、編集画面の操作だけで届く範囲に少しずつ近づいています。ブロックとブロックの内容を結びつけるブロックバインディングも箇条書きの項目まで扱えるようになり、繰り返しの多いページを組みやすくなっています。

ベータ版はそのまま本番サイトに入れるものではありませんが、正式リリースの前に検証環境で触っておくと、公開後の切り替えがスムーズになります。プラグインで補ってきた機能が標準側に取り込まれていく流れは、サイトの構成をできるだけシンプルに保つうえでも見逃せない動きです。詳しい仕様はWordPress開発者向けの公式ニュースで確認できます。

WordPress本体に、公開済みのバージョンを細かく手入れする小さな更新が届いた。派手な新機能の発表ではないので見過ごされやすいが、日々サイトを預かる立場からすると案外大事な話なので、手短に共有したい。

WordPress.orgの告知によると、7.0.1が2026年7月9日に公開された。これは5月に登場したメジャー版7.0のあとに見つかった不具合を直すメンテナンスリリースで、ブロックエディター、管理画面、メディアまわりを中心に31件の修正が入っている。新しい機能を足すものではなく、すでにある動きを安定させるための更新という位置づけになる。

31件という数字だけ見ると多く感じるかもしれないが、メジャー版の直後に出る最初のメンテナンスリリースとしてはよくある規模だ。大勢が使い始めて初めて表面化する細かな不具合を、報告を受けて短い周期でまとめて直す。ブロックエディターや管理画面は制作者が毎日触れる場所なので、ここが少しずつ安定していくのは地味ながらありがたい。

マイナー更新は自動で当たることが多い

こうしたマイナー更新は、自動バックグラウンド更新が有効なサイトであれば、管理画面を開かなくても順に適用されていく。手動で運用している場合は、ダッシュボードの「更新」から今すぐ当てられる。特別な準備はいらず、作業としては数分で終わることがほとんどだ。

マイナー更新はメジャー版のように仕様が大きく変わるものではないため、更新でレイアウトやプラグインが急に動かなくなる心配は基本的に小さい。だからこそ自動更新に任せておける部分でもある。もちろん本番前にステージング環境がある案件なら、そこで一度確認してから本番へ、という手順を挟めばより安心できる。

WordPressは初期設定でマイナー更新だけを自動で当て、メジャー版は手動に委ねる作りになっている。つまり7.0.1のような更新は放っておいても順に届く一方、7.0から7.1へといった大きな移行は自分のタイミングで判断できる。運用を任されている側からすると、この線引きを理解しておくと、顧客に「どこまでが自動で、どこからが手動の判断か」を説明しやすくなる。トラブルを避けたいからと自動更新まで止めてしまうと、かえって細かな修正が当たらず古いままになりやすいので、少なくともマイナー更新は生かしておくのが無難だ。

現場では「問題なく動いているから触らない」という判断になりがちだが、メンテナンスリリースは表示の崩れやエディターの引っかかりといった、実際に手を止められる不具合を静かに潰している。安定性やセキュリティに関わる修正が含まれることも多いので、後回しにする理由はあまりない。中小企業のサイトや個人で回している案件ほど、更新通知に気づかず古いまま放置されやすいので、自動更新が効いているかを一度確認しておくとよい。

次のメジャー版7.1は、8月19日のWordCamp USに合わせて公開が予定されている。大きな変更点はそのとき改めて追うとして、まずは足元の7.0.1を当てて土台を整えておきたい。

ウェブサイトのお問い合わせフォームや会員登録の通知メールを確実に届けるために使われるのが、メール送信系のプラグインです。今回、その代表的なひとつであるGravity SMTPに、設定情報がまるごと外部から読み取れてしまう脆弱性が見つかり、世界中で攻撃が観測されました。約10万サイトが利用していたこと、そして修正版が出た後に攻撃が急増したことから、更新を後回しにしているサイトにとって他人事ではない事例になっています。

ひとつのリクエストで設定情報が丸見えになる仕組み

問題の脆弱性はCVE-2026-4020として公開されました。深刻度は中程度とされていますが、実際の影響は小さくありません。原因は、プラグインが用意していたREST APIの入り口にありました。本来は管理者だけがアクセスできるべきテスト用のエンドポイントが、アクセス権のチェックを常に許可で返す設定になっていたのです。

その結果、ログインしていない誰でも特定のURLを叩くだけで、サイトの設定内容をまとめた診断レポートを受け取れてしまいました。レポートには、メール配信サービスと連携するためのAPIキーやシークレット、OAuthトークンといった、本来は決して外に出してはいけない資格情報が含まれていました。攻撃者から見れば、鍵の束が置かれた扉が開けっ放しになっていたようなものです。しかも返ってくるレポートは数百キロバイトに及ぶ大きなもので、そこに並ぶ項目を眺めるだけで、どこを突けばよいかがひと目で分かってしまいます。

漏れるのはメールの設定だけではない

今回の脆弱性で特に厄介なのは、露出する情報がそのサイトの中だけにとどまらない点です。Gravity SMTPはAmazon SESやGoogle、Mailjet、Resend、Zohoなど外部のメール配信サービスと連携します。つまり漏れた資格情報は、そうした外部サービスのアカウントを操作するための鍵でもあります。

これを手に入れた攻撃者は、正規のサイトになりすまして大量のメールを送りつけたり、迷惑メールの踏み台にしたりできます。送信元が本物のドメインなので受け取った側は見抜きにくく、ブランドの信用にも傷がつきます。診断レポートには利用中のプラグインやテーマ、各種バージョン情報も含まれるため、次の攻撃の下調べにも使われます。ひとつの穴が連鎖的に別の被害へつながっていく構図です。

修正版が出た後に攻撃が急増した

見逃せないのは時間の流れです。開発元はこの問題を修正したバージョン2.1.5を3月に公開していました。ところが攻撃が本格化したのは、それから2か月以上たった5月末から6月にかけてでした。セキュリティ企業のWordfenceは、この脆弱性を狙った攻撃を合計で1700万件以上ブロックしたと報告しています。

なぜ修正後に攻撃が増えるのか。脆弱性の詳細が公開されると、その情報をもとに攻撃を自動化するツールが作られ、更新していないサイトを一斉に探し始めるからです。パッチが出た瞬間が安全の到達点ではなく、むしろ攻撃者にとっての号砲になることもあります。この順序は、規模の大小を問わずすべてのサイト運営者が意識しておきたいところです。

中小規模のサイトが取るべき現実的な対応

まず基本は、プラグインを最新版に保つことです。自動更新を有効にしておけば、修正版が出てから狙われるまでの時間差をかなり縮められます。管理画面を毎日見られない運用でも、更新だけは自動に任せる価値があります。

そして今回のように資格情報が漏れうる脆弱性では、更新だけでは不十分です。すでに露出していた可能性がある以上、連携先サービスのAPIキーやトークンを作り直す、いわゆる再発行が欠かせません。古い鍵を無効にして初めて、盗まれた情報が使えなくなります。地方の制作現場でクライアントのサイトを預かっている場合は、この鍵の入れ替えまでを一連の作業として案内できると安心です。

もう少し長い目で見れば、プラグインを選ぶ段階での目配りも効いてきます。更新の頻度や、脆弱性が報告されたときの対応の速さは、公開されている更新履歴からある程度読み取れます。必要以上に多機能なプラグインを詰め込まないこと、使わなくなったものはこまめに削除することも、攻撃の入り口を減らす地道な守りになります。あわせて、被害に早く気づく備えも役立ちます。連携先サービスの送信履歴や請求額に不自然な急増がないかを時々見ておくと、万一鍵が悪用された場合でも初動を早められます。RESONIXでもサイトを預かる際は、動かすことと同じくらい、こうした更新と権限の設計を大切にしています。

ページを開いた瞬間に次の画面が表示される。そんな体験を、JavaScriptのライブラリを足さずにブラウザの標準機能だけで実現する動きが広がっている。投機的読み込み(speculative loading)と呼ばれる仕組みで、Chromeを中心に実装が進み、WordPressにも標準機能として組み込まれた。表示速度は検索評価にも使い勝手にも直結する話なので、地方の制作現場でも知っておいて損はない。

ただ、この仕組みは入れれば速くなるという単純なものではない。先に読み込むという性質上、アクセス解析の数値が狂ったりサーバーの負荷が増えたりといった副作用がある。今回は投機的読み込みの考え方と、実務で使うときに気をつけたい点を整理してみる。

投機的読み込みとは何か

投機的読み込みは、利用者が次に開きそうなページを、実際にクリックする前にブラウザが裏側で先に取得しておく仕組みだ。土台になっているのがSpeculation Rules APIで、どのURLをどのタイミングで先読みするかをルールとして宣言できる。従来もlink要素によるprefetchのような先読み手段はあったが、Speculation Rules APIはより細かく、より積極的な制御ができる点が違う。

先読みの積極度はeagernessという段階で指定する。控えめな設定はリンクを押した瞬間に動き、中間の設定はリンクにカーソルを合わせたりタップしかけた段階で動く。さらに積極的な設定にすれば、リンクが画面に入った時点で先読みを始める。押してから読み込むのではなく、押しそうな気配を見て先に動くという発想だ。

この気配の読み方はスマートフォンでも工夫が進んでいる。最近のChromeでは、リンクが画面内に入ってから短い時間を置いて先読みを始める挙動が入り、指がまだリンクに触れていない段階でも準備を進められるようになった。マウスのホバーがないタッチ環境では、こうした画面内に入ったという合図が先読みのきっかけとして重みを持つ。

プリフェッチとプリレンダーの違い

投機的読み込みには大きく二つのモードがある。プリフェッチ(prefetch)は次のページのHTMLなど主要な資源を先に取得しておくだけで、ページの組み立ては利用者が実際に移動してから行う。取得済みのぶん移動が速くなるが、効果は限定的だ。

もう一つのプリレンダー(prerender)は、資源の取得だけでなくページの描画まで裏側で済ませてしまう。利用者が移動した瞬間には完成した画面を差し出すだけになるので、体感はほぼ一瞬になる。表示速度の指標で言えばLCPやINPが大きく改善し、ほぼ瞬時と呼べる速さが出る。

効果が大きいぶん、プリレンダーは踏み込んだ挙動になる。描画までするということは、そのページのJavaScriptが裏側で実際に走るということでもある。ここが後述する副作用の入り口になる。

WordPressに標準搭載された投機的読み込み

この仕組みは、WordPress 6.8でコアに取り込まれた。もともとは実験的なプラグインとして提供され、多くのサイトで検証を重ねたうえで安定版に昇格し、コア標準機能になったという経緯がある。特別なプラグインを入れなくても、きれいなパーマリンクを使っているサイトなら初期状態で先読みが働くようになっている。

ただしコアの初期設定は安全側に振ってある。ログインしていない訪問者に対して、控えめな積極度でプリフェッチだけを行う。描画まで踏み込むプリレンダーや、より積極的な設定は初期状態では有効にならない。より強い効果を求める場合は、公式のSpeculative Loadingプラグインを入れると、設定画面からモードや積極度を選べる。プラグイン側の初期値はプリレンダーの中間設定で、コアより一歩踏み込んだ構成になっている。

使いどころとして向いているのは、複数ページを続けて見てもらう性質のサイトだ。ブログや事例紹介、ドキュメント、商品一覧などは相性がよい。一方でカート内や決済の流れのように、先に走らせると困る処理を含むページはプリレンダーの対象から外すのが定石になっている。

先読みが引き起こす副作用

投機的読み込み、とくにプリレンダーで注意したいのがアクセス解析への影響だ。プリレンダーはページのJavaScriptを先に走らせるため、ページ表示を記録する計測タグが、利用者がまだ移動していない段階で発火してしまうことがある。結果として、実際には見られていない訪問がアクセス解析に記録される。

実際にWordPress 6.8の投機的読み込みで、GA4などに幻の訪問が計上される事例が報告されている。数字が水増しされれば、直帰率や滞在時間といった指標の読み方が狂い、サイト改善の判断を誤りかねない。対策として、主要な計測ツールの一部は、ページが実際に表示される瞬間まで計測を保留する仕組みを持っている。導入するなら、使っている計測ツールが先読みに対応しているかを確かめておきたい。

ブラウザ側でも副作用を抑える改良が進んでいる。最近のChromeには、プリレンダー中に最初の外部スクリプトの手前で処理をいったん止め、CSSや画像、フォントの先読みは進めつつ計測タグなどの実行だけを保留する挙動が加わった。裏側で読み込みは進めても、実際に表示されるまで余計な処理を走らせないという方向で、先読みと計測の食い違いを和らげる狙いがある。

もう一つはサーバーへの負荷だ。訪問者が実際に開くより多くのページを先に取得させるので、そのぶんアクセスが増える。多くの閲覧者を抱えるサイトや、動的にページを組み立てる構成では、キャッシュの整備なしに踏み込むと負荷が読みにくくなる。ログイン利用者にまで先読みを広げるかどうかは、サーバーが耐えられるかを見てから決めるのが安全だ。

対応ブラウザの現実

効果の大きい仕組みだが、すべてのブラウザで使えるわけではない点も押さえておきたい。Speculation Rules APIはChromeやEdge、OperaといったChromium系ブラウザで実装されている一方、SafariやFirefoxは現時点で対応していない。対応していないブラウザは、書かれた先読みのルールを単に無視するだけなので、表示が壊れるわけではない。

つまり投機的読み込みは、対応ブラウザの利用者だけが速さの恩恵を受け、それ以外の利用者はこれまで通りという上乗せ型の改善になる。壊れないという安心感がある半面、全員に効く施策ではないので、これ一本で表示速度を語るのは早い。土台となるページ自体の軽さや画像の最適化といった基本があってこそ効いてくる。

中小企業サイトでの取り入れ方

では現場でどう扱うか。まず、WordPressで運用していてきれいなパーマリンクを使っているなら、コアの控えめな先読みはすでに働いている可能性が高い。ここは特別な作業なしに得られている速さなので、まず現状を把握するところから始めるとよい。

そのうえでもう一段速くしたい場合は、プリレンダーへの引き上げを検討する。ただし前述のとおり、アクセス解析の数値と決済まわりの挙動は必ず先に確認する。小さく試して、計測の数字が乱れないか、サーバーの負荷が跳ねないかを見ながら広げるのが現実的だ。ChromeのDevToolsには先読みの挙動を確認する機能があるので、想定通りに動いているかを目で確かめられる。

投機的読み込みは、派手さはないが体感速度をはっきり押し上げる技術だ。ブラウザ標準の仕組みに寄せることで、重いライブラリを足さずに使い勝手を上げられる方向は、限られた予算でサイトを育てる中小の制作現場と相性がよい。副作用を理解したうえで、小さく取り入れていく価値はある。

WordPressのセキュリティをめぐる状況が、数字でみると想像以上に厳しい。Patchstackが2026年に公開したセキュリティホワイトペーパーによると、2025年に発見されたWordPressエコシステムの新しい脆弱性は11,334件にのぼり、前年比42%増となった。しかも2025年に見つかった深刻度の高い脆弱性の数は、その前の2年分を合計した数を上回っている。問題は件数だけではない。

脆弱性が公開されてから最初に悪用されるまでの中央値が5時間という数字だ。重大な脆弱性の20%は開示後6時間以内に攻撃に使われており、45%は24時間以内、70%は7日以内に悪用されている。「パッチが出たら更新する」という従来の対処では、悪用のスピードに追いつかない現実がある。同レポートでは、標準的なホスティング環境の防御機能がブロックできる攻撃は全体の26%にとどまると指摘しており、残り74%はホスト側の仕組みだけでは防ぎきれないとされている。

もうひとつ気になるのは、52%のプラグイン開発者が脆弱性を外部に公開する前にパッチを用意できていないという現状だ。開示と悪用がほぼ同時に起きる状況が珍しくなくなっており、運営するサイトに不審な動きがなくても、使っているプラグインやテーマが攻撃の対象になっている可能性がある。WordPressサイトの保守を受け持つ制作会社にとって、この数字は改めて自動更新やセキュリティプラグインの有効性を見直す契機になるだろう。

EUが義務化する脆弱性開示プログラム

こうした状況を背景に、EU（欧州連合）がサイバーレジリエンス法（Cyber Resilience Act、CRA）の要件として、2026年9月から商業目的のWordPressプラグインとテーマに脆弱性開示プログラム（VDP）の設置を義務付ける。対象は開発者がEUのユーザーに販売・提供するもので、WordPress.orgやCodeCanyonを通じた配布も含まれる。脆弱性を把握してから24時間以内に当局へ速報、72時間以内に正式報告、是正措置後14日以内に最終報告という対応期限が定められており、重大な違反には最大で売上高の2.5%または1,500万ユーロ相当の制裁金が科される。

Patchstackはこの義務化に先立ち、プラグイン・テーマ開発者向けに無償の脆弱性開示プラットフォームを提供しており、すでに650以上のプラグインが参加している。ElementorやWP Rocketもその中に含まれる。義務化によってWordPressエコシステム全体でセキュリティプロセスを形式化する流れが加速しており、開発者と利用者の双方にとって脆弱性情報の透明性が高まることが期待されている。

制作現場の視点では、プラグインの選定基準に「VDPが整備されているか」という軸が加わりそうだ。更新が止まったプラグインや、脆弱性の対応履歴が公開されていないものは、今後EUマーケットから実質的に排除されていく可能性がある。日本のサイトを運営する場合でも、採用するプラグインが国際的なセキュリティ基準を満たしているかを確認しておくことが、長期的な保守コスト削減につながる。