WordPressの強制アップデート通知が届いたら？wp2shell脆弱性で確認すべき4つのこと

結論からお伝えします。サーバー会社から届いた「WordPressの脆弱性（wp2shell）に関する強制アップデート」の通知は、迷惑メールでも宣伝でもありません。ただし、慌ててWordPressを操作する必要もありません。アップデート自体はサーバー会社やWordPressの自動更新がすでに済ませているケースが大半だからです。

やるべきことは4つの確認です。①本当に更新されたかの確認、②更新される前に侵入されていないかの確認、③自動更新設定の確認、そして見落とされがちな④使っていないWordPressが残っていないかの確認。この記事では、実際に通知を受け取った筆者が、この4つを順に解説します。

筆者は熊本でWeb制作とサーバー保守を行っている個人事業主です。2026年8月25日に、エックスサーバーから件名「■重要■ WordPressの脆弱性（wp2shell／CVE-2026-63030）に関する強制アップデートの実施について」というメールを実際に受信しました。その通知の読み解きと、受信後に行った確認をもとに書いています。

wp2shellとはどんな脆弱性？

wp2shellは、WordPress本体（コア）に見つかった2つの脆弱性を組み合わせた攻撃手法の通称です。ログイン不要で、外部の第三者がサイトを乗っ取れてしまう深刻なものです。

識別番号	種類	深刻度
CVE-2026-60137	SQLインジェクション	高
CVE-2026-63030	認証不要の任意コード実行	緊急

ポイントは3つあります。

• ログインや認証が不要で、外部から攻撃できる
• プラグインやテーマの脆弱性ではなく、WordPress本体の問題。「余計なプラグインを入れていないから大丈夫」は通用しない
• 対象バージョンを使っていれば、素の状態のWordPressでも影響を受ける

対象と修正版は次のとおりです。

対象バージョン	修正版
7.0.0〜7.0.1	7.0.2以降
6.9.0〜6.9.4	6.9.5以降
6.8.0〜6.8.5	6.8.6以降

修正版は2026年7月17日に公開されました。海外のセキュリティ企業からは、公開直後から実際の攻撃が観測されたという報告が出ています。詳細はJVNの脆弱性情報（CVE-2026-63030）と同（CVE-2026-60137）で確認できます。

なぜ「強制」アップデートが行われたの？

放置されたサイトが踏み台になるのを防ぐためです。今回は深刻度が高かったため、WordPress公式が自動更新システム経由の強制更新を有効にし、サーバー会社も独自の防御と一斉更新を行いました。

エックスサーバーの場合、対応は3段階でした（公式のお知らせより）。

日付	対応
2026年7月19日	攻撃に使われる通信経路（REST APIのバッチエンドポイント）を全サーバーで遮断
2026年8月6日	修正版に更新済みのサイトから順に遮断を解除
2026年7月末〜8月	対象バージョンのWordPressを順次自動アップデート

つまり利用者が気づく前に、防御壁を立ててから順番に手当てが行われていた、という流れです。「勝手にアップデートされた」と感じるかもしれませんが、今回に関しては放置されるより明確に安全側の対応です。

なお、サーバー会社からの通知には「フィッシングに注意」という一文が添えられていることがあります。似た件名の偽メールが出回る可能性もあるため、メール内のリンクを不用意に踏まず、サーバーの管理画面には普段使っているブックマークからログインしてください。

通知が届いたら何を確認すればいい？

確認は4つです。上から順に進めてください。

確認1：本当に修正版になっているか

自動更新の対象だったはずなのに、何らかの理由で更新が完了していないケースがあります。サーバー会社も「実際にアップデートが完了しているかは利用者側で確認してほしい」と案内しています。

WordPressの管理画面にログインし、「ダッシュボード」→「更新」で現在のバージョンを見てください。7.0.2以降、6.9.5以降、6.8.6以降のいずれかになっていれば修正済みです。まだ対象バージョンのままなら、バックアップを取ったうえで、その場で更新してください。

確認2：更新前に侵入されていないか

ここが一番重要です。修正版の公開は7月17日、攻撃の観測もその直後から始まっています。サーバー会社の一斉更新が7月末〜8月だとすると、その間に数週間の空白があります。アップデートは「これからの侵入」を防ぎますが、「すでに入られていた場合」は解決しません。

最低限、次の3点を見てください。

• 管理画面の「ユーザー」一覧に、身に覚えのない管理者アカウントがないか
• 「プラグイン」一覧に、入れた記憶のないものが追加されていないか
• 投稿・固定ページに、知らない記事や外部リンクが増えていないか

加えて、サーバーのファイルマネージャーやFTPで、更新日時が不自然に新しいファイルがないかを見られるとより確実です。サーバー会社が確認手順の動画や案内を公開している場合は、それに沿うのが早道です。

不審な点を見つけたときは、その場で削除や修復を始めないでください。攻撃の痕跡ごと消してしまい、侵入経路の特定ができなくなります。まず画面のスクリーンショットを残して証拠を保全し、そのうえでサーバー会社のサポートか制作会社に連絡してください。「これが正常なのか不審なのか判断がつかない」という段階の相談でも構いません。切り分け自体が専門側の仕事です。

確認3：自動更新が有効になっているか

今回のような本体の脆弱性は、今後も出ます。WordPressのマイナーアップデート（6.9.4→6.9.5のような末尾の数字の更新）は、セキュリティ修正が中心で互換性の問題が起きにくいため、自動更新を有効にしておくのが基本です。

