【2026年】PHP2Shellとは?WordPressへの影響とエックスサーバーの対策・更新手順

はじめに

2026年10月、PHPに重大な脆弱性「PHP2Shell」が発見されました。

今回の脆弱性は、条件が揃うと外部からサーバー上で任意のコードを実行される可能性があるというものです。

WordPressはPHPで動作するCMSのため、WordPressサイトを運営している方にとっても無関係ではありません。

特に注意したいのが、PHP 7.4などの古いバージョンを利用しているケースです。

私自身もWordPressサイトのPHPバージョンを確認したところ、PHP 7.4.33を利用していました。

ただし、利用しているレンタルサーバーのエックスサーバーでは、今回の脆弱性への修正パッチがすでに適用されていることが分かりました。

この記事では、以下の内容を解説します。

  • PHP2Shellとは何か
  • 2つの脆弱性の仕組みと具体例
  • PHP 7.4.33でも影響を受けるのか
  • WordPressサイトへの影響
  • エックスサーバーの対応状況
  • PHP 7.4からPHP 8.4へ安全に更新する手順

実際にサイトを運営している方が、自分の環境を確認できるようにまとめました。

※本記事は2026年10月25日時点の公開情報をもとにしています。

PHP2Shellとは?2026年10月に公表された重大な脆弱性

PHP2Shellとは、2026年10月に公表されたPHPの2つの脆弱性を組み合わせた攻撃手法の名称です。

IPA(情報処理推進機構)も2026年10月22日に注意喚起を公開しています。

対象となる脆弱性は以下の2件です。

CVE番号脆弱性の概要
CVE-2026-109618メモリ不足時のエラー処理に関する不備
CVE-2026-109619リクエスト間で不正な内部状態が残る問題

どちらもPHPの内部処理に関係する脆弱性です。

重要なのは、WordPressのプラグインやテーマに直接問題があるのではなく、PHPの実行環境自体に問題があるという点です。

つまり、WordPress以外のPHP製Webアプリケーションでも、条件によって影響を受ける可能性があります。

RCE(リモートコード実行)とは?

RCEはRemote Code Executionの略称です。

攻撃者がネットワーク経由で、対象サーバー上で任意のコードを実行できてしまう問題を指します。

例えば、サーバー上で不正なプログラムが実行された場合、実行権限や環境によっては次のような被害につながる可能性があります。

  • Webサイトの改ざん
  • データベース内の情報流出
  • サーバー内部のファイルへの不正アクセス
  • 不正プログラムの設置

RCEが成立するかどうかは、PHPの実行方式や環境、攻撃者が操作できる入力などによって変わります。

脆弱なPHPを利用しているだけで、必ず攻撃が成功するという意味ではありません。

① CVE-2026-109618:メモリ不足時の処理に問題

まずは1つ目の脆弱性です。

どんな脆弱性?

PHPでは、メモリを確保しながらプログラムを実行しています。

画像処理や大きなデータの読み込みなどによって、プログラムが使用可能なメモリを超えてしまうことがあります。

一般的に、こうした状態はOOM(Out Of Memory)と呼ばれます。

今回の脆弱性では、このメモリ不足時のエラー処理に問題がありました。

PHPの内部データが完全に初期化される前に処理が中断されると、その後のクリーンアップ処理で不正な状態のデータが正常なものとして扱われる可能性があります。

結果として、メモリ破損が発生し、条件が揃えば任意のコード実行につながります。

具体例:WordPressで画像をアップロードする場合

例えば、WordPressで容量の大きい画像をアップロードするケースを考えます。

ユーザー
   ↓
WordPressへ画像をアップロード
   ↓
PHPで画像処理
   ↓
大量のメモリを消費
   ↓
メモリ不足が発生
   ↓
PHPのエラー処理

本来はメモリ不足によって画像処理が失敗しても、安全に処理を終了する必要があります。

しかし、脆弱性がある場合は、エラー処理の途中で内部データの整合性が崩れる可能性があります。

正常な処理

メモリ不足
   ↓
エラーを検出
   ↓
安全に後処理
   ↓
処理終了
脆弱性がある場合

メモリ不足
   ↓
内部データが不完全な状態になる
   ↓
後処理で不正なデータを参照
   ↓
メモリ破損
   ↓
任意のコード実行につながる可能性

※この例は問題を理解するための概念図です。画像アップロードだけで攻撃が成立するという意味ではありません。

