2026年10月21日、PHPの開発元は、認証なしで外部からプログラムを実行される深刻な脆弱性2件を修正したバージョンを公開しました。内容は公開予定日より前に漏れていました。首相がSNSで「ウェブサイトの一時停止も有効」と呼びかけ、国内では銀行、ゲーム、EC、自治体などのサービスが相次いで止まりました。

修正版が出たのは、PHP 8.2〜8.5の4つの系統だけです。PHP 7系と8.1には通常の修正版が出ません。 8.2も2026年12月31日でサポートが終わります。レンタルサーバーのサイトは事業者が更新してくれますが、自社サーバーやAWS上で動く業務システムは、自分たちで対応しなければなりません。古いPHPで作られたシステムでは、すぐに上げられないことも多いはずです。

本記事では、今回の脆弱性で何が起きたか、自社のシステムが該当するかの確認方法、すぐにアップデートできない理由、古いシステムを延命するか作り直すかの判断を、情シス担当者向けに整理します。

想定読者

本記事は、次のような方を想定しています。

• 自社の業務システムやWebサービスがPHPで動いているが、バージョンを把握できていない情シス担当者
• PHP 7系や8.1のシステムを抱えていて、今回の修正版を当てられない方
• システムを作った会社と連絡が取れない、または保守契約が切れている方
• 今回の件をきっかけに、古いシステムの作り直しを社内で提案したい方

---

2026年10月のPHP脆弱性で何が起きたか

公表から修正版の公開までの経過

今回の脆弱性は、PHP本体（PHPのプログラムを実行するしくみ）にあります。WordPressやLaravelなど、個別のソフトウェアやフレームワークの問題ではありません。PHPで動くWebサイトやシステムは、作りに関係なく影響を受ける可能性があります。

脆弱性は CVE-2026-109618 と CVE-2026-109619 の2件で、「PHP2Shell」とも呼ばれています。深刻度は、共通の評価基準（CVSS v4.0）で9.2の「緊急」です。開発元は、Webのリクエストを処理するすべてのPHPが対象で、特にApacheの「mod_php」という動かし方では、アプリケーションのコードが動く前に攻撃が成立すると説明しています。

国内では多くのサービスが一時停止した

日本経済新聞は、PHPを「世界のウェブサイトのおよそ7割に使われている」と報じています。修正版が出る前の21日夜には、国内の多くの組織がサービスを予防的に止めました。セキュリティ情報をまとめているブログ「piyolog」は、各社の告知で確認できた一時停止を211組織と数えています。国の機関や自治体、金融機関、大学、ゲーム、EC、レンタルサーバーの管理画面などです。

悪用の状況は、情報源によって違います。米国のCISAは、公表時点では悪用を確認していないとしました。一方、セキュリティ企業のwatchTowrやCloudflareは、攻撃が出始めていると報告しています。いずれにしても、詳細が出回った以上、攻撃が増えると考えて動くのが妥当です。

---

自社のシステムが該当するかを確認する

まず確かめるのは、「どのバージョンのPHPが」「どう動いていて」「誰が更新する場所にあるか」の3つです。

PHPのバージョンを確かめる

サーバーにログインできる場合は、次のコマンドでバージョンがわかります。

php -v

ただし、このコマンドで出るのはコマンドライン用のPHPです。Webで使っているPHPが別のバージョンということもあります。Webサーバーの設定や、phpinfo() を表示する管理用ページで確かめてください（確認が終わったら、そのページは必ず削除します）。

システムの置き場所で、誰が更新するかが変わる

レンタルサーバーでも、古いPHPを選んでいる場合の扱いは事業者によって違います。10月22日時点で、さくらインターネットは管理画面で選べるすべてのバージョンへの対応を終えたと告知しています。エックスサーバーは8.2〜8.5への適用を終え、それより古い版は独自の修正を作成中としています。使っている事業者の告知を確認してください。

すでに攻撃を受けていないか

JPCERT/CCの注意喚起は、侵害を確かめる手がかりとして、不審なセッションID、異常なmultipartリクエスト、メモリエラーやHTTP 500の急増、ワーカーの異常終了などを挙げています。同時に、痕跡が見つからなくても安全とは言い切れないとも書いています。ログの確認は、修正の適用と並行して進めてください。

---

修正版が出ない7系・8.1、12月で終わる8.2

バージョン別の状況

PHPは、各系統が最初のリリースから約4年でサポートを終えます。2026年10月22日時点の状況は次のとおりです。

7.4・8.0・8.1向けの「最小限の修正」はどう使うものか

今回は深刻度が高いため、開発元は例外として、7.4・8.0・8.1向けに最小限の修正をソースコードで公開しました。ただし、これは自分でPHPをビルドしている人向けの措置です。開発元は、ディストリビューションや長期サポートのベンダーに確認するか、サポート中のバージョンへ上げるよう求めています。

