PHP脆弱性をチェック！WordPressセキュリティで実践した6つの点検

「PHPに重大な脆弱性」というニュースを見て、真っ先に気になったのは、管理しているサイトは大丈夫なのか、ということでした。

2026年10月21日に修正版が公開された PHP 脆弱性「php2shell」。共用サーバーを使っていると、PHP 本体は自分では更新できません。サーバー会社が直してくれるのを待つしかない。では、PHP の脆弱性が出たとき、管理者は何をすれば良いのか。実際に管理中のサイトで行った確認方法を、手順ごとにまとめました。

この記事は、こんな人に向けて書いています。

• クライアントの WordPress サイトを、共用サーバー（エックスサーバー等）で管理・保守している
• 自社の WordPress を自分で管理していて、PHP の脆弱性のニュースで自分のサイトへの影響が気になった
• 「サーバー会社が直したから大丈夫」と言い切ってよいのか迷っている
• 次に同じことが起きたときに、すぐ使える手順がほしい

【事前準備】点検の前に用意するもの

今回の点検は、次の環境で行いました。

• サーバー：エックスサーバー（共用サーバー）
• サイト：WordPress（7.1 系）／PHP 8.3 系
• 手元の PC：Mac（標準の「ターミナル」から SSH で接続）
• AI：Claude Code（点検用スクリプトの作成と、結果の判定に使用）

用意するものは次のとおりです。

• SSH で接続できる環境：サーバーパネルで SSH を ON にし、公開鍵を登録しておく（エックスサーバーは公開鍵認証のみ・接続ポートは 10022。公式マニュアルより・2026/10/24 時点）。手順はエックスサーバーの SSH 設定マニュアルにあります
• ターミナル（コマンドを打つ画面）：Mac は標準の「ターミナル」、Windows は「Windows Terminal」や「PowerShell」で足ります。Windows 10（1809 以降）・11 には、SSH の接続に使う ssh コマンド（OpenSSH クライアント）が用意されています。見つからない場合は、設定の「オプション機能」から OpenSSH クライアントを追加します（Microsoft のドキュメントより・2026/10/24 時点）
• WP-CLI：WordPress をコマンドで操作するツール。自分の環境（エックスサーバー）では、最初から入っていました（WP-CLI とは）
• サーバーパネルにログインできること：PHP の版の確認（STEP5）と、アクセスログの取得（STEP6）に使います
• 作業の記録：デプロイの記録や作業ログ。変更されたファイルの理由を確かめるとき（STEP4・STEP6）に使います
• 手元で照合する環境（必要なときだけ）：STEP3 のコマンドがサーバーで動かない場合に、照合用のスクリプトを手元の PC で動かします（自分は AI に書いてもらいました）。Mac・Windows のどちらでも、Python などのスクリプトが動けば足ります

GitHub Actions からのデプロイを扱った別の記事の中で、SSH の接続先（ホスト名・ユーザー名）の調べ方や、エックスサーバーの SSH 設定画面の見方を画面つきで紹介しています。

アルケイズム

GitHub ActionsでXserverにSSH接続できない原因と解決法

WordPress テーマの更新を毎回 FTP でアップロードするのをやめたくて、GitHub Actions で自動デ…

【概要】2026年10月の PHP 脆弱性「php2shell」とは

php2shell は、2026年10月21日（日本時間23時）に修正版が公開された、PHP 本体の脆弱性の通称です。識別番号は CVE-2026-109618 と CVE-2026-109619 の2件で、深刻度を表す CVSS（最大10）はどちらも 9.2。ログインなしで、外部からサーバー上のプログラムを実行される（RCE）おそれがあるものでした。

修正版は PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 です。PHP の公式アドバイザリによると、影響を受けるのは PHP-FPM や Apache の mod_php など、Web のリクエストを処理するすべての PHP 環境です。この脆弱性を今後突かれないかは、使っている PHP に修正が当たっているかで判断します（確かめ方は STEP5）。ただし、修正前に入られていないかは、別に点検が要ります（STEP2・STEP6）。

WordPress の管理者として押さえておきたいのは、プラグインやテーマ側の対策では防げないという点です。PHP 本体の問題なので、特に mod_php の環境では、アプリ（WordPress）のコードが動く前の段階で攻撃が成立するとされています。

