PHPの重大な脆弱性：WordPressサイト所有者が知っておくべきこと

English version: Critical PHP Vulnerabilities: What WordPress Site Owners Need to Know

PHPは2026年10月21日に、2つの重大な脆弱性に対する修正プログラムをリリースしました。WordPressやプラグインをアップデートしても、これらの脆弱性は修正されません。ホスティング環境が影響を受けているかどうかを確認する方法と、対処方法についてはこちらをご覧ください。

要約すると、何が起こったのか

2026年10月21日、PHPプロジェクトは、PHPランタイムにおける2つの重大な脆弱性、CVE-2026-109618とCVE-2026-109619（いずれもCVSS v4.0で9.2と評価）に対する修正プログラムをリリースしました。これらの脆弱性により、特定の条件下では、認証されていない攻撃者がWebサーバー上でコードを実行できてしまいます。これらの脆弱性はPHP自体に存在するものであり、WordPressのコア、テーマ、プラグインに存在するものではないため、修正プログラムはサーバーにインストールされたパッチ適用済みのPHPビルドから提供される必要があります。

推奨される対策：ホスティングプロバイダーに、サイトで提供されているPHPビルドが両方の脆弱性に対するパッチを適用済みであることを確認してもらうよう依頼してください。サーバーを自分で管理している場合は、パッチ適用済みのPHPパッケージをインストールし、PHPを再起動してください。

PHPプロジェクトの勧告では、これらの脆弱性は「メモリ不足によるリモートコード実行（CVE-2026-109618）」と「古いグローバル状態によるリモートコード実行（CVE-2026-109619）」と名付けられています。どちらの場合も、不適切なタイミングでリクエストが失敗すると、PHPが後で利用する内部データが無効な状態のまま残ってしまう可能性があります。

攻撃が成功すると、PHPが実行されているアカウントの権限でコードが実行されます。サーバーの設定によっては、攻撃者はwp-config.phpとそこに含まれるデータベース認証情報を読み取ったり、データベースにアクセスしたり変更したり、サイトのファイルやコンテンツを変更したりすることが可能になります。ただし、PHPワーカーが侵害されたからといって、攻撃者に自動的にサーバーへのルートアクセス権が与えられるわけではありません。

利用状況（2026年10月21日現在）

PHP Foundationは、セキュリティチームがリリース前に公開された概念実証（PoC）コードの中に機能的なエクスプロイトを発見していないものの、PoCの開発が加速していると述べた。10月21日、脆弱性を「php2shell」と呼ぶCloudflareは、顧客を標的とした攻撃トラフィックを観測しており、攻撃者がペイロードを変更して保護を回避しようとしていると報告した。どちらの情報源も、侵害が成功したという確証は得ていない。攻撃トラフィックは攻撃者が積極的に試みていることを示しているが、それ自体ではサイトが侵害されたことを確証するものではない。状況が進展するにつれて、このセクションを更新していく。

影響を受ける可能性のある人は誰ですか？

パッチが適用されていないPHPビルドで運用されているウェブサイトは、WordPress、テーマ、プラグインのバージョンに関係なく、影響を受ける可能性があります。PHPプロジェクトの勧告は、PHP-FPM、mod_phpを使用したApache、php-cgi、FrankenPHP、LiteSpeedなど、ウェブ要求を処理するすべてのPHPインストールを対象としています。

PHPプロジェクトは、mod_phpにおけるリスクが最も高いと考えています。mod_phpでは、認証されていないリクエストがアプリケーションコードの実行前にトリガーされる脆弱性が確認されています。これは、他の構成が安全であることを意味するものではありません。Webリクエストを処理するすべてのPHPインストール環境で、この修正が必要です。

PHPのバージョンとパッチ適用状況を確認する方法

WordPressダッシュボードで、 「ツール」→「サイトヘルス」→「情報」に進み、 「サーバー」セクションを展開します。ここには、サイトをホストしているPHPバージョンとPHP SAPI（サーバーAPI）が表示されます。ほとんどのホスティングコントロールパネルでも同じ情報が表示されます。WP Cerberを使用している場合は、WP Cerber → 「ツール」→「診断」にもPHPバージョンとサーバーAPIが表示されます。

