2026年10月のPHP脆弱性でWordPressに何が起きる？仕組みと懸念点を解説

2026年10月21日（日本時間）、PHPの開発元は、ログインしていない第三者にサーバー上でプログラムを実行されるおそれがある2件の脆弱性を修正しました。
原因はPHP本体にあるため、WordPress本体やプラグインの更新だけでは解消できません。

この記事では、2件の脆弱性の仕組みと、WordPressサイトへの影響を解説します。自分のサイトで確認すべき点、すぐに更新できない場合の応急措置、PHP 8.1以前・8.2を使っている場合の対応もまとめました。

2026年10月に公開されたPHPの脆弱性2件の概要

PHPの開発元（The PHP Group）は、2026年10月21日（日本時間）に、2件の脆弱性を修正したセキュリティリリースを公開しました。
2件とも、ログインしていない第三者からリモートでプログラムを実行される（RCE）おそれがある脆弱性です。

1件目のCVE-2026-109618は、メモリ不足をきっかけに、作りかけのデータが使われてしまう不備です。
2件目のCVE-2026-109619は、前のリクエストで解放されたメモリへの参照が残り、次のリクエストで使われる不備で、メモリ内容が漏えいするおそれもあります。
深刻度は、どちらもCVSS v4.0で9.2（Critical）と評価されています。

対象は「Webのリクエストを処理するすべてのPHP」で、PHPで動くWordPressサイトは、どれも確認が必要です。
修正版は、PHPの系列ごとに次の4つです。

• 8.5系：8.5.12
• 8.4系：8.4.27
• 8.3系：8.3.36
• 8.2系：8.2.35

PHP 8.1以前の対応は、後半の「PHP 8.1以前・8.2のWordPressサイトですべきこと」で説明します。

IPA（情報処理推進機構）は修正版の公開前に注意喚起を出し、PHPの利用状況を棚卸しして、公開後すぐに適用できるよう準備することを求めていました。

参考：PHP公式「News Archive 2026」
参考：GHSA-w8hw-w9fx-j79w「RCE via OOM corruption」（GitHub）
参考：GHSA-6wmf-4rv5-p3rp「RCE via stale global state」（GitHub）
参考：IPA「【事前準備のお願い】PHPのセキュリティリリース公開予定について」

脆弱性の仕組み：PHPのリクエスト処理で何が起きるのか

2件の原因は、PHPがリクエストを受け付けてから終了するまでの内部処理にあります。
CVE-2026-109618では、メモリ不足で処理が中断された際に、初期化が終わっていないデータが使われます。CVE-2026-109619では、前のリクエストで解放されたメモリへの参照が残り、次のリクエストで使われます。

前提：PHPは1回のアクセスをどう処理しているか

PHPがWordPressへのリクエストを処理するとき、大きく次の3段階をたどります。

1. 開始処理：送信データの解析やPHP設定の適用などを行う。
2. WordPressのコードの実行：WordPress本体・テーマ・プラグインのコードを実行し、ページの生成などを行う。
3. 終了処理：そのリクエストのために確保したメモリや内部の情報をリセット・解放する。

リクエストを処理するプロセスを「ワーカー」と呼びます。PHP-FPMでは、ワーカーを何回のリクエストで再起動するかをpm.max_requestsで設定できます。既定値の0は、リクエスト数による再起動を行わない設定です。

CVE-2026-109619は、同じワーカーが別のリクエストを処理することが成立条件の1つです。窓口の担当者が前の来客の書類を片付け損ね、次の来客の対応でその書類を使ってしまうような状態と考えると、流れをつかみやすいでしょう。

以下では、PHP開発元がGitHubで公開したセキュリティ情報を「GHSA」と表記します。

参考：PHP公式マニュアル「FPM Configuration」
参考：GHSA「RCE via stale global state」

CVE-2026-109618：メモリ不足で中断された処理のデータが使われる

修正前のPHPは、メモリの上限（memory_limit）に達するなどしてメモリ不足（OOM）が起きると、その場でリクエストの処理を中断します。

問題は、内部データの初期化が終わる前に中断される場合があることです。不完全なデータが残ったまま終了処理に進むと、PHPがそれを正常なデータとして参照し、不正なメモリ操作につながります。中断の原因となったメモリ確保は、その不完全なデータとは別の処理で起きても、この状態を引き起こします。

GHSAによると、ファイル送信などに使うmultipart形式のデータを解析する処理には、メモリ不足を引き起こす経路が複数あります。送信データがpost_max_sizeの上限内でも、PHP内部で扱う際にメモリ使用量が増え、memory_limitに達する場合があります。