普段はあまり意識しないPHP内部のメモリ管理が、セキュリティに直結するという点が興味深い問題です。

② CVE-2026-109619:別リクエストへ内部状態が引き継がれる問題

続いて2つ目の脆弱性です。

どんな脆弱性?

PHPはWebサーバーと組み合わせて、複数のHTTPリクエストを処理します。

一般的なPHP-FPM構成では、PHPのワーカープロセスが複数のリクエストを順番に処理する場合があります。

本来、各リクエストで使用する内部データは、リクエスト間で適切に初期化・破棄されなければなりません。

しかし、今回の脆弱性では、解放されたメモリに関連する古い内部状態が、後続のリクエストに残る場合がありました。

これにより、不正なメモリ状態が再利用され、任意のコード実行につながる可能性があります。

具体例:PHPのリクエスト処理

例えば、以下のようにリクエストを処理するWebアプリケーションを考えます。

HTTPリクエストA
      ↓
PHPワーカープロセス
      ↓
リクエストAの処理
      ↓
内部状態を初期化
      ↓
HTTPリクエストB
      ↓
リクエストBの処理

これが正常な処理です。

しかし、エラーなどによって内部状態が適切に初期化されなかった場合、次のような問題が考えられます。

HTTPリクエストA
      ↓
PHPワーカープロセス
      ↓
異常処理
      ↓
古い内部状態が残る
      ↓
HTTPリクエストB
      ↓
古い内部状態を誤って使用
      ↓
メモリ破損の可能性

ここで重要なのは、開発者が書いたPHPコードの変数管理だけの問題ではないという点です。

PHPエンジン内部の状態管理に問題があります。

PHP2Shellは、こうした内部処理の不備を悪用するものです。

③ PHP 7.4.33は影響を受ける?

結論からいうと、PHP 7.4.33は今回の脆弱性の影響を受ける可能性があるバージョンです。

IPAの注意喚起によれば、調査に関与したWiz社は、PHP 5.4以降のバージョンが少なくとも一方の脆弱性の影響を受けると説明しています。

さらに問題なのは、PHP 7.4がすでにサポート終了済みであることです。

PHP 7.4は2022年にサポート終了

PHP 7.4の公式サポートは、2022年11月28日に終了しています。

つまり、PHPプロジェクトから新たなセキュリティアップデートが通常提供されることはありません。

2026年10月に公表されたPHP2Shellについても、PHP 7.4向けの公式修正版は公開されていません。

ただし、レンタルサーバー事業者などが独自に修正パッチを適用している場合があります。

PHP2Shellの修正版

2026年10月22日に公開された修正版は以下のとおりです。

PHP系列修正版
PHP 8.28.2.35
PHP 8.38.3.36
PHP 8.48.4.27
PHP 8.58.5.12

PHP 8.1以前は、PHPプロジェクトによる公式サポートが終了しています。

そのため、古いバージョンを利用している場合は、利用中のサーバー事業者による修正の有無を確認する必要があります。

④ エックスサーバーはPHP2Shellへの対策を実施済み

今回、非常に重要な情報があります。

エックスサーバーは、PHP2Shellに関するセキュリティ対策を2026年10月22日に実施しました。

公式のお知らせでは、対象サーバーへの修正パッチ適用が次のスケジュールで完了したと発表しています。

完了日時対象PHP
2026年10月22日 6:45PHP 8.2~8.5
2026年10月22日 12:00PHP 7.4~8.1
2026年10月22日 14:00PHP 5.6~7.3

つまり、エックスサーバーでPHP 7.4.33を利用している場合も、今回の脆弱性に対する修正パッチは適用済みと発表されています。

これは利用者にとって安心できる情報です。

ただし、ここで勘違いしてはいけないことがあります。

パッチ適用済み=古いPHPを使い続けてよい、ではない

今回の脆弱性に対策されていても、PHP 7.4の公式サポートが復活したわけではありません。

今後発見される脆弱性についても、エックスサーバーが必ず修正パッチを提供するとは限りません。

そのため、長期的にはサポート対象のPHPへ移行することが望ましいと考えます。

なお、サーバー事業者が内部的にパッチを適用している場合、WordPressに表示されるPHPバージョン番号が7.4.33のままでも、修正が適用されているケースがあります。

PHPのバージョン番号だけでは、事業者独自のパッチ適用状況を判断できない点にも注意が必要です。

