XServerのWordPress脆弱性「wp2shell」は何を確認する？自動更新後に見るバージョンと不審な変更

XServerからWordPress脆弱性「wp2shell」の自動更新メールが届いても、確認はあと少しで終わります。管理画面で現在のバージョンを見たあと、身に覚えのない変更がないかを順番に確かめれば、次に何をするか判断できます。

ただし、「修正版へ更新された」と「更新前に侵害されていない」は別の確認です。自動アップデートの案内だけで完了にせず、WordPressとXServerの両方を見ておきましょう。

この記事では、2026年8月28日時点のXServerとWordPress公式情報をもとに、対象バージョン、管理画面で見る場所、不審点があった場合の止まり方を整理します。攻撃を再現する操作は行わず、防御側の確認だけに絞ります。

XServerのWordPress脆弱性は自動更新後も2つ確認する

最初に確認するのは、WordPressが修正版以降になっているかです。これは、wp2shellという脆弱性を使った新たな攻撃経路を塞げているかの確認になります。

次に、更新前の期間を含めて不審な変更がないかを確認します。更新によって、すでに追加された管理者や不正ファイルまで自動的に消えるとは限りません。

WordPress脆弱性wp2shellの影響バージョンと修正版

wp2shellは、WordPressコアの脆弱性CVE-2026-63030の通称です。XServer公式は、認証やログインを必要とせず、プラグインやテーマの有無にかかわらず対象バージョンが影響を受けると説明しています。

また、wp2shellと連携して悪用されるSQLインジェクションの脆弱性CVE-2026-60137があります。SQLインジェクションとは、データベースへの命令を不正に差し込む攻撃です。

利用系統	影響対象	修正版の最低ライン
WordPress 6.8系	6.8.0〜6.8.5	6.8.6以降
WordPress 6.9系	6.9.0〜6.9.4	6.9.5以降
WordPress 7.0系	7.0.0〜7.0.1	7.0.2以降

6.8系はCVE-2026-60137の影響対象で、6.9系と7.0系は2件の脆弱性が関係します。現在値が表の中央にあれば、自動更新を待たず、バックアップと互換性を確認して修正版以降へ更新してください。

出典: XServer「WordPressの脆弱性(wp2shell/CVE-2026-63030)に関する注意喚起とサーバー側対策のお知らせ」

WordPress公式も、6.9.5と7.0.2で2件を修正し、6.8.6で連携するSQLインジェクションを修正したと案内しています。6.8より前のWordPressは、この2件については対象外です。

出典: WordPress.org「WordPress 7.0.2 Release」(英語)

XServerが行ったwp2shell対策の時系列

XServerは、攻撃経路となるREST APIのbatch v1への通信を2026年7月19日午前6時30分頃に遮断しました。REST APIは外部システムとWordPressが情報をやり取りする入口で、遮断は被害を抑える暫定措置です。

その後、XServerは影響対象と検知したWordPress環境へ、7月31日頃から8月25日にかけて順次自動アップデートを実施しました。緊急性を優先したため、更新の実施が利用者への案内より先になっています。

8月6日時点では、影響を受けるバージョンを使うドメインを除き、batch v1の遮断は解除されました。さらに8月27日、XServerは不審な変更とアクセス痕跡を確認する簡易セルフチェックを動画で公開し、公式ニュースから案内しています。

自動更新後に確認する5項目

WordPress管理画面へ入ったら、バージョンから表示確認までを上から順番に見ます。途中で異常を見つけたら、その場で削除せず、後述する記録へ切り替えてください。

1. ダッシュボードの更新画面で現在バージョンを見る

管理画面の「ダッシュボード」→「更新」を開き、現在のWordPressバージョンを画面キャプチャまたは運用メモへ残します。自動更新メールに書かれた内容ではなく、いま管理画面に表示される値を確認するのがポイントです。

影響対象のままなら、先ほどの表にある修正版以降へ更新します。
更新ボタンを押す前に、ファイルとデータベースのバックアップが取れているかを確かめておきます。

2. ユーザー一覧で身に覚えのない管理者を見る

「ユーザー」→「ユーザー一覧」を開き、管理者権限を持つアカウントを確認します。
知らない表示名、メールアドレス、最近追加された管理者があれば、名前・メールアドレス・権限を記録してから操作を止めます。

3. 投稿・固定ページ・メニューの変更を見る

投稿と固定ページでは、身に覚えのない新規ページ、タイトル変更、非公開化、不審な外部リンクを確認します。
公開ページだけでなく、下書きやゴミ箱も見ておくと変更を追いやすくなります。

ヘッダーやフッターのリンクが変わっている場合は、外観側のメニューやテーマ設定も確認します。表示だけ直して終わらせず、変更元を探すことが再発防止につながります。

4. プラグインとテーマの追加・有効化を見る

「プラグイン」→「インストール済みプラグイン」と「外観」→「テーマ」を開きます。
未導入のもの、勝手に有効化・無効化されたもの、更新されていないものがないかを確かめます。

wp2shellはWordPressコアの問題なので、怪しいプラグインが見当たらないことだけでは安全判定になりません。一方で、侵害後に別のプラグインが追加される可能性を考え、一覧は確認対象に含めます。