PHP 脆弱性への対応で、管理者にできること・できないこと

共用サーバーでは、PHP 本体を管理しているのはサーバー会社です。利用者が修正版を入れることはできません。今回、エックスサーバーは次のように対応していました（エックスサーバー公式のお知らせより・2026/10/23 時点）。

• 10月21日 16:00：予防措置として、公式サイト・管理画面等を一時停止
• 10月22日 06:45：PHP 8.2〜8.5 の修正を、対象の全サーバーに適用完了
• 10月22日 09:30〜：管理画面を順次再開
• 10月22日 12:00 / 14:00：PHP 7.4〜8.1、5.6〜7.3 の修正も適用完了

管理画面が止まっている間も、自分の環境では SSH での接続とサイトの表示は動いていました。以下の点検は、この SSH で進めています。

では管理者は待つだけかというと、そうではありません。管理者の仕事は次の3つです。

• 確認：サーバー会社の更新が、管理するサイトに本当に届いたか
• 点検：パッチが当たるまでの間に、侵入されていないか
• 整理：古い PHP や使っていないサイトなど、穴になりうるものを片付ける（→ STEP5・「次に備えて」）

PHP の公式アドバイザリには、すぐ更新できない場合の暫定策（session.upload_progress.enabled = 0）も載っていました。ただし公式は、PHP-FPM の .user.ini には頼らず、リクエストの処理より前に効く php.ini やサーバー側の設定で入れるよう求めています。しかも、この設定で塞げるのは確認済みの攻撃経路だけで、ほかの変種は塞げないとされています。共用サーバーで手軽に触れる .user.ini で入れても、安心材料にはなりません。根本対策は修正版への更新です。なお PHP 公式は10月23日、別の経路（CVE-2026-115560）について告知を追加しました。アプリが実行中にセッションの保存形式（session.serialize_handler）を切り替えている、というまれな組み合わせでだけ起きるもので、次の定期リリースで修正されるまでは同じ設定を勧めています（PHP 公式サイトより・2026/10/24 時点）。

【確認方法】実際にやった6段階の点検

管理している WordPress サイトを、次の6段階で点検しました。

点検はすべて読み取りだけです。脆弱性を抱えたまま運用するのも、対策のつもりで設定を触ってサイトが見られなくなるのも、どちらもクライアントに迷惑がかかります。だから、まずはサイトに影響を与えない読み取りだけで状況をつかむことにしました。

【STEP1】対象の洗い出し

点検するサイトを全部挙げます。手元の管理表だけでなく、サーバーにログインして実際の設置場所も見ておくのがおすすめです。管理表に載っていないサイトは、点検からも漏れます。

ls ~/                                                   # ドメインの一覧
find ~/*/public_html -maxdepth 2 -name wp-config.php    # サブフォルダに置いた WordPress も拾える

【STEP2】侵入痕跡の点検（パッチを待たずに）

今回は、修正版が公開されるより前から、攻撃できると主張するコードが出回っていました。パッチを待っても、すでに起きた侵入は消えません。早く見つけるほど、被害が広がる前に手を打てます。だから修正版の公開当夜に1回目を行いました。

# 1. 一時領域に置かれた PHP（攻撃で書き込まれやすい場所）
find /tmp /var/tmp ~/tmp -maxdepth 2 -name '*.php' -user "$(whoami)" 2>/dev/null

# 2. アップロード用フォルダの PHP（本来ほぼ無いはず）
find ~/*/public_html -path '*/uploads/*' -name '*.php' 2>/dev/null

# 3. 起点の日時以降に変更された PHP（キャッシュは除く）
#    起点は攻撃コードが出回り始めるより前に置く（今回は '2026-10-21 00:00'）
find ~/*/public_html -type f -name '*.php' -newermt '<起点の日時>' -not -path '*/cache/*' 2>/dev/null

# 4. 起点の日時以降に変更された .htaccess / .user.ini
find ~/*/public_html ( -name '.htaccess' -o -name '.user.ini' ) -newermt '<起点の日時>' 2>/dev/null

# 5. 管理者ユーザーと登録日（WP-CLI）
wp --path=<WP> --skip-plugins --skip-themes user list --role=administrator --fields=user_login,user_registered

