AIとPCでどうにかする困ったことから、使える知識へ。このサイトについて ↗

Web・セキュリティ

【続報】PHPの重大脆弱性2件が正式公開｜認証不要RCE、対象・修正版・WordPressの対応まとめ

更新

2026年10月21日23時（日本時間）、PHP公式から事前予告されていた2件のCritical脆弱性の詳細と修正版が正式公開されました。

結論から言うと、2件は CVE-2026-109618 と CVE-2026-109619。どちらもCVSS v4.0で**9.2（Critical）と評価され、条件が成立すると認証なしでリモートコード実行（RCE）**につながります。PHP公式は、Webリクエストを処理するPHP環境について速やかな更新を呼びかけています。

この記事は、PHP公式、PHP公式GitHub Security Advisory、Cloudflare、IPAなどの公開情報をもとに、2026年10月21日23時台時点で確認できる内容を整理した続報です。

先に結論：修正版へ更新する

PHP公式が案内している修正版は次の4系統です。

系統 修正版
PHP 8.5 8.5.12
PHP 8.4 8.4.27
PHP 8.3 8.3.36
PHP 8.2 8.2.35

PHP公式は、完全な緩和策はなく、修正版への更新が安全な選択としています。LinuxディストリビューションやLTSベンダーでは修正をバックポートしている場合があるため、OSやホスティング事業者が提供する更新も確認してください。

PHP 8.1以前はPHPプロジェクト本体の通常サポート対象外です。古いPHPを使っている場合は、ディストリビューションやLTSベンダーが修正を提供しているか確認するか、サポート中のPHPへ移行する必要があります。

正式公開された2件の脆弱性

CVE-2026-109618：OOM処理中のメモリ破損からRCE

1件目は、PHPが**メモリ不足（Out Of Memory / OOM）**を処理する際、初期化途中のリクエストデータが不正な状態のまま残り、終了処理でそのデータを正常なものとして扱ってしまう問題です。

PHP公式GitHub Advisoryでは、multipartリクエストなどを利用してメモリ消費を引き起こす複数の経路が説明されています。

特にApacheのmod_phpでは、アプリケーション固有のPHPコードが動き始める前のリクエスト処理だけで攻撃を成立させる実証が行われています。確認された影響は、認証なしのRCEをWebワーカープロセスの権限で実行できるというものです。

一方、PHP-FPMについてはこのCVE単体では、ソース解析上は影響し得るものの、Advisory公開時点でmod_phpと同等の完全なFPM向け攻撃は実証されていないとされています。

CVE-2026-109619：前のリクエストの状態が残るuse-after-free

2件目は、あるリクエストで使った内部状態への参照がワーカーに残り、元のメモリが解放された後も、後続リクエストがその古い状態を利用してしまうuse-after-freeです。

攻撃には、古い状態を残す「producer」と、その状態を次のリクエストで利用する「consumer」が必要です。実証された経路では、複数のHTTPリクエストが同じPHPワーカーへ到達することでRCEにつながります。

この脆弱性については、mod_phpでRCEが確認され、セッションのアップロード進捗処理を使う経路ではPHP-FPMでもRCEが検証済みと公式Advisoryに記載されています。

「URLへアクセスするだけで即root」ではない

危険度は非常に高い一方、SNSで見かける表現の中には正確でないものもあります。

両CVEのCVSS v4.0は、

  • Attack Vector：Network
  • Privileges Required：None
  • User Interaction：None
  • Attack Complexity：High
  • Attack Requirements：Present

となっています。つまり、ネットワーク越し・認証不要・利用者の操作不要なのは事実ですが、あらゆるPHPサイトへ単純な1リクエストを送れば必ず成功する、という意味ではありません。

また、公式Advisoryで確認されているRCEはWebワーカーの権限です。Linux環境なら www-data などで動いていることが多く、脆弱性そのものが直接root権限を与えるわけではありません。

ただし、WebワーカーがWebサイトのファイル、設定ファイル、DB接続情報などへアクセスできる構成は一般的です。rootでなくても、サイト改ざんや情報流出につながる可能性があるため、重大な問題であることに変わりはありません。

どのPHP環境が対象になる？

PHP公式は、Webリクエストを処理するPHP環境として次を挙げています。

  • PHP-FPM
  • Apache + mod_php
  • php-cgi
  • FrankenPHP
  • LiteSpeed

PHP公式はmod_phpを特に高リスクと評価しています。理由は、CVE-2026-109618でアプリケーションコードが動く前に未認証リクエストだけで攻撃を発火させる経路が実証されているためです。

Cloudflareは今回の2件を「php2shell」と呼び、PHP 5.4以降を実行するWebサーバーが影響を受けると説明しています。古いPHPについてはPHP本体から新しいリリースが提供されないため、OSベンダーやLTSベンダーのバックポート有無を確認してください。

WordPress利用者はどうすればいい？

今回の問題はWordPress本体や特定プラグインの脆弱性ではなく、下で動くPHPランタイム側の脆弱性です。

そのため、WordPress本体やプラグインを更新しただけでは今回のPHP脆弱性の修正にはなりません。対応はホスティング形態によって変わります。

WordPress.comなどのフルマネージド型

OSやPHPを利用者が管理しないサービスでは、PHP基盤の更新は基本的にサービス運営側の対応範囲です。利用者は運営からの告知や障害情報を確認してください。