5. PCとスマートフォンで実際の表示を見る

トップページ、問い合わせフォーム、主要な下層ページをPCとスマートフォンで開きます。
意図しない転送、警告、広告、見覚えのない文字列、ログイン不能がないかを見ておきましょう。

• 現在バージョンを記録した
• 管理者ユーザーを照合した
• 投稿・固定ページ・メニューを確認した
• プラグインとテーマを確認した
• PCとスマートフォンで表示を確認した

XServer側で不審な変更とアクセス痕跡を確認する

WordPress管理画面に異常がなくても、ファイルの変更やアクセスの痕跡はサーバー側に残る場合があります。XServerが8月27日に公開したwp2shellの簡易セルフチェック動画に沿って、対象ドメインを確認してください。

出典: XServer公式YouTube「WordPress脆弱性『wp2shell』による不正アクセス状況確認」

• 身に覚えのないファイルやフォルダがないか
• 主要ファイルの更新日時に心当たりがあるか
• 対象期間のアクセスログを保存できるか
• XServerから不正アクセス検知メールが届いていないか

ログの保存期間や設定によって、確認できる範囲は変わります。
読めない文字列を無理に判断せず、対象期間のログを保存して保守担当へ渡すだけでも調査の助けになります。

不正アクセス時の初動はサーバー会社が違っても共通する部分があります。記録する項目をもう少し詳しく確認したい場合は、利用者が確認するメール・管理者・不審ファイルの整理も参考にしてください。

不審点が見つかったときにやってはいけないこと

身に覚えのない管理者やファイルを見つけたら、早く消したくなるものです。しかし、原因と影響範囲が分からないまま一部だけ削除すると、別の侵入経路を残し、調査材料も失うおそれがあります。

急いでしないこと	先にすること
怪しいファイルだけ削除	パス・時刻・画面を記録
バックアップを上書き復元	復元日とクリーン性を確認
公開PoCを本番で実行	公式の防御確認に限定
全パスワードを無計画に変更	影響拡大防止の順序を決定

先に残す記録は5つ

相談先へ渡すのは、対象ドメイン、発見日時、現在バージョン、不審点、実施済み操作の5つです。
ファイルならパスと更新時刻、ユーザーなら表示名・メールアドレス・権限も残します。

ログインできない、意図しない転送が続く、個人情報への影響が疑われる場合は、自社だけで調査を続けず、XServerサポートまたは保守会社へ早めに共有してください。公開停止やアクセス制限が必要かも、この段階で相談します。

XServer公式は、不正アクセス時の対処としてクリーンなデータからの復旧、管理パスワードの変更、FTPアカウントのパスワード変更・削除を案内し、予防策としてWordPress・プラグイン・テーマの更新を挙げています。復元する日付だけでなく、バックアップ自体に改ざんがないかも確認が必要です。

出典: XServer「不正アクセス(ファイルの改ざん、不正なファイル設置)について」

出典: XServer「WordPressリカバリー」

異常がない場合の再発防止

一次確認で異常が見つからなくても、更新・認証・不要物・バックアップの4点を整えておくと、次の脆弱性対応が早くなります。wp2shellだけの臨時対応で終わらせず、普段の運用へ戻しましょう。

• WordPress本体、プラグイン、テーマをサポート対象の最新版へ近づける
• 不要な管理者、FTPアカウント、未使用プラグイン・テーマを削除する
• XServer、サーバーパネル、WordPressでパスワードを使い回さない
• 二段階認証、WordPressセキュリティ設定、WAFを確認する
• ファイルとデータベースを復元できる形でバックアップする
• 管理者一覧と更新日を定期的に記録する

WAFは、Webアプリケーションへの不審な通信を防ぐ仕組みですが、WordPress本体の更新を代替するものではありません。遮断や防御設定と、脆弱性を直すアップデートを分けて運用します。

XServerアカウントの認証を見直す場合は、XServerの二段階認証と復旧経路の解説を確認してください。サイト全体の対策は、中小企業が最低限行うホームページのセキュリティ対策で点検できます。

XServerのWordPress不正アクセスを自社だけで判断できない場合

自社でできるのは、現在値を確認し、異常を記録し、変更を増やさずに相談材料をそろえるところまでです。ログ解析、全ファイルの差分確認、データベース調査、クリーンな復旧判断は、WordPressとサーバーに詳しい担当へ渡します。

保守契約がある場合は、障害対応・更新・バックアップ・復旧のどこまでが含まれるかも確認しましょう。ホームページ保守会社へ頼める作業と契約範囲に、確認項目をまとめています。

担当会社がいない、問い合わせ内容を整理できない場合は、ノーサイドへご相談ください。いま分かっている記録から、確認範囲と復旧後の運用を一緒に切り分けます。

よくある質問

XServerのWordPress脆弱性を確認する順番まとめ

XServerの自動更新後は、現在バージョン→WordPress内の変更→サーバー側の痕跡の順で確認します。修正ラインは6.8.6、6.9.5、7.0.2以降ですが、バージョンだけで侵害なしとは判断しません。