⑤ WordPressのPHPバージョンを確認する方法

ここからは実際の確認手順を説明します。

WordPressでは、管理画面からPHPのバージョンを確認できます。

確認手順

  1. WordPress管理画面にログイン
  2. 「ツール」をクリック
  3. 「サイトヘルス」をクリック
  4. 「情報」タブを開く
  5. 「サーバー」を開く

「PHP バージョン」という項目に現在のバージョンが表示されます。

例えば、次のような表示です。

PHP バージョン:7.4.33

この場合、PHP 7.4系を利用しています。

PHP 7.4は公式サポートが終了しているため、更新を検討しましょう。

⑥ PHP 7.4からPHP 8.4へ更新するべき?

WordPress公式では、PHP 8.3以上の利用を推奨しています。

2026年10月時点で、PHP 8.4は公式のアクティブサポート期間中です。

また、エックスサーバーではPHP 8.5も利用可能で、同サービスのマニュアルではWordPressの推奨バージョンとして案内されています。

ただし、古いPHPから移行する場合は、テーマやプラグインとの互換性も考慮する必要があります。

そのため、今回はPHP 8.4系を移行先の第一候補として考えます。

PHP 8.4であっても、利用しているWordPressやプラグインに対応していなければ、正常に動作しない可能性があります。

重要なのは、バージョンの新しさだけでなく、互換性を確認して更新することです。

⑦ エックスサーバーでPHP 7.4から8.4へ変更する手順

エックスサーバーでは、サーバーパネルからPHPバージョンを変更できます。

ただし、変更前のバックアップと動作確認が非常に重要です。

STEP1:バックアップを取得する

まずはWordPressのバックアップを取得します。

WordPressでは、主に以下の2種類のデータを管理しています。

対象主なデータ
WebファイルWordPress本体・テーマ・プラグイン・画像
MySQL記事・コメント・各種設定など

つまり、ファイルだけをバックアップしても、記事や設定を完全に復元できるとは限りません。

必ず両方を保存しましょう。

エックスサーバーには自動バックアップ機能があり、通常は過去14日分のデータが保持されています。一部の旧サーバーでは7日間の場合があります。

サーバーパネルからバックアップの取得・復元に関するメニューを確認できます。

変更直前に手元へバックアップをダウンロードしておけば、より安心です。

参考:エックスサーバー:自動バックアップからのデータ取得

STEP2:WordPressとプラグインの互換性を確認する

次に、WordPress本体とプラグインのバージョンを確認します。

確認したいポイントは以下のとおりです。

  • WordPress本体が更新可能か
  • 現在のテーマがPHP 8.4に対応しているか
  • プラグインがPHP 8.4に対応しているか
  • 長期間更新されていないプラグインがないか
  • テーマに独自のPHPコードを追加していないか

PHP 7.4から8.4への変更では、PHP側の仕様変更によって古いコードが動作しなくなる可能性があります。

例えば、以前のPHPでは動作していた処理が、PHP 8系ではエラーになるケースです。

特に、独自カスタマイズしたテーマや古いプラグインには注意が必要です。

可能であれば検証用のWordPressサイトを用意して、先にPHP 8.4での動作を確認しましょう。

エックスサーバーには「WordPressサイトコピー」機能もあります。ただし、PHPバージョンの切り替えはドメイン単位のため、同じドメイン内のサブディレクトリへコピーするだけではPHPの設定を分離できません。

参考:エックスサーバー:WordPressサイトコピー

STEP3:サーバーパネルでPHPを変更する

バックアップと互換性の確認が完了したら、PHPバージョンを変更します。

手順は以下のとおりです。

  1. エックスサーバーのサーバーパネルへログイン
  2. 「PHP Ver.切替」をクリック
  3. 変更したいドメインを選択
  4. 「変更後のバージョン」でPHP 8.4系を選択
  5. 「設定する」をクリック

旧サーバーパネルでは、最後の操作が「変更」と表示される場合があります。

これでPHPのバージョンを切り替えられます。

実際の画面操作はエックスサーバー公式マニュアルでも確認できます。

参考:エックスサーバー:PHPのバージョン切り替え方法

STEP4:変更後の動作を確認する

PHPを変更したら、サイトが正常に動作しているか確認します。

特に次の機能をチェックしましょう。