結果は、一時領域の PHP はゼロ、管理者に見覚えのないアカウントもありませんでした。uploads の中には PHP が見つかりましたが、最適化プラグインが置く付属ファイルで、日付も古く問題ありませんでした。

ポイント：一覧に件数の上限を付けない。 自分は、AI に書いてもらった点検スクリプトに表示件数の上限（head -100）が入っていたのに気づかず、一覧が途中で切れたまま見ていました。判定は AI に任せても、結果が全件そろっているかは人が確かめるのが安全です。

【STEP3】本体・プラグインの改ざんチェック

WordPress 本体とプラグインのファイルが、公式の配布物から書き換えられていないかを、公式のチェックサム（ファイルの指紋）と照合します。

wp --path=<WP> --skip-plugins --skip-themes core verify-checksums
wp --path=<WP> --skip-plugins --skip-themes plugin verify-checksums --all

自分の環境では、一部のサーバーでこのコマンドが証明書エラー（cURL error 60）で動きませんでした。その場合は、照合だけ手元で行います。

1. <WP> で、各ファイルの md5 の一覧だけを取り出す（find . -type f -print0 | xargs -0 md5sum）。uploads・キャッシュ・バックアップのフォルダは外す
2. 手元で公式チェックサムを取得する（本体：https://api.wordpress.org/core/checksums/1.0/?version=<版>&locale=<言語>／プラグイン：https://downloads.wordpress.org/plugin-checksums/<スラッグ>/<版>.json）
3. 本体は wp-content 以外のファイル、プラグインはフォルダごとに公式の一覧と比べ、「中身が違うファイル」「公式に無いファイル」を洗い出す（自分は照合用の小さなスクリプトを AI に書いてもらいました）

これで管理しているサイトすべてを照合でき、どれも公式の配布物と一致しました。公式に無いファイルとして出てきたのは、ログイン URL を変えるセキュリティプラグインが作るファイル1種類だけで、手元のものと中身が一致しました。

ポイント：照合できる範囲を知っておく。 公式チェックサムで照合できるのは、wordpress.org で配布されている本体・プラグインだけです。自作テーマや有料プラグインは対象外なので、STEP2 の変更日時で見ます。

【STEP4】変更されたファイルを1件ずつ説明づける

STEP2 の「起点の日時以降に変更されたファイル」は数百件出ました。ほとんどはプラグインの自動更新です。1件残らず「なぜ変わったのか」の説明をつけます。自分の場合は、次のどれかに当てはまりました。

• WordPress 本体・プラグインの自動更新（STEP3 で公式と一致を確認）
• 翻訳ファイルの自動更新
• 自分の作業（デプロイの記録や作業ログと照合）
• プラグインが自動で作るファイル（ログ、キャッシュの設定、ログイン認証の一時ファイルと見られるもの）

説明がつかないものだけを深掘りすれば済みます。

【STEP5】サーバー会社の更新を確かめる

更新を待つ間は、こちらのペースでは進められません。STEP2〜4 を先に済ませておくと、更新後すぐにクローズまで進めます。修正の告知が出たら、自分のサーバーに本当に届いたかを確かめます。見るのは3つです。

• サーバー会社のお知らせ：適用範囲と完了時刻
• サーバー上の PHP の版：php8.3 -r 'echo PHP_VERSION;' のように、版ごとに確認する
• サーバーパネルで、各ドメインの PHP の版：コマンドで見えるのはコマンドライン用の PHP なので、サイトが実際に使う版はパネルで見ます

ポイント：版番号だけで判断しない。 自分の環境では、古い系列（8.1 以前）は修正が入っても版番号が変わっていませんでした。その場合はお知らせで確認します。また、使っていないドメインも含めて全部見てください。自分は、契約時に付いてくる初期ドメインだけが 8.1 のまま残っていました。修正は当たっていましたが、古い版なので 8.3 系に切り替えています。

【STEP6】2回目の点検でクローズ

1回目の点検から、パッチが当たるまでの間も攻撃は受けえます。そこで、1回目の少し前の時刻を起点に、STEP2〜4 をもう一度行いました。