共有レンタルサーバー

PHP本体へのパッチ適用はサーバー会社が行うケースが多いですが、ユーザーがPHPの系統を選択している場合には、安全なバージョンへの切り替え操作が必要になることがあります。

まず契約中の事業者のセキュリティ告知を確認し、独自判断で別系統へ変更する前に、事業者がどのバージョンへ修正を適用したか確認するのが安全です。

VPS・クラウドVM・自前サーバー

自分でOSやPHPを管理している場合は、管理者自身が更新する必要があります。

PHP公式バイナリを直接使っているなら修正版へ、Ubuntu・Debian・RHEL系などのディストリビューションパッケージを使っているなら各ベンダーのセキュリティ更新へ従います。更新後はPHP-FPMやWebサーバーなど、必要なプロセスが修正版を読み込んでいることも確認します。

session.upload_progress を無効にすれば大丈夫？

CVE-2026-109619では、session.upload_progress を利用する実証経路が確認されています。そのため一部の事業者や管理者が、この機能を暫定的に無効化する対応を取る場合があります。

ただし、公式Advisoryは設定変更だけですべての経路を塞げるわけではないとしています。CVE-2026-109618にも別経路があり、CVE-2026-109619も他の内部状態がproducer / consumerになる可能性があります。

したがって、session.upload_progress.enabled = Off は特定経路に対する緩和策にはなり得ても、修正版への更新の代わりにはなりません。

Cloudflareを使っていれば大丈夫？

Cloudflareは、今回のphp2shellに対するWAF保護を公開前から展開しており、公開後も攻撃パターンに合わせてルールを更新しています。

これは重要な防御層ですが、Cloudflare自身もWAFをパッチの代わりとはしていません。オリジンサーバーで脆弱なPHPが動いているなら、最終的にはPHPまたはベンダー提供パッケージを更新する必要があります。

なお、Cloudflare Pagesで静的HTMLだけを配信するサイトや、PHPを使わないCloudflare Workersは、今回のPHPランタイム脆弱性を直接受ける構成ではありません。

攻撃はすでに始まっている？

Cloudflareは、公開日に今回の脆弱性を狙った攻撃トラフィックを観測していると報告しています。攻撃者がWAFを回避しようとペイロードを変化させていることも説明されています。

一方で、世界中のPHPサイトがすでに大量侵害された、といった規模まではこの記事執筆時点で確認できません。

「悪用を狙う通信が観測されている」ことと、「大規模な侵害が確認された」ことは分けて見る必要があります。

一般ユーザー向けの確認順

自分でサーバーを管理していないWordPress利用者なら、慌ててPHPの設定ファイルを編集するより、次の順番で確認するのが分かりやすいです。

  1. 使っているサービスがWordPress.com、共有レンタルサーバー、VPSのどれか確認する
  2. 契約中のホスティング会社から今回のPHP脆弱性に関する告知が出ているか確認する
  3. 自分でPHPバージョンを選択できる場合、現在のバージョンと事業者が案内する修正版を確認する
  4. WordPress本体・テーマ・プラグインの更新とは別に、PHP側の対応状況を確認する
  5. 重要なサイトならバックアップと直近ログの保全状況も確認する

VPSや自前サーバーの管理者は、これに加えてOSベンダーのセキュリティ更新、実行中プロセスのバージョン、Webサーバー構成を確認してください。

事前速報から何が変わった？

23時前の段階では、PHP公式が公開していたのは「Critical 9.2が2件」「修正版を準備中」という情報まででした。正式公開によって、次が確定しました。

  • CVEは CVE-2026-109618 / CVE-2026-109619
  • どちらも認証不要RCEにつながる
  • 修正版は 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12
  • mod_phpではアプリケーションコードより前に成立する実証経路がある
  • PHP-FPMでもCVE-2026-109619のRCE経路が検証されている
  • 設定変更だけの完全な汎用緩和策はなく、更新が必要

事前速報はこちらです。

PHPに重大な脆弱性2件、CVSS 9.2｜WordPress利用者が今確認すべきこと

まとめ

  • PHPのCritical脆弱性2件が正式公開された
  • CVE-2026-109618とCVE-2026-109619、どちらもCVSS v4.0 9.2
  • 条件成立時は認証なしRCEが可能
  • PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12で修正
  • PHP公式はWebリクエストを処理するPHP環境へ即時更新を推奨
  • mod_phpは特に高リスク
  • WordPress本体の更新だけではPHPの修正にならない
  • 共有サーバーは事業者の案内、VPS・自前サーバーは管理者自身の更新が必要
  • Cloudflare WAFなどの緩和策があっても、PHP更新の代わりにはならない

参考情報

関連記事

Web・セキュリティ

PHP2Shellは始まりか｜Cloudflare CEOが『他の重要ソフトにも重大脆弱性』、AIで発見が加速

Cloudflare CEOのMatthew Prince氏は、PHP2Shell以外にも重要ソフトウェアに複数の深刻な脆弱性が存在すると認識しているとReutersに説明。AIで脆弱性の発見と悪用までの時間が短縮する中、今後数カ月〜数年に何が起きるのか、一般ユーザー・サイト管理者が備えるべきことを

← ホームへ戻る