管理画面の「ダッシュボード」→「更新」で、自動更新の設定状態が確認できます。「セキュリティとメンテナンスリリースのみ」以上になっていれば大丈夫です。

なお、大きな更新は話が別です。WordPress本体のメジャーアップデート（6.9→7.0のような数字の頭が変わる更新）と、サーバー側のPHPバージョン変更は、どちらも事前のバックアップとテストをしてから行うものです。PHPの方の手順はWordPressのPHPバージョンアップ手順で詳しく書いています。

確認4：使っていないWordPressが残っていないか

見落とされがちですが、実は今回筆者に一番刺さったのがこれです。

筆者のサイトは現在、WordPressを使わない静的サイトとして運用しています。それなのに通知が届きました。対象は、以前の構築時にサーバーへインストールしたまま残っていた、古いWordPressだったのです。

使っていないWordPressは、誰も管理画面を開かず、誰も更新の面倒を見ていません。つまり「使っていない」は「守られていない」と同じ意味になります。表向きのサイトが別の仕組みで動いていても、サーバー上にWordPressのファイルが残っていれば、そこが入口になり得ます。

サーバーの管理画面で、契約しているサーバーに何がインストールされているかを一度棚卸ししてください。過去に試して放置したもの、リニューアル前の旧サイト、テスト用に作ったもの。使う予定がないなら、バックアップを取ったうえで削除するのが最も確実な対策です。

サイトのリニューアルや静的サイトへの移行を考えている方は、WordPressとAstroの比較記事も参考にしてください。移行後の旧環境の後始末まで含めて計画するのが大事、というのが今回の教訓です。

更新で不具合が出たらどうする？

今回の修正版はマイナーアップデートのため、表示崩れや機能停止が起きる可能性は低めです。それでも万一に備えて、症状別の初動を知っておくと安心です。

症状	初動
画面が真っ白・エラー表示	プラグインを一旦すべて無効化し、1つずつ戻して原因を特定
表示は正常だがフォームが動かない	フォーム系プラグインの更新有無を確認
管理画面に入れない	サーバー会社のサポートに連絡

不具合の切り分けよりも「戻せる状態」を持っておくことが先です。サーバーの自動バックアップ機能が有効か、この機会に確認しておいてください。公開後のサイトで最低限やっておくべきことはホームページ公開後にやることにまとめています。

よくある質問

Q1. 通知が来たけれど、何もしていません。危険ですか？

アップデート自体はサーバー会社側で済んでいる可能性が高いですが、「完了しているかの確認」と「侵入されていないかの確認」は自動では行われません。自分でやるか、誰かに依頼する必要があります。この記事の確認1と確認2は、一次点検としてなら合わせて15分ほどでできるので、今日中に行ってください。ただしこれは表面のチェックであり、ログやファイルの差分まで調べる本格的な調査とは別物です。一次点検で不審な点が出たら、その時点で専門の窓口に切り替えてください。

Q2. 通知が来ていない場合は対象外と考えていいですか？

いいえ。サーバー会社によって通知の有無や範囲は異なります。管理画面でバージョンを直接確認するのが確実です。7.0.2以降・6.9.5以降・6.8.6以降なら修正済みです。

Q3. 乗っ取られていた場合、どんな兆候がありますか？

身に覚えのない管理者ユーザーの追加、知らないプラグインやファイル、勝手に増えた投稿や外部リンク、検索結果に出る自分のサイトのタイトルが書き換わっている、などが典型です。1つでも該当したら、自力での復旧より先にサーバー会社のサポートへ連絡してください。

Q4. 自動更新をあえて切っています。今回のような場合はどうすれば？

カスタマイズの都合などで自動更新を止めている場合は、セキュリティリリースの情報を自分で追い、即日で手動更新できる体制が前提になります。それが難しいなら、少なくともマイナーアップデートの自動更新は有効に戻すことをおすすめします。

Q5. 自分で確認する時間がありません。どこに頼めばいいですか？

契約中のサーバー会社のサポート、またはサイトを作った制作会社が窓口です。保守契約がない場合でも、スポットで確認を請ける制作者は多くいます。筆者の場合、サイトのURLを送っていただければ、外から確認できる範囲（WordPressの稼働有無・バージョンの推定・外形的な改ざんの兆候）をお返しします。管理画面やサーバーの中まで見る必要がある場合は、その旨と必要な準備をお伝えしたうえで対応します。

まとめ：通知は「終わった話」ではなく「確認の合図」

wp2shellはWordPress本体の深刻な脆弱性でしたが、WordPress公式とサーバー会社の対応は早く、多くのサイトは自動的に守られました。それでも、更新完了の確認・侵入痕跡の確認・自動更新の設定・放置WordPressの棚卸しの4つは、放っておいても誰もやってくれません。自分で行うか、保守を頼んでいる相手に「見てもらえましたか」と一声かけて、誰かの目を必ず通してください。

特に4つ目の「使っていないWordPress」は、通知が来て初めて存在を思い出すことがよくあります。筆者自身がそうでした。この機会に、契約サーバーの中身を一度見渡してみてください。

自分のサイトが大丈夫か不安な方は、お問い合わせからURLを送っていただければ、外から確認できる範囲（WordPressの稼働有無・バージョンの推定・外形的な改ざんの兆候）を無料でお返しします。そのうえで管理画面の中の確認が必要な場合は、必要な準備と手順をご案内します。対応が必要なら見積もりを、ご自身でできそうならやり方をお伝えする形です。