〜PHPのEOLバージョンには公式修正パッチが提供されない：2026年10月の重大脆弱性と、今企業が下すべき判断〜

2026年10月21日（日本時間）、PHP本体において深刻度「緊急」とされる2件の脆弱性（CVE-2026-109618、CVE-2026-109619）に対する修正パッチが公開されました。国内でも多数のWebサービスが緊急メンテナンスを実施し、政府機関も公式SNSを通じてPHPの利用状況の確認および速やかな更新準備を呼びかける事態となっています。

しかし、PHPプロジェクト公式から修正版がリリースされたのは、現行サポート期間内にある4系統（8.2〜8.5）のみです。すでにサポートが終了（EOL）している8.1以前の環境に対しては、公式の修正版は提供されていません。今後、同様の重大な脆弱性が発見された際も、EOL環境は同様のリスクに直面し続けることになります。

この記事でわかること

• 今回の脆弱性における「公式修正パッチが提供されたバージョン」と「対象外となったバージョン」の境界線

• 自社PHPバージョンの確認方法および保守ベンダーへ確認すべき4項目

• 「アップグレード」「延長サポート」「暫定延命」「システム再構築・移行」の4つの選択肢と判断基準

経営者・システム責任者の方へ（要点）

• PHP 8.1以前の環境： 今回の重大脆弱性に対する公式修正パッチは提供されていません。

• PHP 8.2の環境： 今回は修正対象となったものの、2026年12月31日をもってサポート終了（EOL）を迎えます。

• 現在の求められる初動： 稼働中のPHPシステムの緊急棚卸しと、バージョンアップまたは刷新計画の策定・予算化です。

▶ レガシーシステム刷新の全体像は「【完全ガイド】レガシー刷新」で解説しています。

2026年10月21日に何が起きたのか

今回の2件脆弱性は、WordPressやLaravelなどの個別フレームワークやアプリケーションではなく、PHP本体に起因するものです。深刻度はCVSS v4.0で「9.2」と極めて高く、環境や設定によっては、外部から認証なしでサーバー上の任意コードを実行される恐れがあります。PHP-FPM、Apacheのmod_php、php-cgiなど、Webリクエストを処理するほぼ全般の稼働形態が対象とされています。

日時（日本時間）	出来事
10月21日未明	CVE識別番号が先行してインターネット上に流出（一部で誤った公開時刻やCVSS 10.0との誤情報が拡散）。PHPプロジェクトはパッチ公開時刻を当初予定の22日23時から21日23時へと前倒しを決定。
10月21日	IPA（独立行政法人情報処理推進機構）が「事前準備のお願い」を緊急公表。PHP稼働システムの棚卸しを要請。
10月21日 夜	首相および国家サイバー統括室がXで、公開サイトにおけるPHP利用の有無の確認と速やかなパッチ適用準備を呼びかけ。
10月21日 23時頃	PHP公式より修正版（8.5.12／8.4.27／8.3.36／8.2.35）が正式公開。
10月21日前後	国内外のホスティング事業者やWebサービスで緊急メンテナンスが相次ぐ。セキュリティ機関からは、攻撃の試行やWAFのシグネチャ回避を狙う攻撃パターンの変化が観測されたと報告（※本稿執筆時点で大規模な侵害事例の公表はなし）。

注目すべき点として、IPAの事前注意喚起において「サポートが終了した古いPHPを利用し続けているウェブサイト・ウェブサービスも見受けられます」と明記されていることが挙げられます。今回の問題の本質はまさにこの点にあります。

「修正パッチが出ない（EOL）」とは何を意味するのか

PHPの各バージョン系列は、初回リリースから2年間の「アクティブサポート（機能改修・バグ修正）」と、その後の2年間の「セキュリティサポート（重大な脆弱性修正のみ）」を経て、計4年でサポート終了（EOL: End-of-Life）を迎えます。

今回の修正対応状況をバージョン系列ごとに整理すると、以下の通りです。

