Web サイトや商用サービスあるいは業務システムにとって、 ソフトウェアのサポート期限は技術部門だけの問題ではありません 。未修正の脆弱性 (ぜいじゃくせい) の放置は、事業停止・顧客の信頼・予算に直結する、経営・管理上の課題です。
本記事では、PHP を題材に、そのサポート切れがなぜ経営上のリスクになるのか、実際の脆弱性悪用事例から何を学ぶべきかを整理します。それから経営陣・管理者層と現場のエンジニアが、何を確認すべきかを記載します。
PHP はサーバーアプリエンジンの代表的なものの一つです。今回はこちらを題材にしています。しかしながら、他のソフトウェアやインフラについても、同様の注意と配慮、さらには実践的な取組みが必要です。
要点: まず経営陣・管理者層が押さえるべきこと
| 要点 | 組織にとっての意味 | まず確認すること |
|---|---|---|
| サポート終了は、ただちに停止するという意味ではない | 動作し続けていても、今後の修正が提供されない可能性がある | PHP のバージョンと公式サポート期限 |
| サポート中でも修正前なら危険がある | PHP2shell のような重大な脆弱性には、サポート中のバージョンでも緊急対応が必要 | PHP2shell の影響有無と修正バージョン |
| 更新はエンジニアだけでは完結しない | 試験、業務調整、予算、委託先との責任分担が必要 | 責任者、期限、予算、切り替え判断権限 |
| 「今まで被害がない」は安全の証明にならない | 未把握のシステムや未検知の侵害が残っている可能性がある | 管理対象の棚卸しと、ログ・復旧手順の確認 |
背景: PHP2shell とサポート切れをめぐる状況
2026 年 10 月、PHP に関する 2 件の重大な脆弱性が公表され、組合せて「PHP2shell」と呼ばれています。悪用された場合、認証されていない第三者が遠隔から任意のコードを実行する可能性があります。PHP 開発チームは修正版を公開し、速やかな更新を強く推奨しました。さらに、2026 年 10 月 26 日には、米国の公的サイバーセキュリティ機関である CISA (Cybersecurity and Infrastructure Security Agency) が、この 2 件を「実際に悪用された脆弱性」のカタログに追加しました。[1][2]
一方、日本の公的な情報セキュリティ専門機関である IPA (情報処理推進機構) は、2026 年 10 月 27 日時点で日本における PHP2shell の攻撃被害を把握していないとしつつ、対策済みバージョンへの移行を呼びかけています。「日本で 被害が確認されていない 」ことは、 「危険がない」ことを意味しません。 [2]
PHP2shell は、サポート切れのバージョンだけの問題でもありません。サポート中のバージョンでも修正前のリリースを使用していれば影響を受ける可能性があります。
一方、サポートが終了したバージョンでは、新たな脆弱性が発見されても、PHP 開発チームから修正プログラムが提供されない場合があります。そのため組織は、サポート対象のリリースへ移行するか、あるいは利用しているオペレーティングシステムやホスティングプロバイダーが独自に保守しているパッケージを提供しているか、またそのサポート範囲がどこまで及ぶのかを確認する必要があります。
1. 放置された古いバージョンが抱えるリスク
PHP (あるいは一般的なソフトウェア) では、すべてのバージョンが無期限に保守されるわけではありません。PHP 開発チームは、各リリース系列について一定期間の通常サポートとセキュリティサポートを提供し、その期間が終わるとサポート終了（End of Life、EOL）として扱います。サポート終了後もシステムが急に動かなくなるわけではありません。むしろ、従来どおり動いて見えるために、問題が表面化しないまま使われ続けることがあります。[4]
PHP のサポート状況を確認する
2026 年 10 月 28 日時点の PHP 公式情報では、PHP 8.2〜8.5がサポート対象です。ただし、PHP 8.2 系のセキュリティサポートは 2026 年 12 月 31 日に終了する予定です。サポート対象の系列を使っていても、期限が迫っていないかを確認する必要があります。
| PHP 系列 | 公式サポート終了日 | 2026 年 10 月 28 日時点の見方 |
|---|---|---|
| PHP 5.6 | 2018 年 12 月 31 日 | サポート終了 |
| PHP 7.4 | 2022 年 11 月 28 日 | サポート終了 |
| PHP 8.0 | 2023 年 11 月 26 日 | サポート終了 |
| PHP 8.1 | 2025 年 12 月 31 日 | サポート終了 |
| PHP 8.2 | 2026 年 12 月 31 日 | セキュリティサポート終了が目前 |
| PHP 8.3 | 2027 年 12 月 31 日 | サポート中。次の移行計画が必要 |
| PHP 8.4 | 2028 年 12 月 31 日 | サポート中 |
| PHP 8.5 | 2029 年 12 月 31 日 | サポート中 |
出典: PHP 公式「Supported Versions」「Unsupported Branches」[4][5]。利用している OS ディストリビューションやホスティング事業者が独自の延長サポートを提供している場合は、その適用条件と責任範囲も別途確認してください。
サポート終了したバージョンを使い続ける主なリスクは、次のように整理できます。
| リスク | 何が起こり得るか | 経営・管理上の影響 |
|---|---|---|
| 修正プログラムが提供されない | 新たな脆弱性が判明しても、公式修正を入手できない場合がある | 既知のリスクを抱えたまま運用を続けることになる |
| 既知の弱点を狙われる | 攻撃者が公開情報や自動スキャンを使って、脆弱な環境を探す可能性がある | Web サイト改ざん、情報漏えい、業務停止などの被害につながり得る |
| 周辺ソフトウェアも更新しにくい | PHP 本体が古いため、CMS・フレームワーク・プラグイン・ライブラリの更新が難しくなることがある | 移行費用や保守作業が増え、選択肢が狭まる |
| 保守体制が失われる | 設計資料や担当者がいない、委託先との契約が終わっているなどの事情が重なる | 更新に要する時間と費用がさらに増える |
古いバージョンについて「脆弱性が何件あるか」だけを数えても、リスクを十分に評価できません。件数はデータベースの集計方法や対象範囲によって変わります。経営上重要なのは、現在のシステムがサポートを受けているか、修正版を適用できるか、そして継続的に保守する体制があるかです。
なぜ古い PHP が放置されやすいのか
システムは、動いている間は問題が見えにくいものです。特に、何年も変更されていない Web サイトでは、「止めると困る」「更新すると壊れるかもしれない」「担当者がいない」といった理由で、更新が先送りされがちです。しかし、先送りはリスクを消すのではなく、移行しなければならない時点まで課題を積み上げることがあります。
【リスクの流れ】
[PHP のサポート終了]
│
▼
[公式修正を受けられない可能性]
│
▼
[脆弱性が残る・周辺部品も更新しにくい]
│
▼
[侵害・停止・復旧長期化のリスク]
この図は、サポート終了が必ず侵害を引き起こすという意味ではありません。サポート終了により修正の選択肢が狭まり、リスク管理が難しくなる流れを示しています。次の図は、組織が取るべき対応を示しています。
【対策のフロー】
[資産の棚卸しと移行計画]
│
▼
[責任者・予算・期限を決定]
│
▼
[サポート対象へ移行し、継続保守]
│
▼
[残余リスクを定期確認]
2. 実際の事例から見る PHP の脆弱性対応
事例 1: CVE-2024-4577 を悪用したWebシェル設置
2024 年、日本の公的な情報セキュリティ専門機関は、PHP の脆弱性 CVE-2024-4577 を悪用した攻撃による被害を確認したと公表しました。発表によると、日本の複数組織でこの脆弱性が悪用され、PHP が稼働する Web サービスに Web シェルが設置されていたとの情報がありました。
Web シェルとは、攻撃者が侵入したサーバーを遠隔から操作するために設置する不正なプログラムです。設置された場合、追加の操作や組織内の別システムへの侵入、他組織への攻撃を中継する足場になる可能性があります。Web サイトの改ざんや情報窃取だけでなく、被害が当初の Web サイトにとどまらないおそれもあります。
この事例は「古い PHP なら必ず侵害される」という意味ではありません。外部から到達できるシステムに脆弱性があり、それを適切なタイミングで修正できなければ、Web サイトが組織への侵入口になる可能性があるということです。CVE-2024-4577 には特定の Windows 上の PHP 構成などの影響条件があるため、すべてのPHP環境が同じ条件で影響を受けるわけではありません。脆弱性ごとに、対象となる OS・実行方式・バージョン を確認することが重要です。[6]
事例 2: PHP2shell —— サポート中でも緊急対応が必要になる
2026 年 10 月に公表された PHP2shell は、メモリ不足時のエラー処理に関連する脆弱性 (CVE-2026-109618) と、リクエスト処理に関連する脆弱性 (CVE-2026-109619) の組み合わせです。悪用された場合、遠隔の第三者が任意のコードを実行する可能性があります。
PHP 開発チームは、次の修正版を 2026 年 10 月 21 日に公開し、速やかな更新を強く推奨しました。
| 使用している系列 | PHP2shell 修正済みの最低バージョン | サポート上の注意 |
|---|---|---|
| PHP 8.2 | 8.2.35 | セキュリティサポートは 2026 年 12 月 31 日に終了予定 |
| PHP 8.3 | 8.3.36 | セキュリティサポートは 2027 年 12 月 31 日までの予定 |
| PHP 8.4 | 8.4.27 | セキュリティサポートは 2028 年 12 月 31 日までの予定 |
| PHP 8.5 | 8.5.12 | セキュリティサポートは 2029 年 12 月 31 日までの予定 |
| PHP 8.1 以前 | 系列ごとに要確認 | PHP 公式の通常サポートは終了。移行や提供元の延長サポートを確認 |
出典：PHP 公式の 2026 年リリース情報、および日本の情報処理推進機構による注意喚起。[1][2][4][5] これは修正済みかどうかを確認するための最低バージョンです。実際の適用時には、利用している配布元・OS・ホスティング事業者が提供する最新の修正版も確認してください。
PHP2shell はサポート中の系列でも修正前なら影響を受ける問題です。サポートが終了した古い系列では状況はさらに深刻です。脆弱性の調査に関与したセキュリティ企業 Wiz は、PHP 5.4 以降のバージョンでは、2 件の脆弱性の少なくとも一方の影響を受けると報告しています。サポートが終了した古い系列では、今回の脆弱性に対する PHP 公式の修正が提供されません。そのため、通常のパッチ適用では解決できず、サポート対象への移行などが必要になる場合があります。
2026 年 10 月 26 日、CISA は両脆弱性を「Known Exploited Vulnerabilities (KEV) Catalog」に追加しました。これは、脆弱性が実際の攻撃で悪用されていることを示す重要な注意情報です。一方、日本の情報処理推進機構は10月27日時点で、日本における PHP2shell の攻撃被害を把握していないと発表しています。[2][7]
「日本で被害が確認されていない」ことを、対策を先送りする根拠にしてはいけません。
ここから経営陣が読み取るべきこと
重大な脆弱性が公表されると、現場は影響するシステムの特定、修正の適用、動作確認、切り替えなどを短期間で進めなければならない場合があります。それらを実行するには、技術的な作業だけでなく、業務側の協力、停止や切り替えの承認、予算や人員、委託先との責任分担が必要です。
したがって、脆弱性対応をエンジニアに「更新しておいて」と指示するだけでは不十分です。経営・管理側には、必要な対応を優先できる意思決定の仕組みと、実行に必要な資源を用意する責任があります。
3. 多層防御の観点から考えるセキュリティの現実
セキュリティの基本の一つは 多層防御 です。家に例えるなら、玄関に頑丈な鍵を付けても、裏口や窓が開いたままでは安全とは言えません。また、今日侵入されなかったからといって、明日も安全だとは限りません。
サポート切れの PHP を使い続けることは、弱点が残っているのに、その弱点を修正する手段が限られている状態に似ています。外部からアクセスできる Web サイトでは、攻撃者が脆弱な環境を探し続けている可能性を前提に、弱点を減らす必要があります。
| 防御の層 | 具体的な対応 | できること・限界 |
|---|---|---|
| 更新・保守 | PHP 本体、CMS・フレームワーク・プラグイン・ライブラリをサポート対象に保つ | 脆弱性の修正が基本。更新後の動作確認も必要 |
| 公開範囲の制限 | 不要なサービスを閉じる。管理画面などへのアクセスを制限する | 攻撃可能な範囲を減らせるが、修正の代わりにはならない |
| 検知・監視 | アクセスログ、不審なファイル、予期しない通信、未知のアカウントなどを確認する | 不審な活動の発見に役立つが、監視だけで侵害を防げるわけではない |
| バックアップ・復旧 | バックアップを保護し、復元と再構築の手順を実際に試す | 被害後の復旧を助ける。バックアップが存在するだけでは復旧可能とは限らない |
| インシデント対応 | 影響範囲の調査、証拠保全、認証情報の更新、復旧判断を行う | 侵害が疑われる場合に、単純な再起動やパッチ適用だけで済ませない |
どの対策も、サポート切れのソフトウェアを放置する理由にはなりません。ネットワーク側の制限や監視の強化は一時的なリスク低減に役立つことがありますが、長期的な安全を保証するものではありません。暫定対策と並行して、サポート対象の環境へ移行する計画を立てる必要があります。[2][6][8]
4. 経営陣・管理者層が今すぐ確認すべきこと
PHP の更新・移行を現場任せにしないために、組織として次の項目を確認してください。最初からすべてを一度に解決できなくても、責任者と期限を決めて可視化することが重要です。
| 優先度 | 確認事項 | 求める成果物・決定事項 | 主な責任者 |
|---|---|---|---|
| 最優先 | PHP2shell の影響を受けるシステムがあるか | 稼働バージョン、公開状況、修正状況の一覧 | システム管理者・保守委託先 |
| 最優先 | 管理対象の Web システムを把握しているか | 公式サイト、採用・キャンペーン・ブランド別サイト、サブドメイン、委託先管理サイトを含む台帳 | IT 責任者・各事業部門 |
| 高 | サポート終了した PHP が残っていないか | バージョン、サポート期限、業務重要度、外部公開の有無 | システム管理者 |
| 高 | 更新・移行の責任と期限が明確か | 責任者、実施期限、検証担当、切り替え判断権限 | IT 責任者・事業責任者 |
| 高 | 移行に必要な費用と人員を確保できるか | 移行計画、予算、社内外の担当範囲 | 経営陣・管理者層 |
| 継続 | 更新後も保守を続けられるか | 定期的なサポート期限レビュー、更新方針、復旧試験の記録 | IT 責任者・システム管理者 |
1. PHP が使われているシステムを把握できているか
公式 Web サイトだけでなく、採用サイト、キャンペーンサイト、ブランド別サイト、グループ会社のサイト、古いサブドメイン、委託先が管理するシステムにも目を向けます。採用サイトやキャンペーンサイト、製品・ブランドサイト、子会社のサイト、古いサブドメイン、さらには外部の代理店やホスティングプロバイダーが管理しているシステムなども対象に含める必要があります。こうした資産は、それぞれ所有者や管理体制が異なる場合があります。また、WordPress、Drupal、Joomla をはじめとする広く利用されているコンテンツ管理システム (CMS) の多くで PHP が採用されているため、資産の棚卸しを行う際には、メインのランタイムだけでなく、アプリケーション本体やそれらが依存するコンポーネントまで含めて確認することが重要です。
W3Techs によるとサーバーサイドプログラミング言語の中で PHP が占めるシェアは約 70 % で、2 位を大きく引き離しての 1 位です。そのうちの 2 つに 1 つの Web サイトでサポート期限切れのバージョンが使われています。[3]
2. 実際に動いているバージョンを確認できているか
サーバー上のコマンドで確認した PHP のバージョンと、Web サイトのリクエストを処理している実行環境のバージョンが異なる場合があります。ホスティング事業者、クラウド事業者、保守委託先にも確認し、実際に稼働している環境を特定してください。
3. PHP2shell への影響と修正状況を確認したか
PHP 公式の注意喚起にある修正バージョンと利用環境を照合します。PHP 8.1 以前など、公式サポートが終了した系列については、パッチの提供を前提にせず、サポート対象への移行や対策済みの製品・サービスへの切り替えを検討してください。更新が完了するまでの間は、公開範囲の制限などの暫定策を検討し、それでも十分にリスクを下げられない場合は、外部からのアクセス遮断やサービスの一時停止も判断対象にします。[2]
4. 移行に必要な人員・予算・期限が決まっているか
「いずれ更新する」という方針だけでは、先送りを招きます。責任者、期限、予算、検証担当、停止や切り替えの判断権限を明確にしてください。古いシステムでは、改修の継続だけでなく、別製品への移行、機能縮小、公開終了や廃止も選択肢として比較する必要があります。[2]
5. 移行後も継続して保守できるか
一度だけ新しいバージョンに更新しても、次のサポート終了までに同じ問題が起きれば意味がありません。PHP と周辺ソフトウェアのサポート期限を定期的に確認し、更新を計画・検証・実施する体制を整えてください。保守できる人員や委託先を確保できないシステムは、使い続ける前提そのものを見直す必要があります。
まとめ: サポート切れは、技術部門だけの問題ではない
PHP のサポート切れは、単に「古いバージョンを使っている」という技術上の問題ではありません。修正されない脆弱性にさらされる可能性、攻撃を受けた場合の事業影響、更新・移行の費用、保守を担う人材の不足が重なった、組織的なリスクです。
PHP2shell が示すのは、サポート中のバージョンでも修正前のリリースなら緊急対応が必要になり得る一方、サポート終了したバージョンでは必要な修正を入手できない場合がある、という現実です。影響範囲を確認し、脆弱性を修正し、必要に応じて公開範囲を制限し、復旧できる状態を保つことを、日常の運用に組み込まなければなりません。
経営陣・管理者層に求められるのは、更新を現場に命じるだけでなく、そのための予算・人員・権限を確保し、移行が困難なシステムについては継続の是非を決めることです。現場のエンジニアには、稼働環境と依存関係を正確に把握し、リスクと選択肢を説明し、安全に更新・移行できる手順を整える役割があります。
「今も動いている」ことと「今後も安全に運用できる」ことは同じではありません。 サポート期限を確認し、リスクを評価し、必要な対応を実行すること。それが、顧客の信頼と事業の継続性を守るための出発点です。
参考資料・出典
以下の資料を、本文中の番号と対応させています。PHP のバージョンや脆弱性対応については、公開時にも必ず最新版を確認してください。
- The PHP Group, “PHP 8.5.12 Released!”, “PHP 8.4.27 Released!”, “PHP 8.3.36 Released!”, “PHP 8.2.35 Released!”（2026年10月21日） — CVE-2026-109618 / CVE-2026-109619の説明、修正版および緊急更新の推奨。 PHP News Archive 2026
- 情報処理推進機構（IPA）「PHPの脆弱性対策について（CVE-2026-109618、CVE-2026-109619：PHP2shell）」（2026年10月22日公開、10月27日更新）— 影響対象、修正バージョン、日本での被害把握状況、サポート切れバージョンへの対応方針。 公式注意喚起
- W3Techs Usage statistics of PHP for websites 28 October 2026.
- The PHP Group, “Supported Versions” — PHP系列の通常サポートおよびセキュリティサポートの考え方、サポート対象系列。 公式ページ
- The PHP Group, “Unsupported Branches” — PHP 8.1以前など、サポート終了済み系列のEOL日と最終リリース。 公式ページ
- 情報処理推進機構（IPA）「PHPの脆弱性（CVE-2024-4577）を狙う攻撃について」（2024年7月5日公開、7月12日更新）— 日本の複数組織における悪用とWebシェル設置に関する注意喚起。 公式注意喚起
- Cybersecurity and Infrastructure Security Agency（CISA）, “CISA Adds Two Known Exploited Vulnerabilities to Catalog”（2026年10月26日）— CVE-2026-109618およびCVE-2026-109619のKEVカタログ追加。 公式告知
- Cybersecurity and Infrastructure Security Agency（CISA）ほか, “#StopRansomware Guide” — バックアップ保護、復旧準備、対応計画に関する一般的な指針。 CISA Ransomware Guide
本記事のサポート状況および PHP2shell に関する記述は、2026 年 10 月 28 日時点の公開情報に基づいています。実際の対応では、利用環境の提供元が公表する最新情報と適用条件を確認してください。