【ConoHa WING】PHP2Shell対応：WordPressサイトをSSHで安全に「メンテナンス中」にする手順

SHARE

結論：WordPressのファイルを公開フォルダの外へ退避し、.htaccess で全リクエストを503のメンテナンス画面に向けるのが、安全で戻しやすい方法でした。

PHPは1行も実行されず、訪問者にも「一時停止中」と伝わります。

この記事では、ConoHa WINGのファイルマネージャーが使えない状況で、MacからSSHだけで次の作業をする手順をまとめます。

  • WordPressのファイルとデータベースのバックアップ
  • メンテナンス画面への切り替え
  • 元の状態への戻し方

共用サーバーでzipが強制終了された件など、実際につまずいた点もあわせて載せています。

目次 非表示

PHP2Shellとは：ConoHa WINGの状況

PHP2Shellは、2026年10月21日に修正版が公開されたPHPの脆弱性2件です。

認証なしで遠隔からコードを実行される恐れがあり、深刻度はCVSS v4.0で9.2（Critical）です。

項目内容
CVECVE-2026-109618 / CVE-2026-109619
影響Webリクエストを処理するPHP（PHP-FPM、mod_php、php-cgiなど）
修正版8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
8.1以前公式の修正なし。8.2以上への変更が必要
経緯10月20日に、修正版の公開前に情報が流出

ConoHa WINGは、10月21日19時〜22日10時に緊急メンテナンスを行いました。

ただし、告知の作業内容は「システムの保守作業」とだけ書かれており、PHPへの言及はありません。

22日には、ファイルマネージャーとWebメールの予防的な一時停止も告知されています。

共用サーバーでは、PHP本体の修正は利用者側では当てられません。利用者にできるのは、次の3つです。

  • 使うPHPの系列を8.2以上にする
  • 修正版が適用されたかを確認する
  • 確認できるまでサイトを止めておく

止め方の比較：なぜ「退避＋503」にしたか

ConoHa WINGには、サイトを一時停止するボタンはありません。

サイト設定のゴミ箱アイコンやサーバー削除は、削除や解約の操作です。

方法PHPは止まるか訪問者の見え方戻しやすさ
メンテナンス用プラグイン止まらない（プラグイン自体がPHP）メンテナンス画面簡単
.htaccess に Require all denied止まる403 Forbidden（乗っ取りに見えかねない）1行消すだけ
ファイルを削除してHTMLを置く止まるメンテナンス画面数千ファイルの再アップロードが必要
公開フォルダの外へ退避＋503止まるメンテナンス画面（503）mv 1回

503は「一時的に利用できない」という意味のステータスコードです。

検索エンジンにも一時停止として伝わるので、検索順位への影響を抑えられます。

手順1：MacからSSH接続する

ファイルマネージャーが502で使えなかったため、SSHで作業しました。

以下の ユーザー名 と ホスト名 は、ご自分の値に置き換えてください。

  1. ConoHa WINGの「サーバー管理」→「SSH」でSSHを「ON」にし、「+SSH Key」で鍵を作成して .pem をダウンロードします。鍵は二度とダウンロードできません。
  2. 同じ画面で、ホスト名・ポート（通常8022）・ユーザー名を控えます。
  3. Macのターミナルで、鍵を移動して権限を絞ります。
mkdir -p ~/.ssh
mv ~/Downloads/key-xxxx.pem ~/.ssh/conoha.pem
chmod 600 ~/.ssh/conoha.pem
  1. 接続します。
ssh -i ~/.ssh/conoha.pem -o IdentitiesOnly=yes -o ServerAliveInterval=30 -p 8022 ユーザー名@ホスト名
  • IdentitiesOnly=yes：Macにある他の鍵を試させない（Permission denied (publickey) の対策）
  • ServerAliveInterval=30：30秒ごとに通信を送り、長い処理の途中で接続が切れるのを防ぐ
  • 最近のmacOSでは「post-quantum key exchange」のWARNINGが出ますが、接続には影響しません

手順2：バックアップを取る

WordPressのバックアップは、ファイルとデータベースの2つです。

example.com は、ご自分のドメインのフォルダ名に置き換えてください。

ファイル：強制終了されないzipの作り方

普通に zip -r を実行したところ、共用サーバーのCPU制限で「強制終了」されました。

そこで、次の4点を加えています。

