PHP のサポート切れがもたらす経営リスク -- 「PHP2shell」から考える更新責任

Web サイトや商用サービスあるいは業務システムにとって、ソフトウェアのサポート期限は技術部門だけの問題ではありません。

未修正の脆弱性（ぜいじゃくせい）の放置は、事業停止・顧客の信頼・予算に直結する、経営・管理上の課題です。

本記事では、PHP を題材に、そのサポート切れがなぜ経営上のリスクになるのか、実際の脆弱性悪用事例から何を学ぶべきかを整理します。それから経営陣・管理者層と現場のエンジニアが、何を確認すべきかを記載します。

PHP はサーバーアプリエンジンの代表的なものの一つです。今回はこちらを題材にしています。しかしながら、他のソフトウェアやインフラについても、同様の注意と配慮、さらには実践的な取組みが必要です。

要点: まず経営陣・管理者層が押さえるべきこと

背景: 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 公式「Supported Versions」「Unsupported Branches」[4][5]。利用している OS ディストリビューションやホスティング事業者が独自の延長サポートを提供している場合は、その適用条件と責任範囲も別途確認してください。

サポート終了したバージョンを使い続ける主なリスクは、次のように整理できます。

古いバージョンについて「脆弱性が何件あるか」だけを数えても、リスクを十分に評価できません。件数はデータベースの集計方法や対象範囲によって変わります。経営上重要なのは、現在のシステムがサポートを受けているか、修正版を適用できるか、そして継続的に保守する体制があるかです。

なぜ古い 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日に公開し、速やかな更新を強く推奨しました。

出典：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サイトでは、攻撃者が脆弱な環境を探し続けている可能性を前提に、弱点を減らす必要があります。

どの対策も、サポート切れのソフトウェアを放置する理由にはなりません。ネットワーク側の制限や監視の強化は一時的なリスク低減に役立つことがありますが、長期的な安全を保証するものではありません。暫定対策と並行して、サポート対象の環境へ移行する計画を立てる必要があります。[2][6][8]

4. 経営陣・管理者層が今すぐ確認すべきこと

PHP の更新・移行を現場任せにしないために、組織として次の項目を確認してください。最初からすべてを一度に解決できなくても、責任者と期限を決めて可視化することが重要です。

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日時点の公開情報に基づいています。実際の対応では、利用環境の提供元が公表する最新情報と適用条件を確認してください。