この状態を繰り返し再現し、RCEにつなげられることが確認されています。mod_phpでは、WordPressのコードを実行する前の開始処理で攻撃が成立する場合があります。

修正版では、メモリ不足の際に突然処理を中断する仕組みを見直しました。安全に停止できる時点まで中断を遅らせる処理と、さらに高いメモリ使用量に達した場合に即座に終了する処理を組み合わせ、不完全なデータが終了処理で使われないようにしています。

参考：GHSA「RCE via OOM corruption」

CVE-2026-109619：前のリクエストで解放されたメモリが次の処理で使われる

PHPのワーカーは、エラー・セッション・拡張機能などに関する情報を保持しています。その一部は、個々のリクエストのために確保したメモリを参照しています。本来は、リクエストの終了時にこれらの参照をリセットしてから、メモリを解放します。

ところが、致命的エラーやメモリ不足でリセット処理が中断されたり、終了処理中の警告によって一度消した参照が再び作られたりする場合があります。その結果、すでに解放されたメモリへの参照だけがワーカー内に残ります。

同じワーカーが次のリクエストを処理する際、通常の初期化より前に動く処理がその参照を使うと、解放済みメモリへのアクセス（use after free）が起きます。

GHSAは、この脆弱性の成立に次の5条件が必要だと説明しています。

1. リクエストに属する情報への参照が、後からアクセスできる場所に保存される。
2. その参照がリセットされない、またはリセット後に再び作られる。
3. 参照先のメモリが解放されても、参照だけがワーカーに残る。
4. 同じワーカーが別のリクエストを処理する。
5. 通常の初期化でリセットされる前に、残った参照が使われる。

致命的エラーが1回起きただけで、直ちに攻撃が成立するわけではありません。実証例では、情報への参照が残る処理と、その参照が使われる処理が、同じワーカーに届いた別々のリクエストで起きています。

GHSAに挙げられた処理をWordPressの運用に当てはめると、確認箇所は次のように整理できます。

参考：GHSA「RCE via stale global state」

実行方式で危険度が違う：mod_phpが最も危険とされる理由

WebサーバーとPHPのつなぎ方を、この記事では「実行方式」と呼びます。
php.netは、PHP-FPM・Apacheのmod_php・php-cgi・FrankenPHP・LiteSpeedを含む「Webのリクエストを処理するすべてのPHP」を対象としたうえで、mod_phpを最も危険としています。
php.netが挙げる理由は、アプリケーションのコードが動く前に、ログインしていないアクセスで攻撃が成立する実証例があることです。

GHSAによると、mod_phpは開始処理に失敗しても終了処理を実行します。
そのため、開始処理中の送信内容の解析でメモリ不足を起こさせると、WordPressのコードが動く前にCVE-2026-109618の攻撃が成立する場合があります。
この経路は、既定の設定（入力とメモリの上限）と、複数のワーカーを持つ通常の構成で、HTTP経由での完全なRCEまで実証されています。
成功のしやすさは、PHPのビルドや拡張機能などの環境によって変わります。

一方、PHP-FPMは開始処理に失敗したワーカーを終了させるため、この経路はそのままでは成り立ちません。
ただしGHSAは、開始処理の後に別の経路でメモリ不足に達する可能性があるとして、ソースコードの分析からPHP-FPMも影響を受けるとしています。
CVE-2026-109619では、セッションのアップロード進捗を使う経路でのRCEが、mod_phpとPHP-FPMの両方で実証されています（PHP-FPMでは、アプリケーション側の処理が成立条件を満たすことが前提）。

mod_phpでは、アプリケーションの処理に依存せず攻撃が成立する場合があります。PHP-FPMなどの方式でも条件次第で成立するため、実行方式にかかわらず修正の適用が必要です。

php.netは、表にないphp-cgiも対象に含めています。
実行方式はサーバーによって違うため、「確認する場所と、番号だけで判断できない理由」の方法で自分のサイトを確かめましょう。

参考：PHP公式「News Archive 2026」
参考：GHSA-w8hw-w9fx-j79w「RCE via OOM corruption」（GitHub）
参考：GHSA-6wmf-4rv5-p3rp「RCE via stale global state」（GitHub）

WordPress本体やセキュリティプラグインだけでは対処できない理由

WordPress本体・テーマ・プラグインを更新しても、PHP本体の脆弱性は解消しません。また、mod_phpで実証された経路には、WordPressのコードが動く前に攻撃が成立するものがあります。

以下は、PHP公式とGHSAの説明をWordPressの実行順序に当てはめたものです。これらの公式情報がWordPress固有の被害や検証結果を示しているわけではありません。

