PHPは10月21日、リモートコード実行につながる重大な脆弱性2件を修正しました。確認できている事実、本当にリスクがあるのは誰か、そして落ち着いて実行できるチェックリストをまとめます。
php.netとphp-srcのアドバイザリーで2026年10月22日に確認済み。
2026年10月21日、PHPプロジェクトは、特定の条件下で認証なしの攻撃者がサーバー上でコードを実行できる重大な脆弱性2件（CVE-2026-109618、CVE-2026-109619）を公表しました。どちらもCVSS 9.2です。修正版はPHP 8.5.12、8.4.27、8.3.36、8.2.35です。
サイトがPHPで動いている場合（WordPressを含む）は、ホスティング会社にPHPのバージョンと更新状況を確認してください。HTMLだけの静的サイトであれば、攻撃対象となるPHPはそもそも動いていません。
| 日付 | 出来事 |
|---|---|
| 2026年9月24日 | 先行するセキュリティリリース：PHP 8.5.11、8.4.26、8.3.35、8.2.34 |
| 2026年10月20日 | PHPプロジェクトが重大なセキュリティリリースを事前告知 |
| 2026年10月21日 | PHP 8.5.12、8.4.27、8.3.36、8.2.35をリリース。2件のアドバイザリーを公開 |
| 2026年10月21日 | PHP 8.6.0 RC4に修正を含む（リリース候補版のため本番環境には不向き） |
| 2026年12月31日 | PHP 8.2がサポート終了（EOL） |
| CVE-2026-109618 | CVE-2026-109619 | |
|---|---|---|
| 種類 | メモリ不足（OOM）による破損を利用したRCE | 古いグローバル状態を利用したRCE |
| 深刻度 | CVSS v4.0 9.2（Critical） | CVSS v4.0 9.2（Critical） |
| 影響範囲 | 8.2.35、8.3.36、8.4.27、8.5.12より前 | |
| 攻撃の難易度 | 高 | 高 |
| 認証 | 不要 | 不要 |
アドバイザリーは構成ごとに状況を具体的に分けており、リスクはどこでも同じではありません。
session.upload_progress.enabled（デフォルトで有効）と、PHP 8.5ではfatal_error_backtracesです。どちらも攻撃の難易度は高いと評価されています。致命的エラーが特定のタイミングで起きること、リクエストが同じワーカーに届くことなど、複数の条件を揃える必要があります。ワンクリックで悪用できる脆弱性より日常のリスクは低いものの、更新が不要になるわけではありません。
アドバイザリーは、更新が唯一の完全な対策だと明記しています。以下はリスクを下げるものであって、安全を保証するものではありません。いずれもワーカーの再起動が必要です。
memory_limit=-1を、アプリケーションから変更できない形で設定する（FPMやApacheの設定のphp_admin_valueなど）。post_max_sizeを、アップロード不要なら8M、必要なら32Mにし、upload_max_filesizeはそれより小さくする。php.iniまたはサーバー設定でsession.upload_progress.enabled=0にする。ini_set()や.user.iniでは不十分です。fatal_error_backtraces=0にする。サーバーを管理しているのが自分でない場合は、このリストを担当者に送ってください。
この部分はアドバイザリーの記述ではなく、私たちの推測です。WordPressと、ほとんどのプラグインやテーマはPHPで動いているため、サーバーのPHPのバージョンによって影響の有無が決まります。WordPress本体やプラグインを更新しても、サーバーのPHPは変わりません。マネージドなWordPressホスティングでは通常、事業者がPHPを管理します。自己管理のVPSや古い共用プランでは、自分か事業者が対応する必要があります。
HTML・CSS・画像だけで作られたWebサイトには、攻撃対象となるPHPが動いていないため、サイト自体にはこの種の問題は当てはまりません。これは静的サイトの実際の特性ですが、安全を保証するものではありません。サーバー本体、同じサーバー上の他のアプリケーション、問い合わせフォームの扱いは引き続き重要です。
開示：XAIWebsitesはXAIAgentと同じチームが運営しています（詳細）。XAIWebsitesが生成するサイトにはPHPファイルは含まれていません。ここで触れるのは関連があるからであり、ご自身の環境の確認の代わりになるわけではありません。サイトに不安がある場合は、無料のウェブサイト診断が手軽な最初の一歩です（診断ページは英語です）。
運用しているものにPHPが使われているなら、今日のうちにバージョンを調べ、8.2.35、8.3.36、8.4.27、8.5.12以降にしてください。マネージドなホスティングなら、多くの場合は問い合わせ1通で済みます。
リスクは現実のものですが条件付きで、悪用されているかどうかは分かっていません。それでも更新してください。それが唯一の完全な対策です。
PHPプロジェクトは、CVE-2026-109618（メモリ不足による破損を利用したリモートコード実行）とCVE-2026-109619（古いグローバル状態を利用したリモートコード実行）という2件の重大な脆弱性を公表しました。どちらもCVSS v4.0で9.2と評価され、特定の条件下で、認証なしの攻撃者がWebサーバーの権限でコードを実行できる可能性があります。
8.2〜8.5系では、8.2.35、8.3.36、8.4.27、8.5.12より前のバージョンが影響を受けます。修正版は8.2.35、8.3.36、8.4.27、8.5.12です。PHP 8.1以前は公式の更新が提供されないため、ベンダーのバックポートまたはアップグレードが必要です。PHP 8.2は2026年12月31日にサポート終了（EOL）を迎えます。
WordPressはPHPで動いているため、重要なのはサーバーのPHPのバージョンです。WordPress本体を更新しても、サーバーのPHPは変わりません。公表された情報ではWordPressは名指しされていません。影響の有無は、ホスティング会社のPHPのバージョンと構成によります。マネージドなホスティングでは通常、事業者がPHPを更新しますが、思い込みではなく確認してください。
私たちが確認したアドバイザリーには、悪用の有無は書かれておらず、確認された報告も見ていません。「不明」であることを「安全」と受け取らないでください。どちらの脆弱性も攻撃の難易度は高いと評価されていますが、Apacheのmod_phpでは完全なリモートコード実行が実証されたと記載されています。
HTML・CSS・画像だけで構成された静的サイトには、攻撃対象となるPHPが動いていないため、サイト自体に更新すべきこの種のPHPはありません。ただし、サーバー本体、同じサーバー上の他のアプリケーション、問い合わせフォームの処理は別の問題です。XAIWebsitesが生成するサイトにはPHPファイルは含まれていません。
アドバイザリーでは、更新が唯一の完全な対策とされており、リスクを下げる（ただし解消はしない）設定が挙げられています。アプリケーションから変更できない形でmemory_limitを-1にする、post_max_sizeを小さく保つ（アップロード不要なら8M、必要なら32M）、php.iniでsession.upload_progress.enabledを無効にして全ワーカーを再起動する、PHP 8.5ではfatal_error_backtracesを0にする、などです。ホスティング会社に依頼し、できるだけ早く更新してください。
ホスティング会社に問い合わせるか、管理画面のPHP設定（PHPバージョン）で確認できます。WordPressでは、「ツール」→「サイトヘルス」→「情報」→「サーバー」にも表示されます。
このページの事実は、PHPプロジェクト自身のページから2026年10月22日に確認したものです。行動する前にもう一度確認してください。アドバイザリーは更新されることがあります。
2026年10月22日公開。PHPプロジェクトは2026年10月21日に修正とアドバイザリーを公開しました。アドバイザリーは更新されることがあるため、行動する前にphp.netを確認してください。