2回目では、STEP5 で初期ドメインの PHP を切り替えたことで .user.ini が作り直されていたのが引っかかりました。中身はサーバー会社の標準の設定で、問題ありません。自分の操作で変わるファイルも出てくるので、作業の記録と照らし合わせます。

2回目も痕跡は無く、これでクローズしました。パッチ前とパッチ後の2回の点検がそろって、はじめて「侵入・改ざんの痕跡は無い」と言える根拠になります。サーバー会社の「適用完了」は穴が塞がったことの証明で、塞がる前に入られていないことの証明ではないからです。

あわせて、アクセスログ（誰がどこにアクセスしたかの記録）も確認しました。エックスサーバーでは、サーバーパネルの「アクセスログ」で過去30日分を見られます（公式マニュアルより・2026/10/23 時点）。攻撃コードが出回ってからパッチが当たるまでの時間帯について、外部からの POST の集中やサーバーエラーを見ました。エラーは WAF が止めた2件だけで、php2shell を狙ったと見られるアクセスは見当たりませんでした。

ポイント：ログのフォルダが空でも、ログが無いとは限らない。 自分は最初、サーバー上の log フォルダが空なのを見て「ログは残っていない」と思い込みました。実際は、パネルで取得できました。パネルで見られるのは過去30日分だけなので、緊急時は早めに取得してください。

【ポイント】AI と分担して進めるときの注意

今回は、点検の手順づくりと結果の判定を Claude Code に任せました。手順・予防策・改善案まで速く正確に出してくれて、自分で手を動かす部分も、何をどうすればいいかを分かりやすく案内してくれたので迷いませんでした。

分担は「本番での実行は人、判定は AI」にしました。自分の環境では、Claude Code の自動モードが本番サーバーへの接続を（読み取りでも）止めたためです。点検用のスクリプトを用意してもらい、実行は自分、結果の判定は AI です。

次に備えてやっておくこと

• アクセスログの取り方を確かめておく：手元にも残したい場合は、パネルからダウンロードしておくか「ユーザー領域への保存設定」をオンにします（同マニュアルより・STEP6）
• 全ドメインの PHP の版を定期的に見る：使っていない初期ドメインも含めて
• 使っていないサイト・プラグインを片付ける：同じサーバーアカウントにある古いサイトは、同じユーザー権限で動くため、1つ乗っ取られると他のサイトのファイルも書き換えられる状態になります
• 点検を手順書・スクリプトにしておく：今回の6段階を、次はすぐ回せるように

WordPress のセキュリティでは、ログイン ID が外から見えてしまう問題も見落とされがちです。こちらも一度点検しておくと安心です。

アルケイズム

【WordPressセキュリティ】ユーザー名（ID）の漏えいを防ぐ！「?author=1」と「wp-json」の2大抜け穴をブロックする方法

WordPressのログインIDが外部から丸見えになる「?author=1」と「wp-json/wp/v2/users」…

WordPress の XML-RPC と REST API は無効化すべきかも、別の記事にまとめています。

まとめ

• 今回の PHP 脆弱性「php2shell」は、PHP 本体の問題。 WordPress 側の対策では防げず、共用サーバーでは更新もサーバー会社の仕事
• 管理者の仕事は「確認・点検・整理」。 待つだけで終わらせない
• 侵入痕跡の点検は、パッチを待たずに1回、更新後にもう1回。 2回そろって「痕跡は無い」と言える根拠になる
• 改ざんは公式チェックサムで照合する。 自作テーマなど照合できないものは変更日時で見る
• 変更ファイルは1件残らず説明をつける。 一覧は件数で打ち切らない
• PHP の版はパネルで全ドメイン確認する。 使っていないドメインも含めて

サーバー会社が直してくれるのは、穴そのものです。その穴が開いていた間に侵入の痕跡が無いことを確かめ、クライアントに「大丈夫です」と言える根拠を持つのは、管理を請けている側の仕事だと思っています。保守を任せる側から見ても、こうした点検が保守に含まれているかは、確認しておく価値があります。

次の緊急事態が来る前に、手順だけでも用意しておくことをおすすめします。

複数の WordPress サイトの保守やセキュリティ点検を、点検と報告まで含めて任せたい方は、お問い合わせからどうぞ。他社で制作されたサイトの保守の引き継ぎも相談できます。相談だけでもかまいません。