OSのパッケージでPHPを入れている場合は、OSのベンダーが修正を出しているかを確認します。対応はOSによって分かれます。たとえばUbuntu 22.04のphp8.1には修正が出ていますが、Amazon Linux 2023のphp8.1は「修正予定なし」とされています。修正が出ていなければ、自分でビルドして入れ替えることになり、それができる担当者がいない会社も多いでしょう。

なお、どこまで古い版が影響を受けるかを、開発元は明記していません。発見者の一人であるWizは、5.4以降のすべての版が少なくとも1件の影響を受けると説明しています。

設定による緩和策は「安全にする」ものではない

開発元は、すぐに更新できない場合の緩和策も示しています。メモリ上限や送信サイズの設定を変える、アップロード進捗の機能を止める、といったものです。ただし、開発元はこれらを「攻撃の経路を減らすが、安全にはしない」と位置づけています。完全な対策は更新だけです。

設定変更でもすぐに対応できない場合は、IPAやCISAが示すとおり、外部からのアクセスを制限するか、一時的にシステムを止めることも検討してください。

---

「アップデートすれば終わり」にならない理由

PHP 7系のシステムを8.3や8.4へ上げる作業は、部品の交換というより改修に近いものです。すぐに上げられない理由は、主に3つあります。

PHP本体を上げると、アプリが動かなくなることがある

PHP 8.0では、7系までの書き方の一部が使えなくなりました。開発元の移行ガイドには、たとえば次の変更が載っています。

• 文字列と数値の比較のルールが変わった（0 == "" の結果が true から false になる）
• each() や create_function() など、古い関数が削除された
• 型の扱いが厳しくなり、以前は警告で済んだ処理がエラーで止まる
• エラー表示の既定値が変わり、@ で隠していた致命的なエラーが表に出る

さらに古いPHP 5系のシステムでは、PHP 7.0の時点で削除された mysql_ 関数でデータベースにつないでいることがあります。この場合、データベースまわりの処理を書き直す必要があります。

どこが動かなくなるかは、コードを調べ、動かしてみないとわかりません。業務システムは画面や帳票が多いので、確認作業だけで数週間から数か月かかることもあります。

フレームワークも期限を迎えている

業務システムは、LaravelやCakePHPなどのフレームワークで作られていることが多くあります。PHPを上げるには、フレームワークも新しいPHPに対応した版にしなければなりません。そのフレームワーク自体にも期限があります。

CakePHP 2.xや3.xで作られたシステムは、PHP 8系では動きません。PHPを上げるには、フレームワークの版を上げる改修が必要になり、その規模は作り直しに近くなります。

作った会社がいない、テストのしくみがない

古いシステムほど、作った会社と連絡が取れない、仕様書が残っていない、自動テストがない、といった事情を抱えています。この状態でPHPを上げると、何が壊れたのかを確かめる手段がありません。結果として「怖くて触れない」まま、修正の届かないPHPで動き続けることになります。

---

PHPだけの問題ではない：言語にも基盤にも期限がある

今回はPHPでしたが、同じことはほかの言語でも起こり得ます。どの言語にもサポートの期限があり、期限を過ぎた版には、深刻な脆弱性が見つかっても修正が届きません。今回のように、修正版より先に詳細が漏れることもあります。

2026年10月22日時点で、主な言語の期限は次のとおりです。

言語だけではありません。システムを支えるOSやデータベース、開発ツールにも、それぞれ期限があります。期限切れの部品が一つでもあれば、そこが攻撃の入口になり得ます。

• OS：Windows Server 2012/R2のESUが2026年10月13日に完全終了、Amazon Linux 2のサポート終了後にどうする？
• データベース：SQL Server 2016のサポート終了後にどうする？
• 言語・開発基盤：.NET 8と.NET 9は同じ日にサポート終了、VB.NETのサポート終了にどう備える？

PHPを一度上げて終わりにせず、「期限が来たら上げる」しくみを社内に作っておく必要があります。上げられないまま何年も動いているシステムは、次の大きな脆弱性が出たとき、また同じ状況に陥ります。

---

古いシステムをどうするか：延命・作り直し・置き換え

修正版が出ないPHPで動くシステムには、3つの道があります。

判断の目安

どれを選ぶかは、システムごとに次の点を見て決めます。

• PHPとフレームワークの版：CakePHP 2.x・3.xやPHP 5系なら、延命より作り直しに近い作業になる
• コードと仕様の状態：作った人がいない、ドキュメントがない場合、延命でも調査に時間がかかる
• 業務との合い方：使っていない機能が多い、Excelでの手作業が周りに増えているなら、作り直しの好機
• 今後何年使うか：あと1〜2年で役目を終えるなら、延命と守りの強化で乗り切る選択もある

延命を選ぶ場合でも、次の期限を前提に計画を立ててください。PHP 8.3の期限は2027年12月31日、8.4は2028年12月31日です。今回8.2.35へ上げたシステムも、年明けまでに次の移行を計画する必要があります。

