【緊急コラム】PHP脆弱性への対応、確認すべきことと判断基準は？2026年10月の修正版公開で何をすべきか

---

2026年10月22日時点の情報です。2026年10月21日、PHPの開発元は重大な脆弱性2件と、その修正版を公表しました。

この記事では、エンジニアではない事業責任者・Web担当者が、自社のサイトについて「誰に何を確認し、どんな返事を受け取れば対応済みと判断できるか」を整理します。

---

修正版への更新が、今回の脆弱性への完全な対策

2件の脆弱性と修正版の公開日

2026年10月21日、PHPの開発元であるThe PHP Group（php.net）は、PHPの脆弱性2件についてセキュリティ情報を公開し、同日に修正版を公開しました。

今回の修正版と、系列ごとのセキュリティサポート終了日は次のとおりです（The PHP Group「News Archive 2026」「Supported Versions」より）。

PHP系列	今回の修正版	セキュリティサポート終了日	やること
8.5	8.5.12	2029年12月31日	修正版への更新
8.4	8.4.27	2028年12月31日	修正版への更新
8.3	8.3.36	2027年12月31日	修正版への更新
8.2	8.2.35	2026年12月31日	修正版への更新＋年内に系列の移行を決める
8.1以前	開発元からの修正版なし	終了済み	提供元の修正の有無を確認し、8.3以上の系列への移行を最優先

CVE番号はCVE-2026-109618・CVE-2026-109619の2件です。深刻度はどちらもCVSS v4.0で9.2と評価されており、PHPの開発元はすべての利用者に、ただちに修正版へ更新するよう呼びかけています。

更新以外の措置は、安全にはしない

PHPの公式サイトの告知は、すぐに更新できない場合の設定変更などの措置について、特定の攻撃経路を減らすだけで安全にはしない、と明記しています。完全な対策は修正版への更新だけです。

すぐに更新できない事情がある場合の措置は、公式の告知をもとに保守担当が判断します。「設定で制限しているから大丈夫」と判断して更新を後回しにせず、修正版への更新を最優先にしてください。

---

PHPを誰が管理しているかで、確認する相手が変わる

事業責任者として最初に確認するのは、「自社のPHPを誰が更新するか」です。これによって、確認する相手と、何を受け取れば「対応済み」と判断できるかが決まります。

PHPの入れ方	誰が更新するか	受け取る根拠	注意点
レンタルサーバー	サーバー事業者	今回のCVEへの対応完了の告知と、その対象のプラン・PHPの系列	「PHP 8.4に対応」など系列だけの記載では判断できない
保守会社が管理するサーバー	保守会社	Webで動いているPHPの版・当てた修正・反映と稼働確認の日時	「対応しました」の一言だけで済ませない
自社で管理するサーバー	自社の保守担当	Webで動いているPHPの版・当てた修正・反映と稼働確認の日時	OSの標準パッケージは版番号が変わらないまま修正が入ることがある

レンタルサーバーの場合——事業者の告知を確認する

レンタルサーバーでは、PHPの更新は事業者が行います。利用者側の作業は、事業者の告知を確認することです。

確認するのは、今回の脆弱性（CVE-2026-109618・CVE-2026-109619）への対応が完了したという記載と、その対象に自社のプランとPHPの系列が含まれているかです。「PHP 8.4に対応」という系列だけの記載では判断できません。

保守会社が管理する場合——保守会社に確認する

保守契約がある場合、修正版への更新は保守会社が行います。しかし「対応しました」という一言の返事だけでは、本当に対応済みかどうかを判断する根拠が手元に残りません。

保守会社から受け取るのは、Webで動いているPHPの版、当てた修正（修正版の番号、または提供元の修正パッケージ）、反映と稼働確認の日時です。これらが揃って初めて、いつ・何を・どのように対応したかが記録として機能します。

自社で管理する場合——自社の保守担当に確認する

自社でサーバーを管理している場合は、自社の保守担当が修正版への更新を行います。注意点が一つあります。OSの標準パッケージで入れたPHPは、OSの提供元が修正を配ります。この場合、PHPの版番号が変わらないまま修正だけが適用されることがあり、版番号だけを見て「未対応」と誤って判断してしまいます。

自社の保守担当からも、Webで動いているPHPの版、当てた修正、反映と稼働確認の日時を受け取ってください。

---

「対応済み」の返事で受け取る根拠

担当者や保守会社から「対応しました」と連絡が来たとき、何を確認すれば「済んだ」と判断できるのか。この基準があいまいなまま承認してしまうと、後になって「実はWebで動いているPHPは古いままだった」という事態が起こりえます。

修正番号まで確認する——系列だけでは不十分

「PHP 8.4に更新しました」という返事は、系列の確認に過ぎません。今回の脆弱性への対応を確認するには、修正版の番号（例：PHP 8.4.27）まで確かめる必要があります。

ただし、OSの標準パッケージを使っている環境では、版番号が変わらないまま修正が適用されることがあります。「番号が変わっていないから未対応」という判断は誤りになりえます。番号だけで判定せず、「当てた修正の内容」もあわせて受け取ってください。

Webで動いているPHPの版を確認する