1. 修正する対象が違う：今回修正されたのはPHP本体（php-src）です。WordPress側の更新だけでは、サーバーのPHPは修正されません。
2. 防御機能が動く前に攻撃が成立する：mod_phpで実証されたCVE-2026-109618の経路は、PHPの開始処理中に成立します。CVE-2026-109619のセッションを使う経路も、mod_phpでは開始処理中に起こる場合があります。PHPで実行されるセキュリティプラグインは、この時点ではまだ動いていないため、これらの経路を防ぐことはできないと考えられます。auto_prepend_fileでWordPressより先に読み込むPHPファイルも、開始処理より前に動くわけではありません。
3. 攻撃対象がログイン画面に限られない：mod_phpでは、送信データの解析がアプリケーションのコードより前に行われます。そのため、ログイン画面だけを保護しても十分ではなく、PHPが処理するほかのページへのリクエストも確認が必要です。

防御方法によって、対処できる範囲は異なります。

PHP-FPMで実証されたセッションを使う経路は、開始処理の後、アプリケーション実行中に情報への参照が残るものです。このような経路では、WordPress側の不具合を直すことで攻撃の成立条件を減らせる余地があります。それでも、PHP本体の修正は必要です。

参考：GHSA「RCE via OOM corruption」
参考：GHSA「RCE via stale global state」
参考：PHP公式マニュアル「Description of core php.ini directives」

WordPressサイトで確認したい3つのポイント

CVE-2026-109619で問題になる「参照が残る処理」と「残った参照を使う処理」は、WordPressの運用にも関わります。GHSAの説明を踏まえると、次の3点を確認する必要があります。

.htaccessに書かれたPHPの設定（php_value）が引き金になりうる

Apacheのmod_phpでは、.htaccessに書かれたphp_value・php_flagなどの設定は、通常の初期化より前に適用されます。
その設定が非推奨だったり値が不正だったりすると、適用の際に警告が出ます。
GHSAは、この警告の処理が「残った参照を使う処理」になりうるとしています。

GHSAが挙げる「警告が出る設定」には、次のようなものがあります。

• 非推奨になった設定（auto_detect_line_endings=1など）
• PHP 8.2以降での、memory_limit・送信サイズ・入力・タイムアウトなどの不正な値や桁あふれ
• memory_limit・date.timezoneなどの、無効な値や競合する値

警告を画面にもログにも出さない設定にしていても、この問題は防げません。
PHPが警告を出すかどうかを判断する前に、問題の情報に触れてしまうためです。

mod_phpを使っていて、.htaccessにphp_value・php_flagの行が残っている場合は、警告が出る設定になっていないかを確認しましょう。
問題になるのは行があること自体ではなく、警告を出す設定であることです。
また、この警告だけで攻撃が成立するわけではなく、次の節の「参照を残す処理」など、ほかの条件もそろう必要があります。

一方、PHP-FPMで使われる.user.iniは通常の初期化の後に適用されるため、同じタイミングで残った参照を使う経路にはならないと、GHSAは説明しています。
ただし、前段のWebサーバーからPHP_VALUE等で設定を送る構成では、PHP-FPMも条件付きで影響を受けます。

参考：GHSA-6wmf-4rv5-p3rp「RCE via stale global state」（GitHub）

致命的エラーやタイムアウトの放置がリスクにつながる

GHSAは、情報への参照が残る原因として、次のような処理の中断を挙げています。

• 構文の誤りなど、コードの解析・コンパイルの失敗
• 捕捉されないエラーや、requireの失敗
• 実行時間の上限超過（Maximum execution time exceeded）
• メモリ不足

GHSAは、攻撃者が到達できる経路の致命的エラーを無くすよう求めています。
その対象には、通常のページ表示だけでなく、アップロード・インポート・エラーページ・プラグインなどの経路も含まれます。

WordPressでは、フォーム送信やファイルのアップロードなど、外部から利用できる処理で致命的エラーやタイムアウトが繰り返されていないかを確認しましょう。攻撃者がその処理を実行できる状態では、脆弱性の成立条件の一部になる可能性があります。

WordPressの「リカバリーモード」は、プラグインやテーマが原因の致命的エラーが起きたときに、管理者がログインして問題を直せるようにする機能です。
PHP内部に残った参照をリセットする機能ではないため、今回の脆弱性を解消するものではありません。

また、エラーログに何も出ていないからといって安心はできません。
GHSAは「ログにエラーが無いことは安全の証明にならない」とし、PHPがメッセージを書き込む前に失敗することもあると説明しています。