バージョン系列	セキュリティサポート期限	今回の公式修正版
PHP8.5	2029年12月31日	8.5.12 提供あり
PHP8.4	2028年12月31日	8.4.27 提供あり
PHP8.3	2027年12月31日	8.3.36 提供あり
PHP8.2	2026年12月31日（あと約70日）	8.2.35 提供あり
PHP8.1／8.0／7.4	終了（EOL）	公式パッケージリリースなし（限定的なソースコード差分のみ公開）
PHP7.3以前／5.x系	終了（EOL）	公式からの提供一切なし

出典：PHP公式サイト「Supported Versions」、CERT-EU Security Advisory 2026-018（2026年10月22日確認情報）

今回、PHPセキュリティチームは極めて異例の措置として、7.4・8.0・8.1向けに最小限のソースコード差分（パッチコード）を公開しました。しかし、これは「自前でソースコードからコンパイル・ビルドが可能な組織」や「LTSベンダーによるサポートを受けられない組織」向けの応急措置に過ぎません。公式なバイナリ・パッケージ配布ではないため、適用作業、ビルド、動作検証のすべてのリスクを利用者自身が負う必要があります。 なお、7.3以前および5.x系に対しては、このソースコード差分すら提供されていません。

今後見つかる脆弱性において、同様の例外措置が取られる保証は一切ありません。つまり「EOL（サポート終了）」とは、修正パッチの作成・検証・安全な配布というエコシステムそのものから完全に切り離されることを意味します。

また、見落としてはならないのが「PHP 8.2」の存在です。今回は修正版が提供されたものの、サポート期限は2026年12月31日までです。年末年始や年度末の進行を考慮すると、今すぐ移行計画に着手しなければ猶予は残されていません。

自社のPHP環境がEOLに該当するかご不明な企業様へ

PHP・OS・フレームワークのバージョンおよび潜在的リスクの範囲を、専門エンジニアが無料で簡易診断いたします。

無料簡易診断を申し込む

自社システムの確認方法と保守ベンダーへのヒアリング事項

まずは、運用中の各Webサイトや業務システムがどのバージョンで稼働しているかを正確に把握する必要があります。主な確認手順は以下の4点です。

確認方法	実務上のポイント
サーバー上で php -v を実行	最も確実な確認手法。Webサーバー（Apache/Nginx）が解釈するPHPとCLI（コマンドライン）環境で異なるバージョンが稼働しているケースがあるため、双方を確認。
phpinfo() 関数の実行	Webサーバー経由で実際に読み込まれているモジュールや設定値を確認可能。（情報漏えい防止のため、確認完了後は直ちに当該ファイルをサーバー上から削除すること。）
HTTPレスポンスヘッダー（X-Powered-By）	外部から簡易確認できる場合がある。ただしセキュリティ対策としてヘッダーを非表示化している環境も多く、表示されないからといって安全の証左にはならない。
ホスティング・クラウドの管理画面	クラウドやマネージドサーバーでは、コントロールパネル上で適用バージョンを確認・切り替え可能な場合が多い。事業者のメンテナンス告知と確認。

システムの保守運用を外部ベンダーに委託している場合は、以下の4項目を至急ヒアリングしてください。

・現行のPHPバージョンおよび稼働OSディストリビューション・バージョン

・今回の脆弱性（CVE-2026-109618、CVE-2026-109619）の該当有無

・修正パッチの適用スケジュール（即時適用が困難な場合、その理由と暫定対策）

・現行の保守契約範囲に、PHPのメジャー/マイナーバージョンアップ対応が含まれているか

日本国内でとりわけ多く見られるのが、「CentOS 7などの旧OS上でPHP 7.xを運用している」構成です。この場合、PHPは外部リポジトリ経由で導入されているケースが多く、OSと言語基盤の双方がサポート切れ（二重EOL）という極めて危険な状態に陥っています。OSベンダーによるセキュリティバックポートも期待できません。

データで見る実態：世界のPHP稼働サイトの約半数がEOL環境

W3Techsの調査データ（2026年10月22日時点）によると、サーバーサイドプログラミング言語が判別可能なWebサイトのうち、69.3%がPHPを採用しています。そのバージョン内訳から現状を分析すると、以下の実態が浮き彫りになります。