「サーバーに入っているPHPの版」と「Webのリクエストを実際に処理しているPHPの版」は、異なることがあります。修正版を入れても反映が終わっていなければ、Webのリクエストは古いPHPで処理され続けます。

保守担当には、「Webで動いているPHPが修正版になっていること」を確認したかどうかを尋ねてください。

反映と稼働確認の日時を受け取る

修正版を当てた日時、再起動などの反映作業を終えた日時、稼働を確認した日時を受け取ることで、「いつの時点で対応済みか」が明確になります。

これは将来の対応においても重要な記録になります。「〇月〇日〇時に修正版（または提供元の修正パッケージ）を適用し、同日〇時に稼働を確認」という形で受け取ることを習慣にしてください。

---

本サイト以外も棚卸しする——LPや旧サイトも対象

本サイトの対応を終えたのに、別のドメインで動いているLPが古いままだった——サイトやページを複数持つ事業者ほど、こうした取りこぼしが起こりえます。

LPや特設サイトは別の場所で動いていることがある

商品LP、キャンペーンサイト、採用LP、期間限定の特設サイトなどが、本サイトとは別のサーバーで動いていることがあります。

本サイトのPHPを修正版に更新しても、別のサーバーで動いているLPや特設サイトには、その更新は及びません。IPAも、可能な範囲で、PHPを利用しているプログラムを棚卸しするよう呼びかけています（IPA「【事前準備のお願い】PHPのセキュリティリリース公開予定について」）。

まず「自社が公開しているWebサイト・ページの一覧」を書き出すことが、棚卸しの起点になります。

旧サイト・検証環境も確認対象に含める

リニューアル前の旧サイト、テスト用の検証環境、開発中のステージング環境も、外部からアクセスできる状態で公開されていて、PHPで動いているなら確認の対象です。

「本番ではないから後回し」にせず、公開されているものは棚卸しに含めてください。使っていないサイトが見つかった場合は、公開を続けるかどうかも保守担当とあわせて決めます。

---

8.2を使っているサイトが抱える「二重期限」とは

PHP 8.2を使っているサイトでは、今回の対応に特有の状況が生じています。この記事では、この状況を「二重期限」と呼びます。

二重期限の定義——修正版への更新と系列の移行

二重期限とは、PHPの修正版への更新（今回の脆弱性への対応）と、使っている系列のサポート終了日までの系列の移行という、締め切りの違う2つの対応を同時に抱えている状態のことです。

1. 今回の脆弱性への対応：修正版（PHP 8.2.35）への更新。今すぐ行う対応です。
2. 系列の移行：PHP 8.2のセキュリティサポートは2026年12月31日で終了します（The PHP Group「Supported Versions」より）。年内に移行先の系列を決め、段取りを組む対応です。

2つの対応は、やることも締め切りも異なります。これを混同したまま保守担当に任せると、どちらかが漏れるおそれがあります。

8.2は年内に系列の移行を決める必要がある

PHPの系列ごとのサポート期間は、通常サポート2年＋セキュリティ修正のみ2年の計4年です（The PHP Group「Supported Versions」より）。PHP 8.2はこの期間が2026年12月31日で終わります。

この日以降、8.2に新たな脆弱性が見つかっても、開発元からの修正版は出ません。

EC事業者にとって、年末は繁忙期にあたります。サイトの変更や検証の時間を取りにくい時期に系列の移行が重ならないよう、今回の修正版への更新を依頼する連絡の中で、系列の移行の日程まで保守担当と決めておくことを勧めます。

8.3〜8.5は今回は修正版への更新だけ

PHP 8.3・8.4・8.5のセキュリティサポートの期限は次のとおりです（The PHP Group「Supported Versions」より）。

• PHP 8.3：2027年12月31日まで
• PHP 8.4：2028年12月31日まで
• PHP 8.5：2029年12月31日まで

これらの系列を使っているサイトは、今回は修正版への更新（8.3.36・8.4.27・8.5.12）で対応が完了します。系列の移行を急ぐ必要はありません。

---

8.1以前のサイトは、系列の移行が最優先

8.1以前は開発元から修正版が出ない

PHP 8.1以前は、PHPの開発元から修正版（更新リリース）が出ません。PHPの公式サイトの告知は、8.1以前の利用者に対し、OSや長期サポートの提供元が修正を配っている場合があるため提供元に確認するか、サポート中の系列へ移行するよう求めています（The PHP Group「News Archive 2026」より）。

サポート中の系列への移行を最優先にする

8.1以前のサイトでは、提供元の修正の有無を確認したうえで、サポート中の系列への移行を最優先にします。移行先は、2026年12月31日にサポートが終わる8.2ではなく、8.3以上の系列で保守担当と検討してください。

ただし、系列を上げると、WordPressのプラグイン・テーマ、問い合わせフォーム、ECカートなどが動かなくなることがあります。「とりあえず上げよう」と指示を出す前に、保守担当と次の段取りを確認してください。

• 使っているプラグイン・テーマ・スクリプトの動作確認
• 検証環境での事前テスト
• 本番への反映のタイミングと、元に戻す手順

