WordPressを動かすPHPの脆弱性—古いバージョンを放置しないための期限と担当の管理

2026年10月21日、PHPの開発元が重大な脆弱性2件を修正したバージョンを公開しました。WordPressはPHPの上で動くため、サイトを預かる側にはWordPress本体の更新とは別に、PHPのバージョンと期限を見る仕事が残ります。本稿の確認時点（2026年10月28日）では、米国のCISAがこの2件を悪用が確認された脆弱性として登録・公表し、IPAとJPCERT/CCも注意喚起に追記しています。本記事ではその経緯を日付ごとに整理したうえで、「期限を誰の予定に入れるか」「対応が終わらないとき誰に引き継ぐか」「次の告知をどう追うか」を論点として整理します。使用中のバージョンの確かめ方と、PHPをアップデートする手順は、それぞれ別の記事で詳しく解説しています。

最初に確かめるのは、どの日に何が起きたかです。修正の公開、注意喚起の公開、悪用の確認、注意喚起への追記は、一度に起きた出来事ではありません。まとめて「10月の脆弱性」と呼ぶと順序が見えなくなるため、日付を分けて並べます。

10月21日、PHP 8.5.12、8.4.27、8.3.36、8.2.35が公開されました。修正されたのは、重大とされる2件の脆弱性（CVE-2026-109618、CVE-2026-109619）です。開発元の告知では、どちらも深刻度の評価（CVSS v4.0）は9.2とされています。影響を受けるのは、Webのリクエストを処理するPHPの環境すべてです。PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedが例に挙がり、開発元は、危険が最も高いのはmod_phpだとみています。

10月22日には、IPAが注意喚起を公開し、JPCERT/CCも注意喚起（JPCERT-AT-2026-0033）を公開しました。2つの機関が扱っているのは同じ2件で、別々の脆弱性ではありません。

動きがあったのは、その後の10月26日と27日です。10月26日（現地時間）、この2件は米国CISAのKEVカタログに「悪用された脆弱性」として掲載された、とIPAは記しています。同じ26日、JPCERT/CCは注意喚起に追記し、悪用できると主張する実証コードが多数公開されていること、悪用を試みる通信を観測したとの報告が相次いでいることを記しています。ただし、実証コードで実際に任意のコードを実行できるかどうかは、PHPのバージョン、実行環境、メモリ配置などの条件によるとも書いています。10月27日には、IPAが追記を加え、CISAの掲載を伝えました。

では、この「悪用の確認」は何を意味するのでしょうか。国内の被害や、自社のサイトが侵害されたことを意味するわけではありません。IPAは追記の中で「国内での攻撃被害の事例については把握しておりません」と明記しています。そのうえで両機関とも、修正済みのバージョンへの移行を求めています。JPCERT/CCは更新に加えて、侵害の有無の調査も推奨しています。

以上が本稿の確認時点（2026年10月28日）の状態です。IPAのページは、追記すべき情報があればその都度更新するとしており、この先も追記が続く可能性があります。

今回の対象はPHPであり、WordPress本体ではありません。本体を最新にしていても、PHPが修正済みのバージョンより前（8.5系なら8.5.12より前）のままであれば、今回の対象に入ります。逆に、本体を更新してもPHPのバージョンは上がりません。PHPのバージョンを決めているのは、サーバー側の設定です。

PHPを組み込んだ製品や、Linuxディストリビューションが配布するPHPも、影響を受けうるとされています。その場合は、製品や配布元が出す情報もあわせて確認することになります。

WordPress本体・部品の脆弱性情報を読む方法については、別の記事で解説しています。自サイトのPHPのバージョンは、次の章の冒頭で確かめます。

PHPをアップデートする作業と、サポートの終了日に備える作業は、一つの管理の中で扱います。ここで決めるのは、日付を誰の予定に入れるか、確認の結果を誰が受け取るか、終わらなかった作業をどこへ引き継ぐかの3点です。

管理の出発点は、使用中のバージョンと、そのバージョンのサポートの状態です。通常のサポートの終了日とセキュリティ修正の終了日は、別々の日付として示されています。この確認ができて初めて、期限を誰が管理するかが決まります。使用中のPHPバージョンと現在の状態の読み方は、別の記事にまとめています。サイトヘルスを開けない場合のPHPの代替確認についても、別の記事で紹介しています。

PHPの公式ページにある終了日は、そのままでは誰の予定にも入っていない日付です。本稿の確認時点（2026年10月28日）で、同ページの表にある8.2〜8.5の終了日は次のとおりです。

2026年12月31日には8.2のセキュリティ修正の終了と、8.4の通常サポートの終了が重なります。同じ日付でも意味は別です。

この日付を管理に載せるには、次の順に決めます。

ここで混同してはならないのが、確認の予定と対応の完了です。予定が入ったことは「確認する日が決まった」という報告であり、「アップデートした」という報告ではありません。報告を受ける側の記録でも、確認した日・バージョン・終了日・担当・次の確認日の欄と、未完了の事項の欄を分けておきます。

次にPHPのバージョンを確かめる時期と、そのきっかけの考え方については、バージョンの読み方を扱う記事で取り上げています。

PHPのバージョンはサーバーの設定の中にあり、サイトの表示はサイト側のテーマやプラグインに左右されます。一つの対応に、サーバー会社、保守会社、制作会社、自社のうち複数が関わる場合があります。

役割は3つに分けて確かめます。確認（バージョンと期限を誰が見るか）、作業（PHPのアップデートを誰が行うか）、完了報告の確認（完了の報告を誰が受け取り、記録するか）です。

契約書やサービスの説明で確かめる項目は、たとえば次のとおりです。