参考：GHSA-6wmf-4rv5-p3rp「RCE via stale global state」（GitHub）
参考：WordPress公式「Recovery Mode」

セッションを使わないWordPressでも無関係ではない

PHPのアップロード進捗機能（session.upload_progress）も、残った参照を使う処理になることがあります。
この機能はPHPの既定で有効です。GHSAによると、アプリケーションがsession_start()を呼ばなくても動作します。

WordPress本体はPHPのセッション開始を前提としておらず、現在の開発版のコードにもsession_start()の呼び出しはありません。
しかし、この機能はWordPressがセッションを開始するかどうかに関係なくPHP側で動くため、WordPressのサイトもこの経路の対象から外れません。

GHSAによると、この機能は参照を残す処理にも、残った参照を使う処理にもなり得ます。PHP-FPMでも、アプリケーション側の処理が条件を満たす場合に、この経路で攻撃が成立することが実証されています。
なお、セッションを開始していないと言えるのはWordPress本体に限った話で、プラグインがセッションを使っている場合はあります。
本体がセッションを開始しないことは、応急措置の1つ（session.upload_progress.enabled=0）を検討するときの判断材料になります。

ここまでの3つの点に当てはまらなくても、安全とは言えません。
GHSAは、すべての攻撃経路に対応できる設定上の回避策はないとしています。
これらの見直しと並行して、PHPの修正を適用してください。

参考：PHP公式マニュアル「Runtime Configuration（Session）」
参考：GHSA-6wmf-4rv5-p3rp「RCE via stale global state」（GitHub）

悪用された場合にWordPressサイトで起こりうること

公式情報で確認されている影響は、Webリクエストを処理するユーザーの権限でプログラムを実行されることと、CVE-2026-109619によるメモリ内容の漏えいです。

一般的なWordPressの構成では、PHPを実行するユーザーはwp-config.phpを読み取り、wp-content配下の一部に書き込めます。以下は、そうした権限でコードを実行された場合に想定される影響です。今回の脆弱性による実際の被害事例を示すものではありません。

wp-config.phpに書かれた接続情報や認証用のキーの読み取り

wp-config.phpには、データベースの接続情報など、サイトの基本設定が書かれています。標準的な構成では、認証用のキーやソルト（AUTH_KEYなど）も保存されています。

WordPressの公式ドキュメントは、このファイルを所有者とWebサーバーだけが読める設定（一般に400または440）にするよう勧めています。
ファイルの読み取り権限を絞っていても、WordPressを動かすPHPからは設定情報にアクセスできる必要があります。

PHPを実行するユーザーの権限でコードを動かされると、データベースのユーザー名やパスワード、認証用のキーやソルトを読み取られるおそれがあります。

これは、コード実行を許した場合に想定される影響です。
GHSAが挙げる「メモリ内容の漏えい」で何が漏れるかは具体的に示されておらず、メモリの漏えいでwp-config.phpの中身が漏れるとまでは言えません。

参考記事：wp-config.phpファイルを徹底解説！役割・場所・パーミッション設定まで

参考：WordPress公式「wp-config.php」
参考：WordPress公式「Hardening WordPress」
参考：WordPress「wp-config-sample.php」（GitHub）

バックドア（裏口）の設置

WordPressでは、画像の保存や更新などのために、wp-content配下の一部にPHPから書き込める構成が使われます。
その権限でコードを実行されると、書き込み可能な場所に不正なファイルを設置されるおそれがあります。設置先でPHPファイルを実行できる場合は、再侵入のためのバックドアとして使われる可能性があります。
置かれたファイルは、PHPを修正版にしてもサーバーに残るため、更新だけで元どおりになるとは限りません。

参考記事：バックドアとは?発見・除去方法と感染前の対策まとめ

参考：WordPress公式「Hardening WordPress」

データベースの改ざん

WordPressは、wp-config.phpの接続情報を使ってデータベースに接続しています。
その接続情報を使われると、管理画面にログインせずにデータベースを操作されるおそれがあります。データベースユーザーに与えられた権限によっては、管理者ユーザーの追加や記事の改ざんも可能です。
ログインを経由しないため、管理画面のログイン履歴だけを見ていても気づけない可能性があります。

参考記事：WordPressが不正改ざん！？影響範囲と対策・復旧方法をご紹介!

同じ実行ユーザーで動くほかのサイトへの波及