PHPプロジェクトの以下のアップストリームリリースには、これらの修正が含まれています。

PHPブランチ	上流の固定リリース
8.5	2012年8月5日
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35
8.1、8.0	上流リリースはありません。パッチ適用済みのビルドまたはアップグレードについては、ベンダーにお問い合わせください。
7.4	アップストリームリリースはありません。パッチ適用済みのベンダービルドが存在します。例えば、Ubuntu Pro (7.4.3-4ubuntu2.29+esm5) を搭載した Ubuntu 20.04 LTS や、既に Remi リポジトリを使用しているシステムでは Remi 7.4.33-31 (RHEL 8、9、10 および互換) などです。ベンダーに確認するか、アップグレードしてください。

重要: これらはアップストリームバージョンであり、普遍的な最小バージョンテストではありません。Linuxディストリビューションおよび商用長期サポート (LTS) ベンダーは、サポートされている 8.2、8.3、および 8.4 ブランチのビルドを含め、以前のバージョン番号を保持するビルドに修正をバックポートできます。たとえば、Ubuntu 24.04 LTS は PHP 8.3 パッケージを 8.3.6 ベースのバージョン文字列で管理し、パッケージバージョン 8.3.6-0ubuntu0.24.04.13 で両方の修正を出荷しています。サイトヘルスだけでは、ベンダーのビルドに両方の修正が含まれているかどうかを判断できません。ベンダーのセキュリティアドバイザリまたはパッケージの変更ログを確認するか、ホストに問い合わせてください。バージョン番号がアップストリームの修正済みリリースよりも低いという理由だけで、サードパーティの PHP パッケージリポジトリに切り替えないでください。

PHP 7.4、8.0、8.1。PHPプロジェクトのソースバックポートに基づいたこれらのブランチのパッチ適用済みビルドは、両方の脆弱性に対処し、サポート終了バージョンに対しては最小限の緩和策を提供します。これは、8.2 以降に提供される完全な修正よりも範囲が狭くなっています。この緩和策により、メモリ不足になった PHP プロセスは即座に終了するため、メモリ制限を超えたサイトでは、WordPress の重大なエラー画面ではなく、一般的なサーバーエラーが表示される場合があります。このようなビルドでは、サイトヘルスで更新前と更新後で同じバージョン番号が表示される可能性があるため、ホスティング会社またはパッケージの変更履歴で修正内容を確認してください。サポートされているブランチへのアップグレードが引き続き推奨されます。

PHP 8.2 のサポートは間もなく終了します。PHPプロジェクトによる PHP 8.2 のセキュリティサポートは 2026 年 12 月 31 日に終了します。PHP 7.4、8.0、または 8.1 からアップグレードする場合は、PHP 8.3 以降を選択し、事前にサイトのバックアップを作成してから、テーマとプラグインの互換性を確認してください。または、ホスティングプロバイダーに現在のブランチのパッチ適用済みビルドを依頼してください。

サーバーに修正を適用する必要がある理由

脆弱性のあるコードは、WordPress自体ではなく、WordPressを実行するPHPランタイムの一部です。

WordPressをアップデートしても、これらのPHPの脆弱性は解消されません。WordPressのコア、テーマ、プラグインをアップデートしても、PHPランタイムは変更されません。

セキュリティプラグインではランタイムを修正することはできません。一部の攻撃経路はWordPressの読み込み前に実行されるため、プラグインがリクエストを検査する機会がありません。ホスティングレベルまたはネットワークレベルのWebアプリケーションファイアウォール（WAF）ルールは特定の攻撃経路を減少させる可能性がありますが、パッチ適用に完全に代わるものではありません。

サイト内から設定を変更しても、確実な解決策にはなりません。PHPプロジェクトの勧告では、設定緩和策を適用するためにini_set()やFPMの.user.iniファイルに依存しないよう警告しており、 wp-config.phpやプラグインによって変更されたPHP設定についても同様です。勧告で説明されているサーバーレベルの対策でさえ、特定の攻撃経路への脆弱性を軽減するだけであり、インストール環境を完全に安全にするものではありません。