mkdir -p ~/backup
cd ~/public_html
nohup nice -n 19 zip -r -1 -q -b ~/backup ~/backup/site_$(date +%Y%m%d).zip example.com > ~/backup/zip.log 2>&1 &
オプション目的
nohup … &SSHが切れても処理を続ける
nice -n 19優先度を最低にする
-1（それでもダメなら -0）圧縮を軽くする（-0 は圧縮なし）
-b ~/backup一時ファイルの置き場所を固定する

Enterは1回だけ押してください。

2回実行すると、2つのzipが同じファイルに書き込みます。

進み具合は次のコマンドで確認します。

ps ux | grep [z]ip              # 1行だけ出ていれば処理中、何も出なければ終了
ls -lh ~/backup/
unzip -t ~/backup/site_*.zip | tail -1   # 「No errors detected」ならOK

データベース

接続情報は wp-config.php にあります。

grep -E "DB_(NAME|USER|PASSWORD|HOST)" ~/public_html/example.com/wp-config.php
mysqldump -h DBホスト -u DBユーザー -p DB名 > ~/backup/db_$(date +%Y%m%d).sql
tail -1 ~/backup/db_*.sql      # 「-- Dump completed」ならOK

Macに持ってくる

SSHを切ってから、Mac側で実行します。届いたら、サーバー上の ~/backup は削除してください。

scp -P 8022 -i ~/.ssh/conoha.pem "ユーザー名@ホスト名:~/backup/*" ~/Desktop/

scp だけは、ポートの指定が大文字の -P です。

手順3：ファイルを退避してメンテナンス画面にする

最初に .htaccess の控えを取る

.htaccess には、WordPressのURL設定やプラグインの設定が入っています。書き換える前に、必ず控えを取ってください。

cd ~/public_html/example.com
cp .htaccess .htaccess.orig

私は最初の緊急対応で、.htaccess の中身を Require all denied の1行に置き換えてしまいました。

その後に取ったバックアップにもその状態で入ったため、元の内容は残っていませんでした。

これが、再開後に投稿を保存できなくなる原因になりました（再開の手順で詳しく書きます）。

メンテナンス画面のHTMLを用意する

画像やCSSへのリクエストも503になるため、スタイルはHTMLの中にすべて書き込み、外部ファイルを読み込まない1枚のHTMLにします。<meta name="robots" content="noindex"> も入れておきます。用意できたら、Macからアップロードします。

scp -P 8022 -i ~/.ssh/conoha.pem ~/Downloads/maintenance.html ユーザー名@ホスト名:~/public_html/example.com/

WordPress一式を公開フォルダの外へ移動する

同じサーバー内の移動は名前を変えるだけなので、数千ファイルでも一瞬で終わります。

dotglob は、.htaccess などの隠しファイルも対象にするための設定です。

mkdir ~/wp_hold_example
cd ~/public_html/example.com
shopt -s dotglob
for f in *; do
  [ "$f" != "maintenance.html" ] && mv -- "$f" ~/wp_hold_example/
done
shopt -u dotglob
ls -la    # maintenance.html だけが残っていればOK

503を返す.htaccessを置く

cat > .htaccess <<'EOF'
ErrorDocument 503 /maintenance.html

<FilesMatch "\.php$">
  Require all denied
</FilesMatch>

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/maintenance\.html$
RewriteRule ^ - [R=503,L]
EOF
chmod 644 .htaccess maintenance.html

PHPファイルはもう公開フォルダにありませんが、念のため .php を拒否する設定も入れています。

確認する

curl -sI https://example.com/ | head -1
curl -sI https://example.com/wp-login.php | head -1

どちらも 503 が返り、ブラウザでメンテナンス画面が出れば完了です。

古いページが出る場合は、ConoHaのコンテンツキャッシュかブラウザのキャッシュをクリアしてください。

再開の手順

再開は、修正版のPHPが適用されたことを確認してから行います。確認する順番は次のとおりです。

  1. ConoHa WINGのニュースで、PHPへの対応の告知を確認する。
  2. 「サイト管理」→「サイト設定」→「応用設定」→「PHP設定」で、8.2以上の系列を選ぶ。
  3. 再開後に、PHPに修正が入っているかを確認する（次の項目を参照）。

ConoHa WINGでは、番号ではなくビルド日時で確認する