複数のWordPressサイトが同じ実行ユーザーで動いている場合、1つのサイトへの侵入が、ほかのサイトに影響するおそれがあります。攻撃者が、同じユーザーで読み書きできるファイルにもアクセスできるためです。
同じ契約内でもサイトごとに実行ユーザーが分かれている場合があり、「同じ契約か」だけで影響範囲は判断できません。
ほかの契約者のサイトにまで及ぶかは、事業者が実行ユーザーをどう分けているかで変わるため、一概には言えません。
たとえばApacheには、CGIなどのプログラムをWebサーバーとは別のユーザーで実行するsuEXECという仕組みがあります。

侵害が疑われる場合は、PHPの修正を適用したうえで、同じ実行ユーザーで動くほかのサイトも調査の対象にしましょう。

参考：Apache HTTP Server公式「suEXEC Support」

自分のWordPressサイトが対象かを判断する

PHPで動いている以上、WordPressサイトはすべて確認の対象です。
まず管理画面でPHPのバージョンと実行方式を確認し、その後、サーバー事業者や保守担当者に修正の適用状況を問い合わせましょう。

確認する場所と、番号だけで判断できない理由

PHPのバージョンと、欄があれば実行方式も、WordPressの管理画面で確かめられます。
開くのは「ツール」→「サイトヘルス」→「情報」タブ→「サーバー」です。

確認する項目は、次の2つです。

• PHP バージョン：使っている系列の修正版（8.5.12／8.4.27／8.3.36／8.2.35）と比べる
• PHP SAPI：この欄が表示されていれば、PHPの実行方式がわかる

「PHP SAPI」の欄が見当たらない場合は、次の節の確認事項2で、PHPを管理している相手に実行方式を聞きましょう。

「PHP SAPI」に表示される主な値と実行方式の対応は、次のとおりです。

• apache2handler：Apacheのmod_php
• fpm-fcgi：PHP-FPM
• cgi-fcgi：CGI・FastCGI（PHP-FPMを使わない方式）
• litespeed：LiteSpeed

ただし、番号が修正版より低くても、それだけで対象とは決められません。
php.netは、Linuxの配布元やLTSベンダーには修正を事前に渡したとして、更新されたパッケージを配布元に確認するよう案内しています。
配布元が修正だけを取り込んだ（バックポートした）パッケージでは、番号が修正版より低く見えても、修正済みの場合があります。
バージョン番号を確認したうえで、PHPの管理者に修正の適用状況を問い合わせてください。

参考：WordPress.org「今すぐ PHP を更新」
参考：PHP公式マニュアル「php_sapi_name」
参考：PHP公式「News Archive 2026」

誰が更新するかはサーバーの種類や契約によって変わる

PHPの更新を担うのは、サーバー上のPHPを管理する事業者や担当者です。WordPressの管理画面で更新するものではありません。

• 共用レンタルサーバー：事業者がPHPの実行環境を提供します。利用者が管理画面で系列を選べる場合でも、修正版の提供や適用は事業者の運用によります。
• マネージドWordPress：事業者が実行環境を管理します。系列の切り替えや更新を自動で行うか、利用者側の操作が必要かはサービスによって異なります。
• VPS・専用サーバーなど：非マネージドの契約では、自分・自社・保守委託先がPHPの更新を行います。事業者が管理を代行する契約もあるため、管理範囲を確認してください。

今回必要なのは、2件の脆弱性の修正を含むPHPを使うことです。サポート中の系列であれば、同じ系列の修正版（8.3系なら8.3.36以降など）を適用する方法もあります。別の系列への移行が必須というわけではありません。

サーバー事業者や保守担当者には、次の3点を確認しましょう。

1. 修正版、または修正を取り込んだパッケージは適用済みか。未適用なら、いつ適用するか。
2. PHPの実行方式は何か。mod_phpかPHP-FPMかなど、サイトヘルスで確認できなかった場合に問い合わせる。
3. 修正を適用するまでに、どのような応急措置を取っているか。

PHP 8.1以前を使っている場合は、配布元による修正の提供状況に加え、サポート対象の系列へ移行できるかも確認してください。

参考：WordPress.org「今すぐ PHP を更新」
参考：PHP公式「News Archive 2026」

すぐに更新できないときの応急措置と、その限界

PHP公式とGHSAは、完全な対策には修正の適用が必要だとしています。以下の応急措置は、一部の攻撃経路のリスクを減らすためのものです。

PHPの設定変更は、リクエストの解析より前に適用されるサーバー管理者側の設定で行います。WordPressの管理画面やプラグインの設定だけで済ませることはできません。

参考：PHP公式「News Archive 2026」

サーバー管理者が行う応急措置

ここで紹介する応急措置の対象は、VPSや専用サーバーなどで自分でPHPを管理している人です。
共用レンタルサーバーなどで、PHPの設定を自分で変えられない場合は、事業者に応急措置の実施を確かめましょう。

