エックスサーバーのSSHとWP-CLIで古いWordPressをまとめて更新した手順｜脆弱性対応で16か所を上げた記録

【PR】本記事はアフィリエイト広告を含みます（エックスサーバー / A8.net）。

2026年9月、WordPress 本体に、ログインなしで外部からコードを実行されるおそれのある脆弱性（CVE-2026-87902）が公表されました。対象は4.7系から7.1系まで。勤務先で管理しているエックスサーバーの契約にも、何年も更新されていない WordPress がいくつも残っていました。10月上旬に SSH と WP-CLI でまとめて更新したときの手順と、つまずいた点を残します。

作業は Claude Code と分担しました。コマンドは自分の Mac のターミナルで実行し、Claude Code は出力を読んで判断するだけです。SSH の鍵とパスフレーズには触れさせていません。

エックスサーバーが更新してくれたのは一部だけ
先に決めたルール
準備：SSH を ON にして鍵を作る
つまずいた3つのこと
1サイト分の手順
結果と後片付け
エックスサーバーを選ぶ場合
1. 参考

エックスサーバーが更新してくれたのは一部だけ

エックスサーバーの告知によると、9月25日の夜に「攻撃が成立する条件に当てはまるサイト」だけを各系統の最新版へ更新し、対象者にはメールで個別に知らせたとのことです。条件に当てはまらないサイトは更新の対象外で、自分で9月22日以降の最新版に上げるよう求めています（公式ニュース）。上げる先は同じ系統の最新版（例：4.9系なら4.9.33）なので、大きなバージョンを飛び越える必要はありません。

最初に、各サイトの wp-links-opml.php と wp-login.php を外から読み、バージョンを調べました（読み取りだけ）。4.7系、4.8系、4.9.3、6.7系などが並び、版を表示しないサイトは SSH で wp core version を打って確かめました。4.9.3 は、自動更新が動かなくなる不具合を持った版です（WordPress 公式の告知）。一方、5.4系のサイトは自動更新が効いていて、アクセスした時点で最新版に上がっていました。

先に決めたルール

管理画面から1つずつではなく、SSH と WP-CLI でまとめて上げることにしました。

更新は同じ系統の修正版だけにして、wp-content（テーマ・プラグイン・画像）と wp-config.php には触らない。取引先のサイトは1件ずつ、OKをもらってから上げる。終わったら SSH を OFF に戻す。公式マニュアルも、接続しないときは SSH を無効にするよう案内しています。

準備：SSH を ON にして鍵を作る

エックスサーバーの SSH は公開鍵認証だけで、パスワードでは入れません。接続ポートは10022です（公式マニュアル：SSH設定）。サーバーパネルの「SSH設定」で ON にし、「公開鍵を登録」から鍵ペアを自動生成すると、秘密鍵（サーバーID.key）がダウンロードされます。鍵にはパスフレーズを設定しておくのがおすすめです。Mac では ~/.ssh/ に置いて chmod 600 をかけ、次のように接続を確かめます（xsample はサーバーIDの例）。

ssh -i ~/.ssh/xsample.key -p 10022 xsample@sv***.xserver.jp 'wp --info; php -v | head -1'

つまずいた3つのこと

1つ目は、最初から入っている WP-CLI が古かったことです。サーバーには wp コマンド（WP-CLI 2.4.0）が入っていましたが、証明書の一覧が古く、wordpress.org から本体をダウンロードできません（cURL error 60）。公式の最新版 wp-cli.phar をホームに置き、SHA-512 を照合してから php8.3 で動かしました。なお、エックスサーバーが WP-CLI を標準で提供しているかどうかは、公式マニュアルでは記載を確認できませんでした（公式マニュアル：プログラム言語・コマンドパス、2026年10月17日確認）。使う前に公式ページを確認し、接続後に wp --info で入っているかどうかと版を確かめてください。

2つ目は、新しい WP-CLI（2.12）の db export が失敗したことです。mariadb-dump を探しにいきますが、サーバーにあるのは mysqldump だけでした。DB の書き出しだけは、最初から入っている WP-CLI を php7.4 で動かして使いました。

3つ目は PHP の版の差です。SSH で使う php はサイトより新しく、古い WordPress を読むと「PHP Deprecated」が大量に出ます。害は無いので grep -v Deprecated で隠しました。

1サイト分の手順

実際に使った手順を、場所と版を例に置き換えて載せます。SSH でサーバーにログインした後、サーバー側で実行するコマンドです（手元の Mac で打つものではありません）。

S=$HOME/example.jp/public_html     # サイトの場所
V=4.9.33                           # 上げる先
W="php8.3 $HOME/wp-cli-new.phar"   # 新しい WP-CLI
WO="php7.4 $(which wp)"            # 最初から入っている WP-CLI（DB 書き出し用）
mkdir -p ~/wp_update_bk ~/wp_dl/$V
$W core version --path=$S
$WO db export ~/wp_update_bk/example.sql --path=$S
tar czf ~/wp_update_bk/example_core.tar.gz -C $S --exclude=./wp-content .
$W core download --version=$V --skip-content --path=$HOME/wp_dl/$V
cp -a ~/wp_dl/$V/. $S/
$W core version --path=$S
$W core verify-checksums --path=$S

DB と本体ファイル（wp-content を除く）を控えてから、公式の本体を別の場所に落とし、サイトへ上書きコピーします。--skip-content を付けているので、テーマやプラグインは上書きされません。最後の verify-checksums で、本体ファイルが公式と一致するかを確かめます。英語版の本体で上書きしても、wp-content/languages の日本語ファイルは残るので、管理画面は日本語のままでした。

更新の前後には、外からトップページとログイン画面の HTTP コード・サイズ・タイトルを記録して比べました。戻すときは tar xzf ~/wp_update_bk/example_core.tar.gz -C $S で本体ファイルを戻します。同じ系統内の更新なら DB の形式は変わらないので、通常はこれで元通りです。

結果と後片付け

メインの契約では WordPress が15か所見つかり、そのうち10か所を更新して、15か所すべてが修正版になりました（wordpress.org の判定で「危険な版」0）。各サイトとも前後の比較で表示の変化はありません。もう1つの契約では7か所見つかり、対象の6か所（うち5か所はテスト用）を上げて、すべて verify-checksums が通りました。前後の差は WordPress が自動で出す部分だけです。残る1か所は4.1系で、今回の脆弱性の対象外ですが古いままです。テスト用の1か所は、設定ファイルがもう存在しない外部の DB を指していて、DB のバックアップが取れませんでした。もともと動いていないサイトでした。

後片付けとして、落とした本体と新しい WP-CLI を消し、メインの契約の SSH を OFF に戻しました。バックアップ（約230MB）は1〜2週間様子を見てから消す予定です。もう1つの契約の SSH を OFF に戻すことと、作業する契約を取り違えて別の契約で作ってしまった鍵の片付けは、この記事を書いている時点ではまだ残っています。

追記（2026年10月20日）：残っていた後片付けも終えました。10月19日にメインの契約ともう1つの契約のバックアップを消し、消した後もサイトが表示されることを確かめました。10月20日には、もう1つの契約と、鍵を取り違えて作った契約の SSH も OFF にしました。鍵は登録したままですが、SSH が OFF なので接続には使えません。

なお、サーバーパネルの「WordPressセキュリティ設定」（国外アクセス制限やログイン試行回数制限）も全ドメイン確認し、1つだけ OFF だったログイン試行回数制限を ON にしました。ただ、これらは管理画面や XML-RPC を守る設定で、公開ページ経由の今回の脆弱性を直接は防ぎません。本体の更新が本筋だと考えています。