段取りを決めてから進めることが、移行後に「サイトが動かない」という事態を防ぎます。

---

修正版の適用と侵入の有無は別の確認

修正版は今後の攻撃を防ぐもの

修正版への更新は、今後の攻撃を防ぐための対応です。「修正版を適用する前に、すでに侵入されていないか」は、それとは別の問いです。

鍵を新しいものに替えても、すでに入り込んだ人を外に出すことにはならないように、修正版への更新は「これから先の攻撃への備え」であって、「適用前の状態の安全性」を保証するものではありません。

不審な点があればログを消さずに相談する

身に覚えのないコンテンツの変更、管理画面の異常、身に覚えのないメールの送信など、サイトの動作に不審な点に気づくことがあるかもしれません。

不審な点に気づいた場合は、自己判断でファイルやログを削除せず、現状を残したまま保守担当へ相談してください。侵入の有無の確認は、修正版の適用とは別の作業として依頼します。

自己判断で「大丈夫そう」と結論づけず、保守担当に確認を依頼してください。

---

次の緊急情報を見落とさない仕組みづくり

今回の対応が終わっても、次の緊急情報は届きます。情報を受け取る入口と、それを見る人を、事業側も関わって決めておくことが重要です。

PHPの公式サイトの告知を確認する

The PHP Group（php.net）の「News Archive」では、PHPのセキュリティリリースの情報が公開されます。今回の修正版もここで公表されました（The PHP Group「News Archive 2026」）。

また「Supported Versions」のページでは、各系列のサポート期限を確認できます（The PHP Group「Supported Versions」）。このページを保守担当と共有し、使っている系列のサポート終了日を組織の共有カレンダーに登録しておくことを勧めます。

IPAの重要なセキュリティ情報を受け取る

IPA（独立行政法人情報処理推進機構）は、今回のセキュリティリリースの公開に先立ち、事前準備を呼びかける告知を出していました（IPA「【事前準備のお願い】PHPのセキュリティリリース公開予定について」）。

IPAは2024年7月にも、PHPの脆弱性を狙う攻撃について注意喚起を出しています（IPA「PHPの脆弱性（CVE-2024-4577）を狙う攻撃について」）。IPAの重要なセキュリティ情報は、技術者だけでなく事業側の担当者も受け取れる入口として使えます。

情報を見る人を決めておく

緊急情報が届いたときに、誰が最初に見て、誰に伝えて、誰が判断するかが決まっていないと、情報は届いていても対応の起点が生まれません。

脆弱性の情報を最初に受け取る人、事業側に伝える相手、対応を承認する人を、あらかじめ文書で決めておくことを勧めます。次の緊急情報が届いたときの動き出しが変わります。

---

PHP脆弱性対応でよくある質問

レンタルサーバーを使っているなら、こちらで何かする必要はあるか？

レンタルサーバーでは、PHPの更新は事業者が行います。利用者側の作業は、事業者の告知を確認することです。今回の脆弱性（CVE-2026-109618・CVE-2026-109619）への対応が完了したという記載と、その対象に自社のプランとPHPの系列が含まれているかを確認してください。

---

WordPressやプラグインを最新にしていれば大丈夫か？

いいえ。今回の脆弱性はPHP本体の問題です。WordPress本体やプラグイン・テーマを更新しても、PHP本体を修正版に更新しなければ対応にはなりません。

---

管理画面に「PHP 8.4」と出ていれば対応済みか？

いいえ。系列（例：8.4）だけでなく、修正番号（例：8.4.27）まで確認する必要があります。また、OSの標準パッケージでPHPを入れている場合は、版番号が変わらないまま修正が入ることがあるため、番号だけで判定しないでください。保守担当から、当てた修正と、反映・稼働確認の日時を受け取ってください。

---

8.1以前のまま使っているとどうなるか？

PHP 8.1以前は、PHPの開発元から修正版が出ません。OSや長期サポートの提供元が修正を配っている場合があるため、まず提供元に確認してください。そのうえで、サポート中の系列への移行が最優先です。移行先は、2026年12月31日にサポートが終わる8.2ではなく、8.3以上の系列で検討してください。系列を上げるとプラグイン・テーマ・フォームが動かなくなることがあるため、保守担当と確認の段取りを決めてから進めます。

---

修正版にすれば、侵入の心配はなくなるか？

修正版への更新は、今後の攻撃を防ぐためのものです。適用前に侵入されていないかの確認は別の作業です。不審な点があれば、ファイルやログを消さずに保守担当へ相談してください。

---

無料で改善を相談する

発注側と制作側の両方を見てきた立場から

「保守会社から返事が来たけれど、これで対応済みと判断していいのか自信がない」——何を聞けばいいか分からないまま承認してしまうことは、Web担当者にとって身近な悩みです。

発注側として「受け取るべき返事の粒度」を知っているかどうかで、確認の精度は変わります。技術的な内容を自分で理解できなくても、確認の問いを正しく立てられれば状況は変わります。

LP・Webサイトの改善についてのご相談は、下のお問い合わせから受け付けています。

今のLPが「どこで・なぜ」成果を落としているのか。その一点を一緒に見るところから始めます。