PHPの設定変更は、起動時のphp.iniやPHP-FPMのプール設定など、リクエストの解析より前に反映される場所で行い、設定後はすべてのワーカーを再起動します。memory_limit=-1については、アプリケーションなどが有限の値に戻せない形で設定し、実際の適用状態も確認してください。
PHPマニュアルは、管理者側の設定に使うphp_admin_value・php_admin_flagは.htaccessでは使えず、これで設定した値は.htaccessでもini_set()でも上書きできないとしています。

memory_limit=-1にするとPHPのリクエスト単位のメモリ上限がなくなるため、サーバーのメモリを大量に消費されるリスクが生じます。
GHSAは、PHPに届く前の送信データの制限や、コンテナのメモリ上限（これも完全な対策ではないとしている）もあわせて挙げています。

pm.max_requests=1は、CVE-2026-109619のGHSAが、性能面で許容できる場合の選択肢として挙げています。リクエストごとにワーカーを再起動するため処理効率に影響しますが、PHP-FPM以外には適用できず、2件の脆弱性をまとめて解消する措置でもありません。

PHPに届く前の送信データの制限としてGHSAが挙げるのは、post_max_sizeを保守的に保ったうえで、解析後の送信サイズ、入力の数、multipartのパート数、アップロード数などに上限を設けることです。
アプリケーションがmultipartを使わないならPHPに届く前に遮断する方法も示されています。
WordPressはメディアのアップロードなどでmultipartを使うため、一律に遮断すると必要な機能も使えなくなります。制限の範囲はサーバー管理者と検討してください。

session.upload_progress.enabled=0について、GHSAは、機能が不要なら修正後も無効にしておくことを選択肢に挙げています。WordPress本体がPHPのセッションを開始しないことだけで判断せず、プラグインなどがアップロード進捗機能に依存していないかも確認してください。

現在のWordPress開発版のコードでは、memory_limitが-1の場合、WP_MEMORY_LIMITの適用やメモリ上限の引き上げは行われません。ただし、プラグインや独自コードを含むすべての設定まで保証するものではないため、サーバー管理者側で上書きを防ぎ、適用状態を確認する必要があります。

いずれの措置も、更新までのつなぎにとどまります。

参考：GHSA-w8hw-w9fx-j79w「RCE via OOM corruption」（GitHub）
参考：GHSA-6wmf-4rv5-p3rp「RCE via stale global state」（GitHub）
参考：PHP公式マニュアル「How to change configuration settings」

WordPress側でできるリスクの低減

WordPress側でも、攻撃の成立条件を減らすために、次の2点を見直せます。

1. .htaccessに残ったphp_value・php_flagを見直す：不要な行や廃止された設定を消し、必要な設定はサーバー側の起動時の設定（php.iniなど）に寄せる。起動時の設定を自分で変えられない場合は、事業者に相談する
2. 外部から届くアクセスで起きる致命的エラーやタイムアウトを放置しない：サーバーのエラーログで、致命的エラーや実行時間の上限超過が繰り返し出ていないかを確かめ、原因のプラグインを直すか止める。ただし、ログに出ていないことは安全の証明にならない

どちらも、更新の代わりにはなりません。

参考：GHSA-6wmf-4rv5-p3rp「RCE via stale global state」（GitHub）

サイトを一時的に止めるなら、PHPに処理が届かない形で

WordPressの標準のメンテナンス表示（.maintenanceファイル）は、PHPがWordPressのファイルを読み込み始めた後、WordPressの設定処理（wp-settings.php）の途中で、「メンテナンス中」の画面を出す仕組みです。
メンテナンスモードのプラグインも、WordPressのコードとして動く点は同じです。
mod_phpでは、それより前の開始処理で攻撃が成立する場合があります。WordPressのメンテナンス表示に切り替えるだけでは、PHPへのリクエストを止められません。

止めるなら、PHPにアクセスが届かないようにWebサーバー側で遮断するか、事業者に依頼しましょう。

参考：GHSA-w8hw-w9fx-j79w「RCE via OOM corruption」（GitHub）

PHP 8.1以前・8.2のWordPressサイトですべきこと

古い系列のPHPを使っているWordPressサイトでは、今回の修正への対応と、サポートが続く版への移行を合わせて考える必要があります。

8.1以前と8.2で対応方法が違う

PHP 8.1以前は、PHPの開発元からの更新が終わっていて（8.1は2025年12月31日に終了）、今回も通常のバージョン番号付きリリースは提供されていません。
しかし、開発元は深刻さを踏まえ、7.4・8.0・8.1向けに最小限のソースコードの修正を例外的に公開しました。