バージョン区分	PHPサイトに占める割合
PHP 5.x系以前	7.8%
PHP 7.x系	26.9%
PHP 8.0／8.1	13.7%
現行EOLバージョンの合計	約48.4%
2027年1月以降（PHP8.2がEOL後）	約66.5%

出典：W3Techs「Usage statistics of PHP」（2026年10月22日時点）をもとに編集部にて算出。

※バージョン判別が可能な全世界のサイトを母集団としており、日本国内単独の統計ではありません。

さらに、サイバーセキュリティの脅威環境にも構造的な変化が起きています。今回の脆弱性は、AIを活用した高度なコード解析技術を用いる複数の研究機関・セキュリティ企業から報告されました。PHP Foundationも言及している通り、AIツールの普及により未知の脆弱性が検知・報告されるスピードは以前とは比較にならないほど加速しています。

脆弱性が発見・兵器化されるスピードが加速度的に早まる一方で、EOL環境にはそれを修正・防御する公式な仕組みが存在しません。この防衛ギャップは今後さらに拡大していくと考えられます。

なぜ「単なるバージョンアップ」で解決できないのか

EOL環境を運用し続けている企業の多くは、放置を望んでいるわけではなく、「バージョンを上げたくても上げられない」構造的な制約を抱えています。その最大の障壁が、PHP自体の破壊的変更です。

バージョン移行区間	代表的な仕様変更・非互換	現場で発生すること
5.x → 7.0	mysql_*関数、ereg系関数の削除	データベース接続層やクエリ処理が完全に動作停止。
7.x → 8.0	create_function()・each()の削除、文字列と数値の比較仕様の変更、多くの警告の例外（TypeError等）への変更	エラーにならず判定結果だけが逆転する箇所や、これまで動いていた業務ロジックが例外スローで強制停止する箇所が多発。
8.0 → 8.1／8.2	組み込み関数へのnull渡しの非推奨化、動的プロパティの非推奨化	非推奨の警告がログに大量に出力され、システム監視や障害検知に支障をきたす。

これに加え、言語以外の要因が複雑に絡み合います。

• フレームワーク・CMSの制約： 使用中の古いフレームワーク（古いCakePHP、Zend Framework等）やCMSが最新のPHPに対応しておらず、フレームワーク自体の移行＝実質的なシステム全面再構築となる。

• OS基盤のサポート終了： 例としてCentOS 7は2024年6月末でEOLを迎えており、サーバーOS環境ごと刷新しなければ最新パッケージを導入できない。

• 仕様書・テストコードの不在と属人化： 初期開発メンバーが不在で仕様書も残っておらず、「どこを修正するとどこに不具合が波及するか」を誰も検証できない。

結果として、「脆弱性を防ぐためにバージョンを上げたいが、改修すると基幹業務が停止するリスクがあり着手できない」という膠着状態に陥ります。

なお、PHP公式やCERT-EUより、即時アップデートが困難な環境向けに暫定緩和策memory_limitの縮小、session.upload_progress.enabledの無効化、リクエストサイズの制限等）が提示されています。しかし、これらはあくまで「攻撃経路への露出を一時的に絞る措置」に過ぎず、根本的な解決策にはなり得ないと明記されています。WAFのシグネチャ対策についても同様で、攻撃リスクの軽減には寄与するものの、脆弱性自体の解消ではない点に注意が必要です。

EOL環境の運用放置がもたらす重大な経営リスク

改正個人情報保護法に基づく法定報告・本人通知義務

サイバー攻撃など不正な意図による個人データの漏えい等が発生、またはその恐れが生じた場合、漏えい件数の多寡に関わらず個人情報保護委員会への報告および本人への通知が法律上義務付けられています（速報は発覚から概ね3〜5日以内、確報は60日以内）。「既知のサポート終了バージョンを放置していたこと」は、インシデント原因究明の場において善管注意義務の不履行として極めて厳しく追及される要因となります。

システム停止に伴う事業継続性（BCP）の毀損

修正パッチを適用できない場合、実務上取り得る最も確実な緊急措置は「Webサービスの公開一時停止（隔離）」です。今回も国家サイバー統括室が、パッチ適用が困難な場合の有効な手段として一時停止を呼びかけました。しかしEOL環境を運用し続ける限り、重大脆弱性が公表されるたびにサービス停止の判断を迫られることになります。サービス停止による機会損失、取引先への謝罪・補償、ブランド信用の失墜はすべて企業側の重い負担となります。