ConoHa WINGは、10月22日20時45分時点の終報で、すべてのPHPバージョンに番号を変えずにセキュリティパッチを適用したと発表しています。そのため、サイトヘルスやコントロールパネルの表示は修正前の番号のままです。

私の環境では、8.4.26と表示されました（PHP公式の修正版は8.4.27）。

番号の代わりに、PHPがビルドされた日時を見ると判断の目安になります。SSHで次を実行します。

php -i | grep -B3 "Build Date"

実際の結果は次のとおりでした（抜粋）。

PHP Version => 8.4.26
...
Build Date => Oct 21 2026 20:29:20
--
MMAP Support => Enabled
...
Build Date => Oct 12 2026 06:43:42
  • PHP Version の近くにある Build Date がPHP本体です。10月21日夜のビルドで、ConoHaの緊急メンテナンスの時間帯と一致します。
  • MMAP Support などと並ぶ2つ目の Build Date は、キャッシュ用の拡張機能APCuのものです。PHP本体とは関係ありません。

終報と本体のビルド日時がそろっていれば、修正済みと判断してよいでしょう。

ただし、ここで見ているのはSSHで使うPHP（CLI）です。

Webで動くPHPまで確実に知りたい場合は、ConoHaのサポートに確認してください。

ファイルを元の場所に戻します。

cd ~/public_html/example.com
rm .htaccess maintenance.html
shopt -s dotglob
mv ~/wp_hold_example/* .
shopt -u dotglob
rmdir ~/wp_hold_example     # エラーが出なければすべて戻っている
curl -sI https://example.com/ | head -1   # 200 ならOK

再開した後に、次の点を確認しておくと安心です。

  • WordPress本体・テーマ・プラグインを最新に更新した
  • 見覚えのない管理者ユーザーがいない
  • 最近更新された不審なPHPファイルや、.htaccess への不審な追記がない

再開後に投稿を保存できないとき

再開後、表示は正常なのに、投稿の保存も下書きの自動保存もできなくなりました。

ブラウザの開発者ツールのコンソールには、次のような404が出ていました。

POST https://example.com/wp-json/wp/v2/users/me?_locale=user 404 (Not Found)
POST https://example.com/wp-json/wp/v2/posts/1558/autosaves?_locale=user 404 (Not Found)

投稿画面（ブロックエディター）は、保存するときに /wp-json/ というURLに通信します。

このURLは、.htaccess の # BEGIN WordPress 〜 # END WordPress の設定がないと404になります。

確認すると、.htaccess は0バイト（空）でした。前の手順で控えを取らずに置き換えていたためです。

ls -la .htaccess*
curl -sI https://example.com/wp-json/ | head -1    # 404 なら設定が欠けている

直し方

  1. WordPressの「設定」→「パーマリンク」を開き、何も変えずに「変更を保存」を押す。WordPressが .htaccess に設定を書き直します。
  2. curl -sI https://example.com/wp-json/ | head -1 で 200 が返れば完了です。
  3. SiteGuardなどのセキュリティ系やキャッシュ系のプラグインを使っている場合は、それぞれの設定画面で一度保存し直します。これらの設定も .htaccess に入っていたためです。

元の .htaccess を正確に戻したい場合は、ConoHaの「サーバー管理」→「自動バックアップ」から、書き換える前の日付のものを探してください。

つまずきポイント

症状原因対処
ファイルマネージャーが502ConoHaによる予防的な一時停止SSHかFTPで作業する
Permission denied (publickey)鍵を指定していない、鍵の権限が広い-i と IdentitiesOnly=yes を付け、chmod 600 にする
zip中に「強制終了」CPU負荷による自動停止nice -n 19 と -1 / -0 を付ける
zi3miXEK のようなファイルが残る途中で止まったzipの一時ファイル削除してよい（-b で置き場所を固定すると探しやすい）
Broken pipe で接続が切れる無通信の時間が長いServerAliveInterval=30 を付け、nohup … & で実行する
CPU使用率が99%を超える圧縮処理が重い-0（圧縮なし）に切り替える
再開後、投稿を保存できない（/wp-json/ が404）.htaccess のWordPress設定が消えている「設定」→「パーマリンク」で「変更を保存」
表示が8.4.26のまま変わらないConoHaは番号を変えずにパッチを適用終報と php -i のBuild Dateで判断する

参考

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

CAPTCHA


前の記事

ConoHa WINGでサブドメインを作成し、Firebase…