PHPに重大な脆弱性2件、修正版を公開——WordPress運営者が確認すべきこと

インターネット , , , , ,

PHPの開発チームは2026年10月21日、2件の重大な脆弱性を修正した更新版を公開しました。条件がそろうと、ログインしていない攻撃者にサーバー上で不正なプログラムを実行されるおそれがあります。［1］

WordPress運営者が最初に確認すべきなのは、契約しているサーバーのPHPに修正が適用されたかどうかです。今回の問題はPHP側にあり、WordPress公式は、この2件への対応としてWordPress本体を更新する必要はないと説明しています。［2］

ただし、表示されるPHPのバージョンが古いままでも、修正済みの場合があります。サーバー会社が修正部分だけを取り込むことがあるためです。この記事では、公式情報と国内3サービスの対応を比較し、修正状況の確認から更新後の点検までの手順を整理します。

情報確認日：2026年10月23日。日時は、特記がない限り日本時間です。各社の対応状況は変わるため、契約サービスの最新告知も確認してください。

何が危険なのか——2件とも深刻度は「緊急」

今回の脆弱性は、WordPressにログインできる人だけが悪用できる問題ではありません。識別番号は「CVE-2026-109618」と「CVE-2026-109619」です。深刻度を示すCVSS v4.0のスコアは、いずれも10点満点中9.2です。［1］

識別番号問題が起きる仕組み注意点
CVE-2026-109618メモリ不足で処理を中断した際、準備途中の内部データを正しいデータとして扱ってしまうApacheのmod_phpでは、サイト側のプログラムが動く前に攻撃が成立する経路が実証された
CVE-2026-109619前の通信処理で使ったメモリへの参照が残り、後の通信処理で再利用されてしまうサーバーの構成や内部に残る情報の種類によって、悪用される経路が異なる

この表では、PHP開発元の技術資料をもとに、問題の仕組みを簡略化しています。悪用されると、PHPの処理に与えられた権限でコードを実行される可能性があります。ただし、必ずサーバー全体の最高権限まで奪われるという意味ではありません。［3］［4］［5］

PHP公式は、PHP-FPMやLiteSpeedなども確認対象に挙げています。「Apacheのmod_phpではないから対象外」とは判断できません。WordPress以外のPHP製アプリを使っている場合も、提供元の案内を確認する必要があります。［1］

修正版は4系列——「PHP 8なら安全」とは限らない

「8.3」などの系列だけでなく、「8.3.36」のような詳しいバージョン番号と、提供元の修正情報を確認してください。PHP公式が公開した修正版は、次の4つです。独自の修正が加えられていない公式版を使っている場合は、利用中の系列の修正版以降へ更新します。［1］

利用中の系列今回の修正版公式のセキュリティサポート終了日終了日までの日数
PHP 8.28.2.352026年12月31日69日
PHP 8.38.3.362027年12月31日434日
PHP 8.48.4.272028年12月31日800日
PHP 8.58.5.122029年12月31日1,165日

修正版はPHP公式の告知、終了日は公式サポート表に基づいています。残日数は本記事で独自に計算したもので、「終了日－2026年10月23日」の日付差です。当日は数えていません。［6］

PHP 8.2を使っている場合は、今回の修正状況を確認するとともに、年内の移行も準備する必要があります。8.2.35へ更新して今回の問題に対処しても、公式サポートの終了日は変わりません。

緊急対応のために、すべてのサイトをいきなり8.5へ変更する必要はありません。まず利用中の系列で修正を適用し、その後、テーマやプラグインの動作を確かめてから別の系列へ移行する方法があります。サーバー会社がバージョン変更は不要と案内している場合は、その案内を優先してください。

PHP 8.1以前は、通常の公式セキュリティサポートが終了しています。ただし今回は、PHP開発元が7.4・8.0・8.1向けにも、ソースコードに適用する最小限の修正を提供しました。旧系列への継続的なサポートが再開されたわけではありません。［1］

国内3サービスを比較——バージョン番号を変えずに修正する場合もある

「修正版と番号が違う」という理由だけで、未対応とは判断できません。国内サービスの公式告知では、通常の更新に加え、旧版への独自修正も案内されています。

サービス公式告知で確認できた対応運営者が確認すること
XServer for WordPress10月22日更新の告知で、PHP 5.6〜8.5の対象サーバーへの修正適用完了を案内。5.5以下の修正は作成・検証中契約サービスと利用中の系列が、対応完了とされた範囲に含まれるか
さくらのレンタルサーバ提供中のPHPに必要な修正を適用。提供中のサポート終了版も修正対象と説明レンタルサーバ向けの案内か、利用者がOSを管理するVPSなどに向けた案内か
ConoHa WING10月22日20時45分時点で対応完了。提供中の全PHPバージョンに、番号を変えずに修正を適用公式は利用者によるPHPバージョン変更は不要と案内。この案内をVPSにもそのまま当てはめない