ただし、これはソースコードからPHPをビルドする人や、LTSベンダーを利用できない人に向けたものです。
配布元やLTSベンダーが独自に修正を取り込んでいる場合もあるため、レンタルサーバーを使っているなら、まず事業者に確かめましょう。

今後見つかる脆弱性について、開発元から修正が出る保証はありません。
配布元やLTSベンダーの修正がどこまで続くかは、契約先に確かめましょう。

また、今回はあくまで例外的な修正になります。
今後も、古い系列を使い続けるのはリスクになるので、サポート対象の系列への移行を急ぎましょう。

PHP 8.2は、8.2.35以降の修正版、または今回の修正を取り込んだ配布元のパッケージを適用すれば、今回の脆弱性に対応できます。

なお、PHP開発元による8.2のセキュリティサポートは2026年12月31日で終了します。
修正版を適用したうえで、移行の計画を今から立てておきましょう。

参考：PHP公式「News Archive 2026」
参考：PHP公式「Unsupported Branches」
参考：PHP公式「Supported Versions」

WordPressでバージョンアップするときに確かめること

WordPressサイトでPHPを更新するときに確かめることは、次の3点です。

• 移行先の版：WordPress.orgの現在の推奨はPHP 8.3以上。セキュリティサポートは、8.3が2027年12月31日まで（8.4は2028年12月31日、8.5は2029年12月31日まで）
• プラグイン・テーマの対応：開発元が公開する対応PHPバージョンを確認し、テスト環境で移行先のPHPを使って動作を確かめる。互換性チェックツールを併用する場合も、移行先のバージョンに対応しているかを確認する。問題があれば、開発元への相談や代替製品への変更を検討する
• 切り替え前後の確認：ファイルとデータベースをバックアップし、WordPress本体・テーマ・プラグインを更新する。PHPの切り替え前後で、ページ表示・フォーム送信・管理画面など、必要な機能が動くかを確認する

WordPress.orgも、PHP更新前のバックアップや、本体・テーマ・プラグインの更新、互換性の確認を勧めています。
詳しい手順と、バージョンアップ後にエラーが出たときの対処は、次の記事で解説しています。

参考：WordPress.org「Requirements」
参考：WordPress.org「今すぐ PHP を更新」
参考：PHP公式「Supported Versions」

PHPの更新を依頼する際の費用と保守契約

PHPの更新にかかる費用は、現在と移行先のバージョンの差、テーマ・プラグインの対応状況、改修の必要性、動作確認の範囲などによって変わります。

サーバー事業者が同じ系列の修正版を適用する場合と、古い系列から移行するためにサイト側の改修が必要な場合とでは、作業内容も異なります。

Webサイトの保守を委託している場合は、PHPの更新、互換性の確認、改修のどこまでが契約に含まれるかを確認しておきましょう。

PHPのバージョンの設定・更新は、主にサーバー側になるため、一般的なWebサイト・WordPress保守の契約では対応範囲に含まれていない場合も多いです。

この機会に、改めて、サーバー事業者と制作・保守会社それぞれの対応範囲と緊急時の連絡先や役割を明確にしておくと対応しやすくなります。

参考記事：WordPress保守とは？選び方やおすすめサービス9選、利用者の声を紹介

よくある質問

PHP-FPMで動いているサイトなら安全ですか？

安全とは言えません。
PHP-FPMは開始処理に失敗したワーカーを終了させるため、mod_phpで実証された経路は、そのままでは成り立ちません。
しかし、CVE-2026-109618はソースコードの分析で影響を受けるとされ、CVE-2026-109619は、アプリケーション側の処理が条件を満たす場合に、アップロード進捗を使う経路での攻撃がPHP-FPMでも実証されています。
前段のWebサーバーからPHPの設定を送る構成では、設定の警告を使う経路も条件付きで成り立ちます。

参考：GHSA-w8hw-w9fx-j79w「RCE via OOM corruption」（GitHub）
参考：GHSA-6wmf-4rv5-p3rp「RCE via stale global state」（GitHub）

CDNやクラウド型のWAFを使っていれば防げますか？

それだけで、すべての攻撃を防げるとは言えません。
GHSAは、PHPに届く前に送信サイズや入力数を制限することを応急措置に挙げていますが、更新だけが完全な対策で、すべての攻撃経路に対応できる設定上の回避策はないとしています。
PHPに届く前の制限は、修正を適用するまでのリスクを減らす手段として検討してください。

参考：GHSA-w8hw-w9fx-j79w「RCE via OOM corruption」（GitHub）
参考：GHSA-6wmf-4rv5-p3rp「RCE via stale global state」（GitHub）

