PHPプロジェクトは2026年10月21日、認証なしでリモートコード実行（RCE）につながりうる重大な脆弱性2件を修正したセキュリティリリースを公開しました。修正版はPHP 8.5.12・8.4.27・8.3.36・8.2.35です。WordPress自体の更新は不要ですが、WordPressはPHPで動くため、サイトを動かしているPHPのバージョンを確認して、更新する必要があります。
PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 で何が直ったか
php.net のセキュリティアドバイザリによると、修正された脆弱性は次の2件です。
| CVE | 種類 | アドバイザリの説明 |
|---|---|---|
| CVE-2026-109618 | OOM（メモリ不足）時のデータ破損によるRCE | メモリ不足の処理が、内部のリクエストデータの初期化が途中の状態でPHPを中断させることがあり、そのあとの後始末で不正なデータが有効なものとして扱われる |
| CVE-2026-109619 | 古いグローバル状態に起因するRCE | リクエスト固有の内部状態が、その状態が使っていたメモリが解放されたあとも残り、同じワーカーが処理する次のリクエストが、通常の初期化の前にその状態を使ってしまう |
対象は、Webリクエストを処理するすべてのPHP環境で、PHP-FPM、Apache の mod_php、php-cgi、FrankenPHP、LiteSpeed が挙げられています。PHPプロジェクトは、特に mod_php のリスクが高いとし、アプリケーションのコードが動く前に、認証なしのリクエストで攻撃を起こせる実証済みのエクスプロイトがある、と説明しています。
WordPressは更新不要、PHPの更新が必要
WordPress.org のニュース記事（10月21日付）によれば、これらの脆弱性はWordPress固有のものではなく、PHPアプリケーションを動かすすべてのサーバーに影響します。WordPressのアップデートは必要なく、予定もされていません。
つまり、WordPress本体・プラグイン・テーマを最新にしていても、土台のPHPが古ければ防げません。次の流れで確認します。
- 管理画面の「ツール > サイトヘルス > 情報 > サーバー」で、PHPのバージョンを確認します（ホスティングの管理画面で確認できる場合もあります）。
- 各系列の修正版（8.5.12・8.4.27・8.3.36・8.2.35）かそれ以降か、または事業者が修正済みのパッケージを提供しているか（ディストリビューションではバージョン番号が変わらないことがあります）を、レンタルサーバーやVPSの事業者の案内で確認します。
- なっていなければ、できるだけ早くPHPを更新します。事業者がWAF（Web Application Firewall）ルールの適用などを進めている場合もありますが、WAFは更新の代わりにはならないので、PHP本体の更新状況もあわせて確認します。
PHP 8.1以前は公式の修正版なし。バックポートか移行を
アドバイザリでは、PHP 8.1以前はPHPプロジェクトからの更新が出ていない、と書かれています。ただし、PHPのセキュリティチームは、重大性を考えて、PHP 7.4・8.0・8.1向けに最小限のソースのバックポートを公開しました。これは、ソースからビルドする人や、LTSベンダーを使えない人を助けるためのものです。ディストリビューションやLTSベンダーが、バックポートした修正を出している場合もあるので、使っている事業者に確認します。自分でサーバーを管理していて、更新の準備に時間がかかる場合は、準備が終わるまでサーバーを止めることも検討するよう、WordPress.orgの記事は勧めています（英国のNCSCも、即時の対処が難しいなら「システムをオフラインにすることを検討すべき」と述べています）。
PHPの公式サポート期間でも、8.1はすでにサポートが終わっています。8.2はセキュリティサポートが2026年12月31日までで、今回の8.2.35のアナウンスにも「その日以降はセキュリティ修正が出ない」と書かれています。8.2を使っている人は、今回の更新に加えて、8.3以降への移行計画も立てておくのがよいでしょう。
| バージョン | 初回リリース | セキュリティサポートの終了 |
|---|---|---|
| 8.2 | 2022年12月8日 | 2026年12月31日 |
| 8.3 | 2023年11月23日 | 2027年12月31日 |
| 8.4 | 2024年11月21日 | 2028年12月31日 |
| 8.5 | 2025年11月20日 | 2029年12月31日 |
すぐに更新できないときの暫定策は「完全な対策ではない」
アドバイザリには、すぐに更新できない場合の暫定策も載っています。ただし、PHPプロジェクト自身が「更新だけが完全な解決策」とし、各リリースのアナウンスでも「完全な緩和策はなく、更新だけが安全な選択」と書いています。暫定策は、特定の攻撃経路への露出を減らすだけで、環境を安全にするものではありません。主なものは次のとおりです。
- CVE-2026-109618向け: memory_limit を -1 にする。FPMプールやApacheの設定の php_admin_value のように、アプリ側で上書きできない形で行い、どこかの設定が有限の値に戻していないかも確認します。ただし、この設定でも、その下にある割り当て失敗が、脆弱な処理に届く可能性は残ります
- CVE-2026-109618向け: post_max_size を小さくする（ファイルアップロードが不要なら 8M、必要でも 32M）、upload_max_filesize を post_max_size より小さくする。Webサーバーやプロキシ側でも、デコード後のリクエストサイズ、入力フィールド数、マルチパートの数、ヘッダー数、ネストの深さを制限する（Content-Length のないリクエストも対象）
- CVE-2026-109618向け: コンテナやcgroupの上限を、可用性の境界として使う。RLIMIT_AS や RLIMIT_DATA での代用は、脆弱な割り当て失敗を起こしうるので避ける
- CVE-2026-109619向け: session.upload_progress.enabled を 0 にして、すべてのワーカーを再起動する。php.ini やFPMプール、サーバー設定など、リクエスト解析より前に効く場所で設定し、ini_set() や .user.ini には頼らない。確認済みの経路は塞げますが、ほかの変種は塞げません
- CVE-2026-109619向け: PHP 8.5 では fatal_error_backtraces を 0 にして、すべてのワーカーを再起動する（確認済みの経路のみ塞ぎます）。リクエストごとに適用される不正・非推奨の設定を取り除く。error_reporting や display_errors、@ で診断を隠しても効果はありません。攻撃者が起こせる致命的エラーやタイムアウトも直す
いずれも設定の影響範囲が大きいので、本番に入れる前に、ステージングで動作を確かめるのが安全です。
筆者の見方：PHPの層もWordPressの更新対象として扱う
ここからは筆者の見方です。WordPressの開発者や運用者は、普段、プラグインやテーマの脆弱性に注意を向けがちです。今回のように、下の層（PHP）で認証なしのRCEが見つかると、WordPress側をいくら更新していても、この種の脆弱性は防げません。更新のしやすさはサーバー環境によって変わるので、共用レンタルサーバーなのか、VPSなのか、マネージドホスティングなのかで、自分がどこまで対応する立場なのかも変わります。
また、PHPのバージョンを「動いているから」とずっと上げずにいると、今回のような緊急のリリースがあったときに、更新の選択肢が狭くなります。サポート期間の中のバージョンに、普段から載せておくことが、最も確実な備えの一つだと考えます。
参考にした公式情報
- WordPress.org News「Critical PHP Security Release」（2026年10月21日）
- php.net「Security advisory: Critical remote code execution vulnerabilities, update now」（2026年10月21日）
- php.net「PHP 8.2.35 Released!」（2026年10月21日）
- php.net「Supported Versions」
2026年10月24日時点の情報です。
コメント