出典：各サービスの公式告知。XServerについては、確認した告知が掲載されているXServer for WordPressを比較対象としています。他の契約サービスにも当てはまるかは、そのサービスの案内で確認してください。［7］［8］［9］

ConoHa WINGは、修正後も「8.5.11」など従来の番号が表示される場合があると説明しています。修正部分だけを取り込む「バックポート」という方法を使っているためです。［9］

ただし、別のサーバーで同じ番号が表示されていても、修正済みとは限りません。判断の根拠になるのは、自分が契約している環境を対象とした告知です。会社名に加えて、サービス名、対象系列、対応日時を照合しましょう。

WordPress運営者の確認手順——3つの記録を残す

本記事では、「対象の特定」「修正の確認」「動作の確認」の3つに分けて、対応状況を記録する方法を提案します。表示されるバージョン番号だけに頼らず、後から対応内容を確認できるようにするためです。

1．サイトとPHPの情報を記録する

WordPressの「ツール」→「サイトヘルス」→「情報」→「サーバー」で、PHPのバージョンを確認できます。ドメイン名、契約サービス名、確認日時も一緒に記録してください。この確認場所は、WordPress公式が案内しているものです。［2］

複数のサイトを運営している場合は、ドメインごとに確認します。公開中のサイトに加え、外部からアクセスできるテスト用サイトや旧サイトも対象です。同じ契約内でも、PHPの設定がそろっているとは限りません。

2．今回の2件に対する修正状況を確認する

サーバー会社が「対応済み」としている範囲に、自分の利用環境が含まれているかを確認します。不明な場合は、2つのCVE番号を添えて問い合わせると、別の脆弱性との取り違えを避けられます。

利用中のドメインは○○、契約サービスは○○です。CVE-2026-109618とCVE-2026-109619について、この環境のPHPへの修正適用は完了していますか。表示バージョンが変わらない場合、修正済みと確認できる告知と、利用者側で必要な操作を教えてください。

自分でOSを管理しているVPSや専用サーバーでは、OSやパッケージの提供元の案内も確認します。更新後は必要な再起動や再読み込みを行い、Webサイトの処理に使われるPHPへ修正が反映されたかを確かめてください。

3．更新後の動作を確かめる

トップページが表示されるかに加え、普段使っている操作を最後まで行えるかも確かめます。以下は、本記事で作成した確認表です。修正が適用されたことと、サイトが正常に動くことを、それぞれ記録できます。

確認項目記録する内容確認できること
対象の特定ドメイン、契約サービス、Webサイトの処理に使うPHPの情報、確認日時どの環境を調べたか
修正の確認両CVEへの対応告知、対象範囲、適用日時または提供元の回答対象環境に今回の修正が適用されたか
動作の確認管理画面へのログイン、下書き保存、画像投稿、フォームの送受信など更新後も必要な機能を使えるか

問い合わせフォームは、送信完了の表示から通知メールの到着まで確認します。ネットショップなら、決済サービスのテスト機能などを使って、購入手続きの流れを点検します。ただし、これらが正常に動いても、過去に侵害されていないことまでは証明できません。

よくある誤解——プラグインやWAFだけでは修正できない

攻撃の入口を制限する対策と、PHPの欠陥を直す対策は、分けて考える必要があります。PHP公式は、設定変更による緩和策だけでは安全を確保できず、更新が必要だと説明しています。［1］

対策の例役立つ点今回の問題に対する限界
WordPressやプラグインを更新するそれぞれの不具合や脆弱性に対応できるサーバーのPHP自体が修正されたことの証明にはならない
セキュリティプラグインを入れるログイン保護や監視などに役立つプラグインが動く前のPHPの処理で、攻撃が成立する経路がある
WAFを有効にする対応ルールによって、特定の攻撃通信を遮断できる場合があるPHPへの修正適用の代わりにはならない
アップロード進捗機能を無効にする確認されている一部の攻撃経路を減らせる別の経路が残るため、2件への完全な対策にはならない

特に、セキュリティプラグインだけで防げると考えるのは危険です。PHP開発元は、mod_phpでアプリのコードが動く前に攻撃が成立する経路を示しています。WordPress側の処理だけで防ぐ方法には、仕組み上の限界があります。［3］

ネット上で紹介されているメモリ上限の撤廃なども、その設定だけをまねて済ませないでください。PHP公式の緩和策には、サーバー側での資源制限など、適用にあたっての条件があります。すぐに修正できない環境では、管理者や提供元と相談し、外部からのアクセス制限や一時停止を検討する必要があります。［10］

更新後に不具合が出たら——元に戻す前に、復元する範囲を確認する

復旧の際は、「記事や設定を戻す」のか、「PHPを含むサーバー全体を戻す」のかを区別してください。これは、今回の修正とバックアップの運用を踏まえた、本記事の実務上の提案です。