契約ごとに答えは違います。サーバー会社がPHPのバージョンを管理する契約もあれば、利用者が設定画面で自分で変える契約もあります。保守会社への依頼にPHPが含まれるかどうかも、契約を見るまで分かりません。誰が何を担うのか、一律には決められません。

決まらない項目が出た場合に最も避けたいのは、その状態のまま期限を迎えることです。PHPに限らず保守を自社で担うかの判断については、別の記事で詳しく説明しています。

依頼したのに返事がありません。作業が始まったと連絡を受けたのに、完了の報告が届きません。この2つは、止まっている段階が違います。前者は返答の段階で、後者は作業の段階で止まっています。では、どの時点で次の担当へ引き継ぐのでしょうか。管理の表では、状態を次のように分けておきます。

どの時点で引き継ぐかは、この状態から決まります。返答がなければ、依頼元が次に連絡する先（社内の責任者、別の契約先）を、依頼の時点で決めておきます。作業が止まっていれば、サポートの終了日までの残りの期間を確かめ、期限までに終わらない場合の相談先へ引き継ぎます。返答がないことそのものも、記録に残します。

回答の期限や受け持つ範囲は、契約ごとに異なります。日数は体制によっても異なるため、本記事では一律の日数を示しません。自社の契約に合わせて決める項目です。

使用中のPHPが古く、すぐにアップデートできない場合にも、残る作業があります。ここでは、古いバージョン向けの提供物と、通常の更新を分けて整理します。

PHP 8.1以前のバージョンは、PHPの開発元から更新が提供されません。開発元は告知の中で、一部のディストリビューションや長期サポート（LTS）を提供する事業者が修正を移植して提供している場合があるため、事業者に問い合わせるか、サポートされるバージョンへアップデートするよう案内しています。

一方で、開発元は脆弱性の深刻さを考え、PHP 7.4、8.0、8.1向けに最小限の修正プログラム（minimal source-backports）を出しました。告知には、その目的は、ソースからビルドする人や、長期サポートを提供する事業者を利用できない人を支援することだと書かれています。JPCERT/CCは、これを「最小限の緩和策」と表記しています。

通常の更新と最小限の修正プログラムは、別のものです。通常の更新は、開発元のサポート期間内にあるバージョンにだけ提供されます。最小限の修正プログラムはサポート外のバージョンへの例外的な提供であり、サーバーの管理画面で選べるPHPのバージョンがこれで修正されたかどうかは、告知の文面からは分かりません。自社のサーバーのバージョンがどう扱われているかは、サーバー会社や保守会社に確かめる事柄です。

この提供があることは、古いバージョンを使い続けてよいという判断の根拠にはなりません。必要なのは、サポート期間内のバージョンへの移行の検討です。

更新できない場合の緩和策について、開発元は、完全な対策は更新だけであり、緩和策は特定の攻撃経路への露出を減らすにとどまる、としています。インストールを安全にするものではない、とも明記しています。本稿の確認時点（2026年10月28日）では、2件について悪用の確認があるため、緩和策のまま長く置かない前提で管理を組むことになります。

更新できない理由は、その時点で具体的に記録します。テーマやプラグインが新しいPHPに対応していない、アップデートを行う人がいない、元に戻せる状態を用意できない、といった理由が挙がります。そのうえで、解消を担う人、アップデートを行う予定日、再確認の予定を、表に並べます。緩和策を入れた場合は、誰がいつ入れたかも同じ表に書き、更新の予定日と並べて見えるようにします。設定の具体的な手順は、この記事では扱いません。

アップデートの準備、実施、問題が出たときの戻し方は、別の記事の一回のPHPアップデートと問題が出た場合の戻し方で詳しく取り上げています。

10月21日の2件とは別に、10月23日、PHPの開発元はCVE-2026-115560に関する告知（セッションのアップロード進捗に関するもの）を出しました。まれな設定とアプリケーションのコードの組み合わせでだけ起きる、とされています。この告知は、10月21日の2件とは別件として扱います。

開発元は、通常のリリースの周期で扱い、次のリリースで詳細な脆弱性情報を公開する、と述べています。JPCERT/CC（10月26日の追記）は、これを「通常のリリースサイクルで修正する方針」と言い換えています。どのバージョンでいつ修正されるかは、原文に書かれていません。本稿の確認時点（2026年10月28日）では、米国の脆弱性データベース（NVD）に未登録で、詳細な脆弱性情報も未公開です。「次の定期更新で修正される」と読み取れる書き方は、避けるのが安全です。

それまでの間、開発元は、次の通常の不具合修正リリースまで、この機能を無効にする設定を推奨しています。10月21日に出たCVE-2026-109619の脆弱性情報にも同じ設定が緩和策として載っており、その時点で入れた場合は追加の作業は要らない、とも書いています。設定の中身は、開発元の告知で確かめてください。

管理の面では、2件への対応の記録と、この別の告知の追跡を、別の管理項目として扱います。追う先は、PHP開発元の告知、NVD、JPCERT/CCの3つです。詳細な脆弱性情報が出たかを見る担当を決め、出たときに誰へ知らせるかも、あらかじめ決めておきます。

期限は、バージョンの終了日を確認する担当が管理します。未完了の事項は、依頼先を決めた引き継ぎの表に記録します。別の告知は、追う先と知らせを受け取る担当を決めた管理項目として追います。この3つを分けておけば、公表が重なっても混ざりません。期限の管理、担当の整理、未完了の引き継ぎまで一緒に整えたい場合は、PHPのアップデートにも対応するWordPress保守の相談をご覧ください。

本記事は、ビークリエイトのWordPress保守チームの知見をもとに構成しています。詳しくは会社概要をご覧ください。