PHP の脆弱性（php2shell）が公表されたとき、WordPress サイトで確認すべきこと
公開 有限会社カルフ 栗山
2026年10月21日、PHP の開発元が重大な脆弱性2件（CVE-2026-109618、CVE-2026-109619。通称 php2shell）を公表し、修正版を公開しました。ログインしていない第三者が細工した通信を送るだけで、サーバ上でプログラムを実行される可能性があるというものです。
WordPress は PHP で動いているため、WordPress のサイトはほぼすべてが確認の対象になります。この記事では、WordPress サイトを管理している方に向けて、確認と対応の順番を整理しました。
内容は2026年10月26日時点の情報です。最新の状況は、末尾に挙げた公式の発表でご確認ください。
1. 何が起きたのか
- 深刻度は2件とも CVSS v4.0 で 9.2（最大 10.0）と、非常に高い評価です。
- 攻撃コードがすでに公開されており、JPCERT/CC には攻撃の試みも報告されています。
- 攻撃が成功するかどうかは、PHP のバージョンや動作環境によって変わります。開発元は、Apache の mod_php で PHP を動かしている環境が最もリスクが高いとしています。
- 10月23日には関連する CVE-2026-115560 も公表されましたが、こちらは特定の設定とプログラムの組み合わせでのみ影響するものです。
影響を受けるバージョンと修正版
| 系列 | 影響を受けるバージョン | 修正版 |
|---|---|---|
| 8.5 | 8.5.12 より前 | 8.5.12 |
| 8.4 | 8.4.27 より前 | 8.4.27 |
| 8.3 | 8.3.36 より前 | 8.3.36 |
| 8.2 | 8.2.35 より前 | 8.2.35 |
| 8.1 以前 | すべて | 公式の修正版なし（サポート終了）※ |
PHP 8.1 以前はサポートが終了しているため、開発元からの修正版は出ていません。7.4・8.0・8.1 向けには、開発元から最小限の修正がソースコードの形で公開されていますが、通常のサーバでそのまま使えるものではありません。また、PHP 8.2 も2026年12月31日でサポートが終了します。
※ 公式ではありませんが、Linux ディストリビューションやサーバー会社が独自に修正を提供している場合があります。たとえば Ubuntu 22.04 の PHP 8.1 には、Canonical が修正済みのパッケージ（8.1.2-1ubuntu2.28）を通常のアップデートで提供しています。このような修正では PHP のバージョン番号は変わりません。
2. PHP のバージョンを確認する
WordPress の管理画面で確認する
管理画面の「ツール」→「サイトヘルス」→「情報」タブを開き、「サーバー」の項目にある PHP のバージョンを確認します。
レンタルサーバーの場合
レンタルサーバーでは、PHP 本体の修正はサーバー会社が行います。ただし、会社によって対応の仕方が分かれています。
- サーバー会社が修正を強制的に適用する：利用者の作業は基本的に不要です。
- 修正済みのバージョンは用意されるが、切り替えは利用者が行う：管理画面で修正済みのバージョンを選び直さない限り、古いバージョンのまま動き続けている可能性があります。
まずはサーバー会社のお知らせで、どちらの対応なのか、自分のサイトで何をすればよいのかを確認してください。サーバー会社が独自に修正した場合はバージョン番号が変わらないことがあるため、番号だけでは判断できません。また、管理画面で PHP のバージョンを選べる場合は、古い系列（8.1 以前）を選んだままになっていないかも確認します。
自社で管理しているサーバ（VPS・クラウド）の場合
php -v でバージョンを確認できます。ただし、Linux ディストリビューションが提供するパッケージは、バージョン番号が上の表と違っていても修正が取り込まれている（バックポートされている）ことがあります。その場合は、ディストリビューションのセキュリティ情報で、修正済みのパッケージかどうかを確認してください。
3. 更新するときの注意
- 先にバックアップを取る：ファイルとデータベースの両方です。
- 系列をまたぐ更新は事前に試す：7.4 から 8.x へのように系列を上げると、テーマやプラグインが動かなくなることがあります。できればテスト環境で先に試してください。同じ系列の中での更新（8.2.x から 8.2.35 など）であれば、互換性の問題はほとんど起きません。
- 更新後に PHP を再起動する：PHP-FPM や Apache の古いプロセスが残っていると、修正が反映されません。
- WordPress 本体・テーマ・プラグインも最新にする：今回の脆弱性とは別に、古いプラグインは攻撃の入口になりやすいためです。
4. あわせて行いたいこと
更新とあわせて、次のこともできる範囲で行います。
- WAF を有効にする：レンタルサーバーの WAF 機能や Cloudflare などです。今回の攻撃に対応したルールが入っているかは、提供元に確認してください。WAF は更新の代わりにはなりません。
- 使っていない WordPress を止める：テスト用に作ったまま放置しているサイトや、移転前の古いサイトも同じように狙われます。
5. すでに被害を受けていないか確認する
JPCERT/CC は、侵害の痕跡として次の点を挙げています。
- 過去のレスポンスで、異常に長い、または形式のおかしい
PHPSESSIDの Cookie が設定されていないか - 不審な
multipart/form-dataのリクエストがないか。特に、PHP のメモリ上限エラーや HTTP 500 エラーの前後にあるもの - PHP のプロセスが予期せず停止したり、頻繁に再起動したりしていないか
- 不審なプロセスの実行、想定外の外部への通信、見覚えのないファイルの作成がないか
WordPress のサイトでは、次の点もあわせて確認します。
- 見覚えのない管理者ユーザーが増えていないか
- 画像などを置く
wp-content/uploadsの中に、PHP ファイルが置かれていないか - 最近、身に覚えのない PHP ファイルの更新がないか
- ページに不審なリンクや、別のサイトへの転送が入っていないか
これらが見つからなくても、攻撃されていないとは言い切れません。被害が疑われる場合は、まずログと現状を保全し、影響範囲を調べたうえで、サーバをネットワークから切り離します。慌ててファイルを消したりサーバを作り直したりすると、原因や影響範囲が分からなくなります。侵害の可能性がある場合は、WordPress やデータベースのパスワード、wp-config.php の認証用キー、外部サービスの API キーなども変更してください。
6. お問い合わせフォームで個人情報を扱っている場合
- 受信内容がデータベースに保存されていないか確認する：フォームのプラグインによっては、送信内容を WordPress のデータベースに保存しています。保存されていれば、サーバが侵害されたときに流出する対象になります。
- 不要な過去のデータは削除する：保存しておく必要がなければ、保存しない設定にします。
- 侵害の可能性があるときは報告義務を確認する：不正アクセスによって個人情報が漏えいしたおそれがある場合、個人情報保護委員会への報告や本人への通知が必要になることがあります。
7. 根本的な対策の選択肢
今回の件は更新すれば落ち着きますが、PHP やプラグインの脆弱性は今後も見つかります。そのたびに慌てなくて済むように、構成から見直すという選択肢があります。
公開サイトから PHP をなくす
WordPress で編集したページを静的な HTML として書き出し、公開サーバには HTML だけを置く方法です。お知らせやブログが中心のサイトであれば、移行できる可能性があります。
ただし、公開フォルダから PHP のファイルをなくすだけでは不十分です。今回の脆弱性は、PHP のプログラムが動き始める前の、送られてきたデータを受け取る段階で起きます。そのため、PHP のファイルが1つもなくても、Web サーバが PHP にリクエストを渡す設定のままであれば、設定によっては攻撃が PHP まで届く可能性があります。また、編集用の WordPress を同じサーバで動かしていれば、そのサーバでは PHP が動いています。
静的化の効果を得るには、公開サーバでは PHP を動かさない（インストールしない、または Web サーバから PHP に渡さない）こと、そして編集用の WordPress は別の場所に置き、外部から接続できないようにすることが必要です。
PHP を残すなら、被害を広げない構成にする
会員機能や EC など、PHP をなくせないサイトもあります。その場合は、Cloudflare などで入口を前に出し、管理画面やデータベースを外から見えない場所に分けることで、脆弱性が見つかったときの被害を小さくできます。
管理している人がいない場合
「制作会社と連絡が取れず、サーバの中身が分からない」という場合も、現状の調査からお手伝いできます。