確認対象チェックする内容
トップページ正常に表示されるか
記事ページ本文や画像が表示されるか
管理画面正常にログインできるか
記事投稿ブロックエディターが動くか
画像アップロード画像を追加できるか
プラグイン主な機能が正常に動くか
フォーム問い合わせ送信ができるか

ブラウザの表示確認だけでなく、投稿画面など管理機能の確認も重要です。

WordPressでブログを運営している場合は、記事の新規作成・編集・公開まで確認しておくとよいでしょう。

STEP5:問題が発生した場合は元に戻す

もしPHP 8.4へ変更してサイトが表示されなくなった場合は、サーバーパネルからPHPを元の7.4へ戻すことができます。

PHPの変更だけが原因であれば、元のバージョンに戻すことで復旧する場合があります。

ただし、PHP 7.4への切り戻しは一時的な対応として考えます。

その後、エックスサーバーの「エラーログ」から原因を確認しましょう。

例えば、PHPのFatal errorが発生していれば、互換性のないプラグインやテーマを特定する手掛かりになります。

原因を修正できたら、再度PHP 8.4への移行を検討します。

なお、バックアップからデータを復元すると、その後に追加・更新したデータが失われる場合があります。

PHPバージョンを元に戻す操作と、バックアップから復元する操作は分けて考えることが重要です。

参考:エックスサーバー:エラーログの確認方法

⑧ PHP2Shellから学べること

今回のPHP2Shellは、PHPの内部メモリ管理に関する脆弱性です。

通常のWebアプリケーション開発では、入力値の検証やSQLインジェクション、XSSなどの対策を意識することが多いと思います。

しかし、どれだけアプリケーション側の実装に注意していても、実行環境そのものに脆弱性が存在する可能性があります。

例えば、JavaでWebアプリケーションを開発している場合も同様です。

Spring BootのControllerやServiceに問題がなくても、利用しているJDKやApache Tomcatなどに脆弱性があれば、影響を受ける場合があります。

今回のPHP2Shellから学べるのは、アプリケーションのコードだけでなく、ランタイムやミドルウェアを含めたセキュリティ管理が必要ということです。

また、エックスサーバーのように、提供事業者が独自に修正パッチを適用するケースもあります。

そのため、脆弱性の影響を判断する際には、単純なバージョン番号だけでなく、提供元のセキュリティ情報も確認する必要があります。

よくある質問

Q. PHP 7.4.33を使っているだけでサイトは危険?

PHP 7.4は公式サポートが終了しているため、セキュリティ上のリスクがあります。

ただし、今回のPHP2Shellについては、エックスサーバーがPHP 7.4系へのパッチ適用完了を公表しています。

古いバージョンだからといって、今回の脆弱性が必ず未修正とは限りません。

Q. WordPressを更新すればPHP2Shellも修正される?

いいえ。

PHP2ShellはPHPの実行環境に関する脆弱性です。

WordPress本体を更新するだけでは、PHPランタイム自体の問題は解消しません。

Q. PHP 7.4から8.4へ直接変更できる?

エックスサーバーでは、管理画面からPHP 8.4系へ切り替えることができます。

ただし、WordPress本体・テーマ・プラグインの互換性確認が必要です。

Q. PHPバージョンを変更したら記事は消える?

PHPのバージョンを変更する操作自体は、通常、記事データを削除するものではありません。

ただし、動作不良に備えて、事前にMySQLとWebファイルのバックアップを取得してください。

まとめ

2026年10月に公表されたPHP2Shellは、PHP内部のメモリ管理に関する2件の脆弱性です。

条件が揃うと、外部から任意のコードを実行される可能性があるため、注意が必要です。

今回のポイントをまとめます。

  • PHP2ShellはCVE-2026-109618とCVE-2026-109619の組み合わせ
  • PHP 7.4.33も影響を受ける可能性がある
  • エックスサーバーでは2026年10月22日にPHP 7.4への修正パッチ適用が完了
  • PHP 7.4自体は2022年11月に公式サポートが終了
  • WordPressではPHP 8.3以上が推奨されている
  • PHPの更新時は、バックアップと互換性確認が重要

今回の件をきっかけに、自分が運営しているWordPressサイトのPHPバージョンを確認してみるのもよいと思います。

サーバー側で脆弱性対策が行われていても、古いPHPを使い続けるリスクがなくなるわけではありません。

長期的なサイト運営を考えて、サポート対象のバージョンへの移行を進めていきましょう。

参考情報

是非フォローしてください

最新の情報をお伝えします

類似投稿