サプライチェーン攻撃の「踏み台」化リスク

2024年に深刻な被害をもたらしたPHPの脆弱性（CVE-2024-4577）では、IPAが国内複数組織におけるWebシェルの設置を公表し、侵害されたサーバーが別組織への攻撃の「中継地点（踏み台）」として悪用される危険性を警告しました。自社のセキュリティ不備が、取引先やサプライチェーン全体を脅かす加害者側へ転落するリスクを孕んでいます。

企業が取り得る4つの選択肢と判断基準

EOLバージョンの課題を抱える企業には、大きく分けて4つの選択肢が存在します。

選択肢	推奨されるケース	メリット	注意点
（A） サポート対象版へのアップグレード	ソースコードが比較的新しく、自動テスト等の検証環境が整っている場合。	最も低コストかつ短納期で対応可能。	PHP 8.2は2026年末でEOLとなるため、8.3以上への移行を推奨。非互換箇所のコード修正・回帰テストが必須。
（B）有償延長サポートの利用（OSディストリビューション・LTSベンダー）	直近での全面改修が困難で、当面の安全確保と移行期間を稼ぎたい場合。	システム本体に手を加えず、バックポートパッチを継続受給可能。	有償かつ契約期間に制限あり。パッチの提供範囲はベンダー仕様に依存するため根本解決ではない。
（C） 設定変更・WAFによる延命	移行やアップグレードを実施するまでの数週間を防御する場合。	即日導入・対策が可能。	あくまで攻撃遮断の確率を高める応急処置。既知の脆弱性そのものは残存するため、恒久対策と誤認してはならない。
（D）システム再構築・移行（モダナイゼーション）	PHP 5.x/7.x系で仕様書がなく、アップグレードの影響範囲が算出できない場合。	技術的負債を一掃し、保守性の高い最新アーキテクチャやAI連携基盤へ刷新可能。	相応のプロジェクト期間と投資が必要。現行業務要件のリバースエンジニアリングと要件定義の精度が成否を分ける。

判断のための3つの確認基準

・現行のPHPおよびOSバージョンは何か（サポート期間内か）

・仕様書・テスト環境・当時の仕様を把握しているエンジニアは存在するか

・対象システムを今後3年以上継続して利用する予定があるか

PHP 8.x系かつテスト環境が整備されていれば、第一選択は「A（アップグレード）」です。一方、PHP 7.x以前であり、仕様書が欠落しているシステムを今後3年以上使い続ける場合は、「D（モダナイゼーション）」を中長期的計画として位置付け、移行完了までの期間を「B（有償LTS）」や「C（暫定対策）」で凌ぐ進め方が最も現実的です。また、費用対効果の観点からシステムの統廃合やSaaS代替を検討することも有効な戦略です。

モダナイゼーション（D）は、単なる脆弱性回避にとどまりません。ブラックボックス化した業務ロジックを再設計・可視化し、蓄積されたデータを将来のAI活用に耐えうる基盤へと進化させる絶好の契機となります。

どの選択肢を選ぶにしても、第一歩は「稼働資産の棚卸しとリスクの可視化」です。IPAも今回の事前警告において、何よりもまず資産棚卸しの実施を強く呼びかけています。

よくある誤解（FAQ）

• 誤解1：「WAFを導入しているため安全」

  WAFは攻撃トラフィックを検知・緩和する有効な防御壁ですが、脆弱性そのものを解消するものではありません。今回も攻撃側によるWAF回避パターンの変化が観測されています。また、Cloudflare等の「DNS only」設定や直接IP指定アクセスなど、WAFを経由しない経路からの攻撃には対抗できません。

• 誤解2：「社内ネットワーク限定のシステムだから対象外」

  今回の脆弱性はWebリクエストを処理するPHP環境全般に影響します。社外非公開であっても、VPN侵入やマルウェア感染端末を経由した内部ネットワークからの横展開（ラテラルムーブメント）の足がかりとして悪用される危険性があります。また、ネットワークアプライアンスやオンプレミス業務パッケージの内部にPHPが組み込まれている事例も多く、IPAもベンダー情報の確認を推奨しています。