WP Cerberをご利用の方へ。WP CerberはWordPress内部で動作します。PHPのパッチ適用はできず、WordPressの起動前にこれらの脆弱性を引き起こすリクエストを検査することもできません。そのため、WP Cerberのログにはそのような試みが記録されない場合があり、疑わしいエントリがないログは、サイトが攻撃の標的になっていないことを証明するものではありません。WP CerberはアプリケーションレベルでWordPressを保護しますが、PHPのアップデートの代替となるものではありません。

今、何をすべきか

サーバーを管理していない場合

これは共有ホスティングとマネージドホスティングの両方に当てはまります。これらの場合、PHPランタイムの保守はプロバイダの責任となります。プロバイダに、ウェブサイトで使用されているPHPビルドに両方の脆弱性に対する修正が含まれていることを確認してもらってください。この質問はそのまま送信できます。

ウェブサイトで使用されている PHP ビルドは、CVE-2026-109618 および CVE-2026-109619 に対するパッチが適用されていますか？パッチ適用済みのビルドを読み込むために、関連する PHP ワーカーは再起動されていますか？

VPSまたは専用サーバーを管理している場合

PHPをアップデートしてください。パッチが適用された最新のリリース、またはアドバイザリや変更履歴で両方の修正が含まれていることが確認できるディストリビューションまたはベンダーのパッケージをインストールしてください。

PHPを再起動してください。PHP -FPM、Apache、またはサイトでPHPを実行しているその他のサービスを再起動または再読み込みしてください。実行中のワーカーは、再起動されるまで古いバイナリを使用し続けます。

検証してください。サイトヘルスで、各サイトで想定どおりのPHPビルドが使用されていることを確認してください。次に、ベンダーのアドバイザリまたはパッケージの変更履歴で、インストールされているパッケージに両方の修正が含まれていることを別途確認してください。サイトヘルスは実行中のバージョンを表示しますが、バックポートが含まれていることを証明することはできません。php php -vコマンドは、ウェブサイトで使用されているPHPとは異なるPHPインストールを報告する可能性があるため、このコマンドだけに頼らないでください。

どちらのケースに該当する場合でも、復元可能な最新のバックアップを必ず作成しておいてください。PHPのパッチ適用前にサイトが侵害された疑いがある場合は、PHPのアップデートではマルウェアやバックドアが削除されないことに注意してください。その場合は、まずホスティングプロバイダに連絡してください。PHP経由で取得したアクセスはWordPressファイルに限定されない可能性があるためです。WordPressのインストール自体をクリーンアップする方法については、「WordPressサイトがハッキングされた場合の対処法」ガイドを参照してください。

よくある質問

影響を受けているウェブサイトにアクセスした場合、私のコンピューターやブラウザは危険にさらされますか？

直接的なリスクはありません。脆弱性はウェブサーバー上のPHPにあり、訪問者のデバイスやブラウザにあるわけではありません。ただし、これらの脆弱性によって侵害されたサイトは、悪意のあるコンテンツを表示するように改変される可能性があるため、訪問者は間接的なリスクに直面する可能性があります。

WordPressを再インストールする必要がありますか？

いいえ、これらの脆弱性に対処するためではありません。サーバー上のPHPを更新することで修正できますし、WordPressを再インストールしてもPHPは変更されません。ただし、侵害されたサイトのクリーンアップの一環として再インストールが必要になる場合もあります。

ホスティングプロバイダーのサポートなしで、自分でこの問題を解決できますか？

それは、PHPランタイムを自分で制御できるかどうかによります。VPSや専用サーバーでは、パッチ適用済みのパッケージを自分でインストールできます。共有ホスティングやマネージドホスティングでは、ホストがPHPを制御します。多くのコントロールパネルでは、サイトを別のPHPバージョンに切り替えることができますが、そのビルドにパッチが適用されているかどうかは、やはりホストに依存します。