作り直しは段階的に進められる

作り直しというと、何年もかかる大きな計画を想像するかもしれません。実際には、外部に公開している部分や、古さのリスクが大きい部分から順に新しい基盤へ移すこともできます。c3indexでも、刷新中の基幹システムの開発を段階的に引き継いだ例や、古いサーバーで動いていた生産管理システムをクラウドへ移しながら作り直した例があります。

• パッケージでは合わなかった生産管理システムの刷新とクラウド移行
• 刷新中の基幹システムの二次開発を段階的に引き継ぎ
• ワークフローシステムの保守から、新基盤への申請書移行まで

---

刷新が終わるまでの守り方

作り直しを決めても、新しいシステムができるまでは古いシステムを使い続けます。その間は、次の守りを重ねてください。

• 公開範囲を絞る：社内だけで使うシステムなら、インターネットから直接アクセスできないようにする。VPNの内側に置く、接続元のIPアドレスを制限する
• WAFを入れる：Webアプリケーションへの攻撃を手前で止めるしくみ。クラウドの機能で比較的早く導入できる
• 開発元の緩和策を設定する：完全ではないが、攻撃の経路を減らせる
• 脆弱性診断を受ける：PHP以外の部品も含め、外からどう見えているかを確かめる
• 保守の体制を決める：誰がPHPやOSの更新を判断し、作業するのかを契約で明確にする

---

よくある質問

Q. レンタルサーバーで動かしているサイトも、対応が必要ですか？

PHP本体の更新は事業者が行います。ただし、古いPHPを選んでいる場合の扱いは事業者によって違うため、告知を確認してください。今回の修正が当たっていても、サポートが終わった版には次の修正が届く保証がありません。管理画面でサポート中の版へ切り替え、動かなくなるおそれがあるなら、先にテスト用の環境で確かめます。

Q. PHP 7.4のまま、公開された最小限の修正を当てて使い続けられますか？

当てれば今回の2件は防げますが、開発元はこれを例外的な措置としています。次に脆弱性が見つかったとき、同じ対応がある保証はありません。当面の守りとして使いつつ、サポート中の版への移行か作り直しを計画してください。

Q. 8.2.35に上げたので、もう安心ですか？

今回の2件は修正されています。ただ、PHP 8.2は2026年12月31日でサポートが終わります。年明け以降に見つかった脆弱性の修正は届きません。8.3以降への移行を、年内から計画することをおすすめします。

Q. システムを作った会社と連絡が取れません。どこに相談すればよいですか？

他社が作ったシステムの調査や引き継ぎを受けているシステム会社に相談できます。ソースコードとサーバーへのアクセス手段があれば、PHPとフレームワークの版、改修の規模、作り直しとの比較を調べられます。ソースコードがない場合も、動いているサーバーから回収できることがあります。

Q. 作り直しの費用はどのくらいかかりますか？

画面や帳票の数、外部システムとの連携、データの量で変わります。まずは現状を調べ、延命した場合と作り直した場合の費用と期間を並べて比べるのが現実的です。

---

まとめ

本記事のポイントをまとめます。

• 2026年10月21日、PHPの開発元は、認証なしで外部からプログラムを実行される脆弱性2件（CVSS v4.0で9.2）を修正した8.2〜8.5の新版を公開した。詳細は公開前に漏れ、国内では多くのサービスが一時停止した
• 修正版が出たのは8.2〜8.5だけ。7.4・8.0・8.1は自分でビルドする人向けの最小限の修正のみで、7.3以前には提供がない。8.2も2026年12月31日で終わる
• レンタルサーバーは事業者が更新するが、自社サーバーやクラウドで動く業務システムは自社で対応する必要がある
• PHP 7系から8系への移行は、古い関数の削除や型の厳格化、フレームワークの対応状況のため、改修に近い作業になる
• 期限切れの問題はPHPに限らない。.NET、Python、Node.js、Java、OS、データベースにもそれぞれ期限がある
• 古いシステムは、延命・作り直し・置き換えを比べて方針を決め、移行が終わるまでは公開範囲の制限やWAFで守る

修正版を当てられないシステムは、次に大きな脆弱性が出たときも同じ対応に追われます。まずは社内のPHPのシステムを棚卸しし、どのシステムをいつまでにどうするかを決めるところから始めてください。

---

c3index に相談する

c3index は、製造業・中堅企業の情シスを支援するシステム会社です。他社が作ったシステムの調査・引き継ぎから、PHPやフレームワークのバージョンアップ、新しい基盤での作り直し、AWSへの移行と移行後の保守まで、一貫して支援しています。「このシステムは延命できるのか、作り直すべきか」の判断材料を集める現状調査からお手伝いします。名古屋・東京・福岡の3拠点体制で対応しています。まずはお気軽にご相談ください。