• 誤解3：「Linux標準パッケージを使っているから古い版でも自動で対策される」

  Red Hat Enterprise LinuxやUbuntuなどの商用ディストリビューションがセキュリティ修正をバックポートしている場合、バージョン表記が古くてもパッチ適用済みのケースは存在します。ただし、それは「OSベンダーの公式サポート（有償延長サポート含む）が有効」かつ「OS標準リポジトリから導入したPHP」に限られます。外部リポジトリ（Remi等）から個別導入したPHPは対象外となるため、バージョン番号のみで過信せず、パッケージの出所とベンダー告知を必ず確認してください。

まとめ

• 今回公式修正パッチが提供されたのはPHP 8.2〜8.5のみ。8.1以前には公式修正版はリリースされていない。

• パッチが提供されたPHP 8.2も2026年12月31日をもってサポート終了（EOL）を迎える。

• EOL問題の本質は、「更新の必要性を認識していながら、影響範囲の不透明さから容易に手を出せない」点にある。

• 企業がまず着手すべきは、PHP・OSのバージョン、仕様書・テスト環境の有無、今後の想定利用年数に基づく「稼働システムの詳細な棚卸し」である。

PHPバージョン・EOL影響 無料簡易診断のご案内

「自社のどのシステムで、どのバージョンのPHPが稼働しているか正確に把握できていない」という初期検討フェーズからご相談いただけます。

• 診断内容： PHP・OS・主要フレームワークのバージョン確認、Web公開状況の整理、EOL該当有無および脆弱性影響範囲のスクリーニング

• ご提出物： 簡易診断レポート（推奨される移行選択肢A〜Dのご提案を含みます）

• ご準備いただくもの： 調査対象システムの一覧（把握できている範囲の情報で構いません）

• 所要期間： 必要情報をご提供いただいてから、原則1営業日以内にレポートをご提出いたします

• サーバーアクセス： 原則不要（詳細調査が必要となる場合は、秘密保持契約［NDA］締結の上で対応いたします）

• 費用： 無料

※本簡易診断は、システムに脆弱性が一切存在しないことを保証するセキュリティ診断ではありません。

無料簡易診断を申し込む

参考情報・公式出典

• PHP「Supported Versions」 https://www.php.net/supported-versions.php

• PHP公式サイト セキュリティアナウンス・緩和策 https://www.php.net/

• The PHP Foundation「Today’s PHP Security Release, and How We’re Strengthening PHP Security」 https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/

• CERT-EU「Critical Vulnerabilities in PHP」Security Advisory 2026-018 https://cert.europa.eu/publications/security-advisories/2026-018/

• IPA（独立行政法人情報処理推進機構）「【事前準備のお願い】PHPのセキュリティリリース公開予定について」 https://www.ipa.go.jp/security/security-alert/2026/pre-alert20261021.html

• JPCERT/CC「PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起」 https://www.jpcert.or.jp/at/2026/at260033.html

• INTERNET Watch「多くのサイトが予防的に公開停止、高市総理が対応呼びかけ」 https://internet.watch.impress.co.jp/docs/news/2150203.html

• gihyo.jp「PHP、重大な脆弱性2件を修正」 https://gihyo.jp/article/2026/10/php-critical-security-release

• W3Techs「Usage statistics of PHP」 https://w3techs.com/technologies/details/pl-php

• JAPAN Security Summit Update「国家サイバー統括室、PHPの重大脆弱性に注意喚起」 https://japansecuritysummit.org/2026/10/15106/

• The Hacker News「PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws」 https://thehackernews.com/2026/10/php-issues-emergency-patches-for-two.html

• 個人情報保護委員会「漏えい等報告・本人への通知の義務化について」 https://www.ppc.go.jp/news/kaiseihou_feature/roueitouhoukoku_gimuka/

• ScanNetSecurity「PHPの脆弱性(CVE-2024-4577)を狙う攻撃に注意を呼びかけ」 https://scan.netsecurity.ne.jp/article/2024/07/08/51257.html