7月31日頃、エックスサーバーが顧客のWordPressを更新しました。その事実が公表されたのは、3週間ほどあとの8月24日です。本体の管理は、原則として利用者の側にあります。それでも押されたボタンは、何を肩代わりし、どこから先を私たちに残したのでしょうか。
エックスサーバーは2026年8月24日、WordPressの脆弱性「wp2shell」（CVE-2026-63030／CVE-2026-60137）への対応として、システムで検知した影響対象バージョンの利用者に対しWordPressのアップデートを実施したと公式Xで公表した。
該当顧客には個別にメールで案内している。そのメールによれば、実施は7月31日頃で、7.0.0〜7.0.1は7.0.2へ、6.9.0〜6.9.4は6.9.5へ更新された。メールは事後の案内であることを明記したうえで、自動更新ですでに新しい版へ進んだ環境が古い版に戻ることはないとしている。
同社は7月19日にREST APIのバッチエンドポイントへの通信を遮断し、8月6日に脆弱なバージョンを使うドメインを除いて解除していた。
まず、お使いのバージョンを確認してください
まず、お使いのWordPressのバージョンを確認してください。管理画面のダッシュボードから「更新」を開けば分かります。7月に事業者側で更新された環境も、そこで止まっている可能性があります。
そのうえで、この夏に起きたことを順に見ていきます。
押した日と、告げた日
7月17日、WordPress.orgが7.0.2、6.9.5、6.8.6を公開しました。深刻さを踏まえ、影響を受けるサイトには自動更新システムによる強制更新も有効にしています。
7月19日午前6時半頃、エックスサーバーは攻撃経路となるREST APIのバッチエンドポイント、/wp-json/batch/v1への通信を遮断しました。同社はこれを暫定的な措置と位置づけ、恒久的な対策としては利用者自身によるアップデートを求めています。
そして7月31日頃、同社は影響対象のWordPressに対してマイナーアップデートを順次実施しました。WordPress本体の管理は、原則として利用者の側にあります。それでも同社は、顧客のアプリケーションに手を入れました。
公式Xでその事実が公表されたのは、8月24日です。翌25日には公式サイトの告知にも追記が入り、同じ日、私の手元にも該当アカウントの契約者として個別のメールが届きました。冒頭に「事後のご案内となり大変恐縮でございますが」と書かれています。実施が7月31日頃だったこと、7.0.0から7.0.1は7.0.2へ、6.9.0から6.9.4は6.9.5へ上げたこと。いずれもこのメールで示された内容です。Xの投稿と公式サイトの追記が伝えているのは、実施したという事実までです。
押した日と、告げた日のあいだに、3週間ほどの開きがありました。
なぜ事業者が押す必要があったのでしょうか。WordPress.orgの強制更新は7月17日に有効化されています。それでも残ったサイトがあった、ということです。なぜ残ったのかは、この記事の後半でもう一度出てきます。
運んでくれるのは「7月17日の安全地帯」まで
そのうえで、更新後のバージョンを見てください。7.0.2と6.9.5です。7月17日時点の正解であり、いまの正解ではありません。
8月6日に7.0.3系が出ています。XSS2Shellを含む12件の修正です。8月12日には7.0.4系、8月19日にはメジャーバージョンの7.1「Mary Lou」。押されたボタンが連れて行ってくれるのは、押された日の安全地帯までです。
メールが求めた、二つのこと
だからメールの二つ目の依頼、自動アップデートが有効になっているかを確認してほしいという一文が、今回いちばん重いのだと思います。事業者は一度だけ肩代わりし、その先はご自分で走ってください、と言っている。線の引き方としては筋が通っています。
同じメールには、すでに自動更新で6.9.7や7.0.4へ進んでいる環境が古い版へ巻き戻ることはない、とも明記されていました。強制的な更新でいちばん怖いのは巻き戻りです。そこに一行を割いているのは、率直に丁寧だと感じました。
一つ目の依頼は、不正アクセスの痕跡を確認してほしい、というものでした。更新は鍵の交換であって、家の中の点検ではありません。すでに入られていたなら、鍵を替えても中に残ったものは消えない。事業者が代われるのは鍵までという線引きは、限界というより役割分担として妥当だと思います。
なお、メールが更新対象として挙げていたのは7.0系と6.9系です。6.8系はRCEの連鎖の対象外で、SQLインジェクションのみの影響を受けます。6.8系をどう扱ったかは、公表されていません。
三つの呼び名
公式Xは「自動アップデートを実施しました」、メールの件名は「強制アップデート」、メール本文は「マイナーアップデートの実施」。同じ一つの行為に、三つの言い方が並んでいます。
Xの投稿からも、公式サイトの追記からも、更新したこと自体は読み取れます。ただ、いつ、どのバージョンからどこまで上げたのかは、個別メールを開いて初めて分かりました。緊急対応のさなかに使った言葉を、あとから一本に揃えるのは難しい。これは同じ立場に立ちうるホスティング事業者と制作会社にとって、そのまま自分の宿題でもあります。
制作の現場は、どう受け止めたか
この一件を、同じ仕事をしている人たちがどう受け止めたのかも見ておきたいと思います。反応が集まったのは、公式Xの投稿の翌日、8月25日でした。
サイト制作と保守管理を手がけるピクセリウム株式会社の佐藤浩司氏は、緊急性の高い脆弱性にサーバー側でも検知・対応してもらえるのはありがたい、と受け止めています。そのうえで、日頃の本体・テーマ・プラグインの更新も忘れずに、と付け加えています。
WordPressの修復・保守を請け負う瀬尾真氏は、サーバーが強制的に更新しなければならないほど深刻だった、と読みました。あわせて、プラグインの更新まで止められているケースがあるとして、対象サイトの全面的な見直しを促しています。
この「止められている」が、今回いちばん重い指摘だと思います。
横浜WordPress Meetupを主宰し、自身もWeb制作会社を営む石井秀幸氏は、同じ日にもっと長い文章を書いています。wp2shellで考えさせられたのは脆弱性の中身よりも、更新を止めた状態で納品されていたサイトが実在したことだった、と。
制作側が自動更新を切り、さらに更新を止めるプラグインまで入れて納品する。クライアントは更新の必要に気づけません。石井氏は、独自テーマのfunctions.phpに更新停止のコードが仕込まれているのは珍しい事故ではなく、業界にそれなりの数で存在する運用だと書いています。
更新を止める設定が、救済の網を閉じる
そして、ここが先ほどの問いにつながります。コアの自動更新まで停止する設定やプラグインは、WordPress.orgが強制自動更新を有効にした場合でも、その更新を阻止しえます。
7月17日にWordPress.orgが救済の網を広げても、サイト側の設定によっては、自動更新が実行されない場合があります。その要因の一つになりうるのが、納品時に残された更新停止の設定やプラグインです。制作側が良かれと思って固定した「完成形」が、数ヶ月後に救済経路を閉じることがある。ただし、今回検知されたサイトがなぜ残っていたのか、その理由は公表されていません。
石井氏の結論は、事業者への異議ではありません。壊れたくないから更新しない、ではなく、壊れる前提で先に試す運用に変える。ステージングで更新を確認する手順を持てば、止める理由はほぼなくなる、と書いています。保守契約のない案件でも、せめてセキュリティ更新は自動のまま渡すべきだ、とも書き添えています。
代わりに押されたということは、自分が押していなかったということです。この受け止め方は、事業者を責める向きよりもよほど厳しい。厳しさが自分のほうを向いています。
事後になったことを、どう読むか
先に手を動かし、あとから知らせた。順番としては逆です。ただ、同社が判断の根拠に挙げているのは、悪用されるリスクと緊急性でした。告知の準備を待つあいだ、脆弱なサイトは脆弱なまま公開され続けます。その時間を短くするほうを選んだと読めば、順番には理由があります。
私は、押したこと自体は支持します。利用者自身に更新を求めるだけに留める選択肢もあった場面で、同社は顧客環境の更新まで実施しました。その半歩は、評価されていいと思います。
ここからは、少し長い射程の話をします。
押す人が、動きはじめている
スマートフォンのOSも、ブラウザも、セキュリティ更新を自動で届ける仕組みが広く採用されるようになりました。利用者や管理者が方針を変えられる製品もあります。
WordPressでも、マネージドホスティングでは事業者がコアの更新を代行する運用が以前からあります。エックスサーバー自身、WordPress専用のサービスでは自動アップデートを機能として用意しています。
今回が違うのは、更新が止まっていた環境に対して、事業者の側から実行されたことです。メールの二つ目の依頼が自動アップデートの有効化だったことは、そこを裏づけています。合意して預けた更新ではなく、預けていなかった更新が動きました。
そしてこれから、AIエージェントが人の代わりに操作する場面が増えます。誰が、どこまで、代わりに押していいのか。この問いは緊急対応から始まって、もっと日常的な場面へ広がっていきます。今回のこの夏は、その先取りだったのかもしれません。
守る場所が動いただけではなく、押す人が動きはじめている。
更新を済ませたら、次はご自分のサイトでコアの自動更新が有効になっているかを確認してください。管理画面の表示だけでなく、更新制御プラグインや wp-config.php、ホスト側の設定で止められていないかも見てください。その設定が、次の緊急更新を自力で受け取れるかどうかを決めます。
【関連記事】
WordPressコアに認証前RCE「wp2shell」、6.9／7.0系に影響 7.0.2などで修正
7月の公表を伝えた記事。脆弱性そのものの成立条件と、影響を受けるバージョンの範囲を整理しており、一連の記事の出発点にあたる。
WordPress、守る場所は管理画面からAPIへ｜wp2shellが示したもの
攻撃面が管理画面からAPIへ移ったことを論じた記事。守るべき場所の変化を、サイトを設計する側の視点から読み解いている内容。
WordPressにXSS2Shell、全バージョン影響 公式が緊急更新を呼びかけ
8月6日の7.0.3で修正された別系統の脆弱性を扱った記事。wp2shellとの成立条件の違いを詳しく整理している内容である。
「25ドル対50万ドル」GPT-5.6 Sol × wp2shell が問い直すAIセキュリティ研究の民主化
AIが脆弱性発見の担い手になりつつある流れを、wp2shellの事例から論じた記事。発見にかかった費用の対比も扱っている。
【編集部後記】
7月19日のお知らせに、一行だけ気になる注意書きがありました。自動更新を有効にしている場合も、実際に更新が完了しているか管理画面で確認してほしい、というものです。
7月の時点で、すでにそう書かれていました。更新の仕組みを持っていることと、更新されていることは違う。その距離を、事業者は最初から知っていたのだと思います。
ご自分のサイトのバージョンは、今日、目で見て確かめましたか。
【用語解説】
wp2shell
WordPressコアの2つの不具合を連鎖させ、認証なしで任意のコードを実行しうる攻撃手法の通称。発見者が名付けた。
CVE-2026-63030
共通脆弱性識別子。REST APIのバッチ処理で、どの要求がどの処理にあたるかの対応がずれる不具合を指す。
CVE-2026-60137
共通脆弱性識別子。投稿を検索する内部処理に細工した値を渡せてしまう不具合で、SQLインジェクションにあたる。
REST API
外部のプログラムがWordPressを操作するための入口。標準で有効になっている。
バッチエンドポイント
複数の操作をまとめて1回の通信で受け付ける接続口。WordPressでは /wp-json/batch/v1 にあたる。
RCE
リモートコード実行。外部から任意のプログラムを動かされる状態を指し、サイトの乗っ取りにつながる。
SQLインジェクション
入力値の扱いの不備を突き、データベースへ意図しない命令を送り込む攻撃手法。
強制自動更新
WordPress.orgが深刻な脆弱性に際し、影響を受けるバージョンへ更新を配信する仕組み。サイト側の設定によっては実行されない。
マイナーアップデート
7.0.1から7.0.2のように、同じメジャー系統のなかで行われる更新。不具合やセキュリティ問題の修正に加え、既存機能の小さな改善を含むこともある。
XSS2Shell
8月6日の7.0.3系で修正された別系統の脆弱性。管理者の操作を起点とする点でwp2shellと成立条件が異なる。
functions.php
WordPressのテーマに含まれる、機能を追加・変更するためのファイル。自動更新を止める記述を書き込むこともできる。
wp-config.php
WordPressの基本設定を記述するファイル。自動更新の可否もここで制御できる。
ステージング
本番と同じ構成を持つ検証用の環境。更新の影響を公開前に確かめる用途で使う。
更新制御プラグイン
コアやプラグインの更新を停止・制限するために導入されるプラグインの総称。
【参考リンク】
エックスサーバー（外部）
エックスサーバー株式会社が運営する国内のレンタルサーバー。今回、影響対象の顧客サイトでWordPress本体の更新を実施した。
【重要】WordPressの脆弱性（wp2shell／CVE-2026-63030）に関する注意喚起とサーバー側対策のお知らせ（外部）
同社の公式告知。7月19日公開で、8月25日の追記により、影響対象の利用者へ自動アップデートを実施した旨が示されている。
エックスサーバー【公式】（@xserverjp）2026年8月24日の投稿（外部）
実施を公表した投稿。システムで検知した影響対象バージョンを利用していた顧客に対し、WordPressの更新を実施したとしている。
WordPress.org（外部）
WordPressの公式サイト。最新版の入手先と、セキュリティリリースの告知を掲載しており、更新の要否をここで確認できる。
wp2shell（外部）
発見者が公開した専用サイト。影響を受けるバージョンの一覧と、修正版へ更新するまでのあいだに取れる三つの緩和策を掲載している。
Searchlight Cyber（外部）
wp2shellを報告した英国のセキュリティ企業。攻撃対象領域を管理するASM製品Assetnoteを提供し、研究成果を公開している。
横浜WordPress Meetup（外部）
WordPress公式チャプターとして神奈川で開かれている勉強会。石井秀幸氏が2022年8月から主宰し、交流の場を続けている。
ピクセリウム株式会社（外部）
佐藤浩司氏が代表を務めるWeb制作会社。制作のみの契約は原則として承らず、公開後の保守管理を含めた提供を基本としている。
セオリコ（外部）
瀬尾真氏が運営するSEOとWordPressのサポートサービス。エラー修正やハッキングによる改ざんの修復を手がけている。
【参考記事】
wp2shell: Pre Authentication RCE in WordPress Core（外部）
発見者による初報。影響を受けるバージョンと、更新できない場合に取れる二つの一時的な緩和策を示す。公開時点では技術詳細を伏せている。
WordPressの深刻度「緊急」脆弱性 wp2shell の概要と対応指針（外部）
GMO Flatt Securityによる解説。悪用時に残る痕跡と、HTTPメソッドの上書きを見落とさないログ確認手順を扱う。
WordPress 7.0.2 Release（外部）
7月17日のセキュリティリリース告知。影響を受けるバージョンに対し、自動更新システムによる強制更新を有効にした旨が明記されている。
WordPressの脆弱性「wp2shell」 古いバージョンでも自動更新していても安心できない理由（外部）
CloudflareやWAF事業者の初動を時系列で整理した記事。パッチを当てる前にすでに攻撃を受けていた可能性にも触れている。
WordPress Coreの脆弱性「wp2shell」（CVE-2026-63030、CVE-2026-60137）について（外部）
サイバーセキュリティクラウドによる告知。影響バージョンごとの更新先に加え、7.1 Beta 1も対象だった点を明記している。