復旧方法の例確認すること
WordPressのファイルとデータベースを復元する復元内容に不審なファイルや設定が含まれていないか。PHP側の修正は維持されているか
VPS全体を古いスナップショットへ戻すPHPやOSも修正前の状態へ戻らないか。戻る場合は、外部公開前に修正を再適用する
PHPを以前の系列へ戻す戻した先のPHPも、今回の2件に対応済みか

例えば、PHPの系列を変更した後に、古いテーマが動かなくなったとします。元の系列へ戻す場合も、戻した先のPHPに修正が適用されているかを確認してください。「以前は表示できた」というだけでは、公開を再開してよいとは判断できません。

変更前には、ファイルとデータベースのバックアップを保管してください。ただし、すでに侵害されていた場合は、不正な内容まで保存される可能性があります。バックアップがあることと、安全に復元できることは、分けて確認する必要があります。

なぜ今になって修正されたのか——2024年の調査から残った課題

PHP Foundationは、メモリ不足に関する問題の兆候を2024年に把握していたと説明しています。当時は具体的な攻撃経路が見つからず、修正にあたっても互換性などの難しい問題がありました。同団体は、対応が遅れた背景に、意思決定の問題と人員不足があったと認めています。［11］

その後、2026年の調査で、実際にコード実行に至る経路が報告されました。AIを使った調査や検証も行われています。ただし、この説明を「今回の2件を2024年の時点ですべて把握していた」と解釈するのは正確ではありません。［11］

運営者としては、これまで被害が見えていなかったことを、安全の根拠にしないようにしたいところです。今回の問題では、サイトの知名度やアクセス数で危険性を判断するより、外部からアクセスできる環境のPHPが修正済みかを先に確認する方が、対応に直結します。

修正済みでも、侵害の有無は別に確認する必要がある

PHPを更新しても、更新前に置かれた不正なファイルが自動で消えるわけではありません。JPCERT/CCも、対策を適用するとともに、侵害の有無を調べるよう呼びかけています。［5］

同センターは、不審な通信の前後に発生したメモリエラー、PHP処理の異常終了、不自然なCookieなどを確認項目に挙げています。ただし、痕跡が見つからなくても、攻撃されていないとは断定できないとしています。［5］

個人でWordPressを運営している場合は、見覚えのない管理者アカウント、新しいPHPファイル、不審な転送などに気づいたら、サーバー会社や保守担当者へ連絡してください。調査前にログを消したり、全体を上書きしたりせず、証拠を残しておくことが大切です。

予防のためにサービスが停止したという事実だけで、情報漏えいが起きたとは判断できません。さくらインターネットは、10月22日14時時点で、同社の調査では、悪用による不正アクセスや情報漏えいなどの被害は報告されていないと説明しています。ただし、これはその時点の調査範囲についての説明です。［8］

まとめ——まずは契約先の対応状況を確認する

「利用環境を特定する」「2件に対する修正状況を確認する」「更新後の動作と侵害の兆候を点検する」の順に進めてください。対応済みのサーバーでは、表示されるバージョン番号だけを理由に、慌てて設定を変更する必要はありません。

  • WordPress本体を更新しただけでは、今回のPHPの問題に対処したことにはなりません。
  • 修正版と番号が違っていても、提供元の独自修正が適用されている場合があります。
  • PHP 8.2の公式サポートは2026年末までです。今回の対応とは別に、移行も準備してください。
  • 複数のサイトやテスト環境も確認し、対象・修正・動作の記録を残してください。

関連ページ

さらに確認する際は、契約サービスの最新告知とWordPress公式の案内を参照してください。

出典・参考資料

脆弱性と各サービスの対応に関する事実関係は、以下の一次情報で確認しています。残日数の計算、3つの確認項目に分けた記録表、復旧方法別の確認表は、本記事で作成したものです。

  1. PHP公式：Security advisory: Critical remote code execution vulnerabilities, update now／2026年のリリース情報
  2. WordPress公式：Critical PHP Security Release
  3. PHP開発元：RCE via OOM corruption
  4. PHP開発元：RCE via stale global state
  5. JPCERT/CC：PHPにおける複数の脆弱性に関する注意喚起
  6. PHP公式：Supported Versions
  7. XServer for WordPress：予防的な安全対策に伴う公式サイト・管理画面等の一時停止のお知らせ
  8. さくらインターネット：PHPの脆弱性に関する当社の対応状況について
  9. ConoHa WING：PHPの脆弱性への弊社対応完了のお知らせ（終報）
  10. ENISA：Joint statement on critical PHP vulnerabilities
  11. PHP Foundation：Today’s PHP Security Release, and How We’re Strengthening PHP Security

タグ

Related Posts

コメントを送信

You May Have Missed