攻撃を受けたかどうかを確かめる方法はありますか？

ログだけで、侵害の有無を断定することはできません。
GHSAは、ログにエラーが無いことは安全の証明にならず、PHPがメッセージを書き込む前に失敗することもあるとしています。

悪用の状況について、IPAは修正版の公開前の注意喚起で、その時点では悪用した攻撃を確認していないとしていました。
同時に、悪用されるおそれがあり、攻撃者が極めて短時間で攻撃を実行する可能性もあるとしています。
悪用状況は変わるため、PHP開発元や公的機関の最新情報を確認してください。米国CISAの既知の悪用脆弱性の一覧（KEV）などに掲載されていない場合でも、攻撃が起きていないとは判断できません。

侵害が疑われる場合の調べ方と復旧の手順は、次の記事を参考にしてください。

参考記事：ハッキングから自力復旧！WordPressサイトを正常に戻す手順を解説

参考：GHSA-6wmf-4rv5-p3rp「RCE via stale global state」（GitHub）
参考：IPA「【事前準備のお願い】PHPのセキュリティリリース公開予定について」
参考：CISA「Known Exploited Vulnerabilities Catalog」

.user.iniやwp-config.phpで設定を変えれば応急措置になりますか？

それだけでは、公式が求める応急措置にはなりません。
PHPの開始処理に関わる設定は、リクエストの解析より前にサーバー管理者側で適用する必要があります。
php_admin_valueのような管理者側の設定は.htaccessでは使えず、ini_set()でも上書きできません。
.user.iniはディレクトリごとの設定で、PHP-FPMでは通常の初期化の後に適用されます。
wp-config.phpで変えられるWordPressのメモリ設定は、WordPressのコードが動いてから反映されるため、それより前の開始処理で起きる経路には効かないと考えられます。
応急措置は、サーバーの管理者側で行いましょう。

参考：PHP公式マニュアル「How to change configuration settings」
参考：GHSA-6wmf-4rv5-p3rp「RCE via stale global state」（GitHub）

まとめ

今回の2件の脆弱性は、WordPress本体ではなく、PHPのリクエスト処理に原因があります。WordPress本体やプラグインを更新するだけでは解消できず、mod_phpではWordPressのコードが動く前に攻撃が成立する場合もあります。

• まず修正の適用状況を確認する：サイトヘルスでPHPのバージョンと実行方式を調べ、サーバー事業者や保守担当者に修正済みかを問い合わせる。配布元が修正を取り込んでいる場合があるため、番号だけで判断しない。
• 応急措置で対応を終えない：サーバー側の設定やWordPress側のエラー修正でリスクを減らせても、PHP本体の更新は必要。メンテナンス表示への切り替えだけでは、PHPへのリクエストは止まらない。
• 古い系列は移行も進める：PHP 8.1以前は配布元の修正を確認し、サポート対象の系列への移行を急ぐ。8.2は今回の修正を適用したうえで、2026年末のサポート終了に備える。

攻撃者によるコード実行が成立すると、設定情報の読み取りやバックドアの設置、データベースの改ざんなどにつながるおそれがあります。侵害が疑われる場合は、PHPの更新に加え、サイトの調査と復旧も必要です。

まずは、自分のサイトで使っているPHPを確認し、サーバー事業者や保守担当者に、修正の適用状況と未適用の場合の対応予定を問い合わせてください。

WordPress保守・運用のパートナーなら「wp.support」にお任せ！

WordPressサイトを運用していて、以下のようなお悩みはありませんか？

• 管理画面を使いやすくしたいけれど、カスタマイズする時間や技術がない…
• サイトのUI/UXを改善したいけれど、自社内では難しい…
• WordPressサイトを高速化したいけれど、ノウハウがない…
• セキュリティ対策をしたいけれど、知識のある人材がいない…
• 日々の業務に追われて、バージョンアップなどの保守業務が放置気味…
• ちょっとしたトラブルを気軽に相談できる相手が欲しい…

「wp.support」は、WordPressのプロフェッショナル集団によるWordPress保守サービスです。
「セキュリティ対策」「バージョンアップ対応」「定期バックアップ」はもちろん、「電話サポートが無制限」なのでカスタマイズの方法やトラブル発生時にも気軽にプロに相談できます。

既に導入済みのお客様からも、
「些細なことでも気軽に相談できるパートナー的な存在」
「困ったら相談していいんだ、と気持ちが楽になった」
と大変ご好評をいただいています。

WordPress保守・運用のパートナーをお探しなら、ぜひお気軽にお問合せください。

>> wp.supportに無料相談する