「PHPの脆弱性のニュースを見たけれど、自社のサイトがどうなっているのか分からない」「サーバー会社が対応したと聞いたが、それで安心していいのか判断できない」。今回のニュースを見て、こうした疑問を持った企業の担当者は、少なくないはずです。
2026年10月21日、PHP開発チームは、深刻度が最高クラスの脆弱性2件（CVE-2026-109618、CVE-2026-109619）を修正する緊急のセキュリティリリースを公開しました。ログインなしで外部からコードを実行されるおそれがある脆弱性で（セキュリティ業界では「PHP2Shell」とも呼ばれています）、PHPで動いているWebサイトやシステムは、規模を問わず確認の対象になります。
すでに、確認手順や「今日やること」を解説した記事は多く出ています。そこでこの記事では、少し視点を変えます。今回の事案から何が見えたのか、そして、これから企業はサイトの保守体制をどう見直すべきかを、公式発表と各社の報告をもとに整理しました。
※本記事は2026年10月28日時点の情報にもとづいています。状況は変わる可能性があるため、最新の情報は、PHP公式サイト、IPA（情報処理推進機構）、ご利用のサーバー会社の案内でご確認ください。
【まず結論】今回の事案から見えた5つの課題と、今後の方針
先に結論をお伝えします。今回の事案は、PHPのバージョンを上げれば終わる話ではなく、「誰が、何を、いつまでに守るのか」が決まっているかどうかを問う出来事でした。
- 対応の猶予が短い：予告から修正版の公開、悪用の試みの観測まで、数日のうちに進みました。「来週確認する」では間に合わない場合があります。
- サーバー会社が守る範囲と、利用者が守る範囲が違う：レンタルサーバーは事業者が修正を適用する一方、VPSなどは利用者自身の対応が必要です。
- サポート終了版のPHPが、まだ使われている：サポートが終了したバージョンへの修正は、今回は例外的な措置です。次も同じ対応があるとは限りません。
- 「更新した」だけでは、安全の確認にならない：更新前に侵入されていた可能性や、更新後にフォームなどが正常に動くかの確認が残ります。
- 管理者が決まっていないサイトが多い：制作会社、サーバーの契約先、保守担当が別々で、誰に聞けばよいか分からないサイトは少なくありません。
今後の方針としては、次の3つを、年内を目安に決めておくことをおすすめします。
- サイトごとに、管理者（連絡先）、PHPのバージョン、サポート期限を一覧にした「台帳」をつくる
- サポート終了版を使っているサイトは、移行の計画を立てる（PHP 8.2は2026年12月31日にセキュリティサポートが終了します）
- 重大な脆弱性が出たときに「誰が判断し、誰が作業するか」を、事前に決めておく
事案の整理｜10月20日から10月27日に何が起きたか
まず、事実関係を時系列で整理します。内容は、PHP公式サイト、IPA、各サーバー会社の発表、セキュリティ各社の報告にもとづいています。
| 日付 | 出来事 |
|---|---|
| 10月20日 | PHP開発チームが、10月21日14時（協定世界時）＝日本時間23時に、深刻度の高い脆弱性2件を修正するセキュリティリリースを行うと事前に告知しました。2件とも、深刻度の指標（CVSS v4.0）は9.2です。あわせて、情報が漏れた場合などは予定より早く公開する可能性があるとしていました。 |
| 10月20日〜21日 | セキュリティ会社のHuntressやwatchTowrは、公開前に脆弱性の情報が出回ったと報告しています。 |
| 10月21日 | 修正版（PHP 8.5.12、8.4.27、8.3.36、8.2.35）が公開されました。サポートが終了しているPHP 7.4、8.0、8.1についても、最小限の修正コードが提供されました。watchTowrは、同日に悪用の試みを観測したと報告しています。 |
| 10月22日 | IPAが注意喚起を公開しました。国内のレンタルサーバー各社は、緊急メンテナンスや修正の適用を進めました。 |
| 10月23日 | PHP開発チームが、追加の情報（アドバイザリ）を公開しました。session.upload_progress.enabledを無効にしておくことを推奨し、別の脆弱性（CVE-2026-115560）の詳細は、次回のリリースで公開するとしています。 |
| 10月26日 | 米国のCISA（サイバーセキュリティ・インフラストラクチャセキュリティ庁）が、今回の脆弱性を「悪用が確認された脆弱性」の一覧（KEVカタログ）に掲載しました（watchTowrは、掲載されたのはCVE-2026-109618だと報告しています）。 |
| 10月27日 | IPAが、KEVカタログへの掲載を追記しました。IPAは、国内での攻撃被害事例は把握していないとしています。 |
2件の脆弱性は、どちらもPHPの内部の処理に関するものです。1件目は、メモリ不足のエラーが起きたときに、処理の途中の不完全なデータが、そのまま「正しいデータ」として扱われてしまう問題です。2件目は、あるリクエストで使われたデータの情報が、次のリクエストの処理に残ってしまう問題です。
PHP公式は、Webのリクエストを処理するPHPの環境すべてが対象になるとしています。具体的には、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなどです。特にmod_phpでは、サイト側のプログラムが動く前に攻撃が成立しうるため、リスクが最も高いとされています。
また、公式は「設定変更だけでは、これらの脆弱性は完全には防げない」としており、修正版への更新が唯一の完全な対策です。
考察1｜公表から悪用の試みまで、猶予はほとんどなかった
今回の事案で、最も印象的だったのは時間の短さです。公式の事前告知が10月20日、情報の漏えいが同じ時期、修正版の公開と悪用の試みの観測が10月21日、そしてCISAの掲載が10月26日でした。
もちろん、悪用の「試み」と、実際に侵入が成立した件数は別の話です。Unit 42（Palo Alto Networks）は、当初「欧州の政府機関への攻撃が今回の脆弱性によるものではないか」と評価していましたが、10月25日に、その評価を撤回しました。IPAも、国内での被害事例は把握していないとしています。
それでも、実務の面で重要なのは、「詳細が出たその日から、攻撃の試みが始まる」前提で動く必要があるという点です。Palo Alto Networksは、インターネット上に公開されている、影響を受ける可能性のあるPHP環境が2,260万件を超えると報告しています（公開時点の数字です）。これだけ多いと、攻撃者にとって、機械的に試す価値のある対象になります。
この点から、企業にとっての課題は、「脆弱性が出たら考える」では遅い、ということです。次の3つを、平時に決めておく必要があります。
- 脆弱性の情報を、誰が受け取るのか（ニュース、サーバー会社の通知、制作会社からの連絡）
- 受け取った人が、自分で判断してよい範囲と、上長や経営層に確認する範囲
- 作業を依頼する先と、その連絡手段（休日や夜間も含めて）
考察2｜サーバー会社が守ってくれる範囲は、契約の種類で大きく違う
今回、国内の主なレンタルサーバー各社は、修正版の公開と前後して、予防的な措置や修正の適用を行いました。ただし、「サーバー会社が全部やってくれる」とは限らないことも、はっきりしました。各社の発表（発表時点の内容）を、次の表にまとめます。
| サービス | 発表されていた対応（要点） |
|---|---|
| エックスサーバー（レンタルサーバー） | PHP 8.2〜8.5は同じ系列の修正版へ更新し、PHP 5.1〜8.1には修正パッチを適用しました。10月26日6時20分までに、対象サーバーすべての対応が完了したと案内しています。利用者に、急いでPHPのバージョンを変更する必要はないとしています（追加の対策が必要な場合は、改めて案内するとしています）。 |
| エックスサーバーのVPS | 事業者によるPHPの修正パッチは適用しておらず、利用者自身が、PHPのバージョンの確認と更新を行う必要があります。 |
| ロリポップ！ | PHP 8.2〜8.5は開発元の修正版、PHP 7.4〜8.1は開発元が提供した修正コード、PHP 5.3〜7.3はロリポップ独自の修正を適用しました。全バージョンでsession.upload_progressを無効にしています。10月22日13時ごろに、お客様サイトの表示を再開しました。 |
| さくらのレンタルサーバ | 自社提供のPHPに必要な修正を適用し、提供中のサポート終了版にも修正を適用しました。サポート終了版は新しい脆弱性が見つかる可能性があるため、サポート対象の最新版の利用を推奨しています。 |
| さくらのVPS | サービスの提供部分でPHPを使用していないため影響はないとしつつ、利用者の環境でPHPを動かしている場合は、最新版への更新を推奨しています。 |
| KAGOYA | レンタルサーバープランは修正版へのアップデートを完了しました。マネージド専用、共用サーバー、WordPress専用サーバーなどについては、発表時点では暫定策（公開の停止やアクセス制限）の案内が中心でした。 |
さくらインターネット、ロリポップ！、KAGOYAは、発表時点で、この脆弱性を悪用した不正アクセスや情報漏えいは確認していない、としています（ロリポップ！は、脆弱性を狙ったとみられるアクセスの試み自体は確認したと案内しています）。
この表から読み取れるポイントは、次の3つです。
① 同じ「サーバー」でも、責任の範囲が違う
レンタルサーバーは、PHPの更新を事業者が行うため、利用者の作業は少なくて済みます。一方、VPSや専用サーバーのように、OSやPHPを利用者が管理するタイプは、事業者が代わりに更新してくれるとは限りません。自社のサイトが、どのタイプのサーバーで動いているかを知っておくことが、最初の一歩です。
② 事業者の対応が終わっても、利用者の確認は残る
ロリポップ！は、再開後に、サイトの表示、問い合わせフォーム、ファイルのアップロードなどが正常に動くかの確認を、利用者に呼びかけています。無効にされた機能（たとえばアップロードの進捗表示）の影響が出る可能性があるためです。
③ 事業者の対応は、数日かけて順次進んだ
エックスサーバーは10月26日朝までかけて対応を完了しました。KAGOYAの一部のプランのように、発表時点で方針を調整していたものもあります。「サーバー会社から連絡がないから大丈夫」と考えるのではなく、契約中のサービスの公式のお知らせを、自分で確認する習慣が必要です。
考察3｜サポート終了版のPHPは、「今回は例外的に」守られただけ
今回の事案で、もう1つ重要なのが、サポートが終了したバージョンの扱いです。PHP公式サイトの整理は、次のとおりです。
- PHP 8.2〜8.5：修正版が公開されました
- PHP 7.4、8.0、8.1：すでにサポートが終了していますが、今回は例外的に、最小限の修正コード（バックポート）が提供されました
- PHP 7.3以前（PHP 5を含む）：公式の修正は提供されていません
つまり、PHP 7.4、8.0、8.1を使い続けているサイトは、今回は修正コードが出たおかげで守れた、という状況です。ロリポップ！は、この対応を「応急的な位置づけ」とし、今後見つかる脆弱性について、公式の修正が提供されない、または自社で対応できない可能性があると明記しています。
さらに、PHP公式サイトによると、PHPの各バージョンのセキュリティサポートの期限は、次のとおりです。
| バージョン | セキュリティサポートの終了日 |
|---|---|
| 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 8.2を使っているサイトは、「今回の修正版が出ているから問題ない」ではなく、あと2か月ほどで、セキュリティの修正が出なくなることを、前提に計画する必要があります。年内に、PHP 8.3以上へ移行する計画を立てておくのが安全です。
古いPHPのサイトを、どうするか｜4つの選択肢
古いバージョンのPHPで動いているシステムは、一般に、次の4つの選択肢があります。それぞれ、費用と期間、リスクが違います。
| 選択肢 | 内容 | 向いているケース |
|---|---|---|
| ① PHPのバージョンを上げる | サポート中のバージョンへ上げます。古い機能の削除や型の厳格化により、改修が必要になる場合があります。 | WordPressなど、テーマやプラグインが新しいPHPに対応しているサイト |
| ② サイトを作り直す | 新しい基盤で作り直します。期間と費用がかかります。 | 古い仕組みで作られ、改修よりも作り直しのほうが合理的なシステム |
| ③ 既存の製品やサービスに置き換える | 市販のパッケージやクラウドサービスへ移ります。業務を製品に合わせる必要があります。 | 独自の機能が少なく、標準的な機能で足りるサイト |
| ④ 公開の範囲を絞る | VPNの内側に置く、接続元のIPアドレスを制限するなど、インターネットから直接アクセスできないようにします。 | 社内専用のシステム。応急措置であり、根本的な解決ではありません |
なお、フレームワークにも期限があり、古いバージョンのCakePHP（2.x、3.x）などで作られたシステムは、PHP 8系では動かない場合があります。「PHPを上げれば終わり」とは限らないため、移行の前に、どこまで改修が必要かを調べることが大切です。
考察4｜「更新したから安全」ではなく、「侵入されていなかったか」まで確認する
更新が済んでも、確認は終わりません。PHPの修正版への更新は、これからの攻撃を防ぐものですが、すでに侵入されたサイトを元に戻すものではありません。修正版の公開当日から悪用の試みが観測されていることから、更新するまでの期間に侵入されていなかったかの確認も必要です。
次の点を、保守担当者やサーバー会社と一緒に確認しておきましょう。
- 見覚えのない管理者ユーザーが、追加されていないか
- 見覚えのないファイルや、最近書き換えられたファイルが、ないか
- サイトの見た目や、リンク先が、勝手に変わっていないか
- Google Search Consoleに、セキュリティ関連の警告が出ていないか
- アクセスログやエラーログに、不審な記録がないか
不審な点を見つけたときは、自己判断でファイルを削除せず、ログを保存したうえで、保守担当者やサーバー会社に相談してください。削除してしまうと、原因や被害の範囲を調べられなくなることがあります。
また、更新後は、お問い合わせフォーム、会員ページ、決済など、事業に直結する機能が動くかの確認も欠かせません。更新後にフォームが動かなくなり、問い合わせのメールが届かない状態が続くと、気づかないうちに機会を失ってしまいます。
考察5｜WordPressサイトは、「5つの層」で考える
WordPressで作られたサイトでは、「WordPressを最新にしているから大丈夫」と考えている方が少なくありません。しかし、WordPress本体を更新しても、PHPのバージョンは変わりません。PHPは、サーバー側で動いているためです。
今年は、WordPress本体でも緊急の脆弱性が続きました。7月には、IPAがWordPressの2件の脆弱性（CVE-2026-60137、CVE-2026-63030）について対策情報を公開し、9月には、WordPress 7.1.2で、深刻度の高い脆弱性（CVE-2026-87902）が修正されています。そして10月が、今回のPHPです。サイトを守る対象が、1つではないことが、あらためて見えた1年でした。
WordPressのサイトを守るために確認が必要な「層」を、整理すると、次のようになります。
| 層 | 例 | 管理している人の例 |
|---|---|---|
| ① サーバー・OS | サーバーの契約、OS、Webサーバー | サーバー会社、または自社のインフラ担当 |
| ② PHP | PHPのバージョンと設定 | サーバー会社の管理画面、または保守会社 |
| ③ WordPress本体 | 7.1.x などのバージョン | 制作会社、保守会社、または自社 |
| ④ テーマ・プラグイン | デザイン、フォーム、SEOなどの機能 | 制作会社、保守会社、または自社 |
| ⑤ 運用ルール | バックアップ、更新の記録、連絡体制 | 自社（担当者を決める） |
この5つの層のうち、どれを誰が見ているのかが決まっていないと、今回のように「どこから手を付ければよいか分からない」状態になります。特に、①〜④を別々の会社が担当している場合は、窓口を一本化するだけでも、対応のスピードが大きく変わります。
WordPressのバージョンの確認方法や、セキュリティ更新とメジャー更新の考え方は、WordPressの緊急更新（CVE-2026-87902）と7.2への備えを解説した記事で整理しています。あわせてご覧ください。
これからの見通し｜確定していること、予測にとどまること
確定していること
- PHP公式は、CVE-2026-115560について、詳細なアドバイザリを次回のリリースで公開するとしています。それまでの対策として、
session.upload_progress.enabled=0の設定を推奨しています。ただし公式は、これを「可能性の低い攻撃経路への予防的な措置」としており、特殊な条件がそろった場合の話です。 - PHP 8.2のセキュリティサポートは、2026年12月31日で終了します。
- PHP 8.6.0は、リリース候補（RC）の段階で、次のRC5は2026年11月5日に予定されています。
予測にとどまること（当社の見立て）
ここからは、確定した事実ではなく、当社の見立てです。今回のように、広く使われている基盤に深刻な脆弱性が見つかる事案は、今後も起こりうると考えています。WordPress、PHP、そしてサーバーと、基盤が複数あるため、1年のうちに何度か「緊急の対応」が必要になる可能性は、あらかじめ織り込んでおくのが現実的です。
その場合、企業にできる備えは、「ニュースを全部追いかける」ことではなく、連絡を受け取る窓口と、作業を依頼できる先を、平時に決めておくことだと考えます。
今後のロードマップ｜優先度つきでやることを整理する
やることが多く見えますが、すべてを一度にやる必要はありません。優先度の高い順に、次の3段階で進めるのがおすすめです。
【優先度：高】今日〜今週中
- 自社のサイトやシステムが、PHPで動いているかを確認する（WordPress、EC-CUBE、問い合わせフォームなど）
- 契約しているサーバーの種類（レンタルサーバーか、VPSか）を確認する
- 契約中のサーバー会社の、PHP脆弱性に関する公式のお知らせを読み、対応状況を確認する
- 管理している会社（制作会社、保守会社、サーバー会社）に、対応状況を問い合わせる
- サポート終了版のPHP（8.1以前）で動いているサイトを、洗い出す
- 更新後の動作確認（フォーム、決済、会員ページ）を行う
【優先度：中】12月中（PHP 8.2のサポート終了前）
- PHP 8.2以前のサイトについて、PHP 8.3以上へ移行する計画を立てる
- テーマやプラグインが、移行先のPHPに対応しているかを確認する
- テスト環境で、先に動作を確認する
- サイトごとの「台帳」（管理者、PHPのバージョン、サポート期限）をつくる
【優先度：通常】来年以降、継続して行うこと
- PHPやWordPressのサポート期限を、年に1回は見直す
- 重大な脆弱性が出たときの、連絡と判断の流れを決めておく
- 更新の作業を、誰が・いつ行ったのか、記録を残す
- 改修の予算を、年度の計画の中に、あらかじめ確保しておく
IPAは、更新や移行のあとの維持管理の体制（人員、予算、保守）を確保しておくことが大切だと、今回の注意喚起の中で述べています。1回の対応で終わらせず、継続して守る仕組みにすることが、今回の事案の最大の教訓だと考えています。
サイトの「台帳」に書いておきたい項目
台帳といっても、難しいものではありません。表計算ソフトの1枚のシートで十分です。次の項目を、サイトごとに書いておくと、次に何かあったときの対応が早くなります。
| 項目 | 書く内容の例 |
|---|---|
| サイトの名前とURL | コーポレートサイト、採用サイト、サービスサイトなど |
| サーバーの契約先と種類 | レンタルサーバー、VPSなど。契約者と、更新日 |
| PHPのバージョン | 確認した日付も、あわせて記録する |
| PHPのサポート終了日 | 公式サイトで確認した日付 |
| WordPressのバージョン | 本体、テーマ、主要なプラグイン |
| 管理している会社と担当者 | 連絡先（電話、メール、休日の連絡方法） |
| 緊急時の判断者 | 誰の許可で、更新や一時停止を実施できるか |
PHPの脆弱性に関する、よくある質問
Q. サーバー会社が対応を完了したと発表しました。自分で何かする必要はありますか？
レンタルサーバーで、事業者が修正を適用している場合、PHPのバージョンの変更を急ぐ必要がないとしている会社が多くあります。ただし、サイトの表示、問い合わせフォーム、アップロードなどが正常に動くかの確認は、利用者側で行う必要があります。また、利用中のPHPがサポート終了版の場合は、今回の対応が応急的なものである点にも注意してください。
Q. VPSを使っています。何をすればよいですか？
VPSは、事業者がPHPを更新するとは限らず、利用者自身が、PHPのバージョンの確認と更新を行う必要があります。OSのパッケージでPHPを入れている場合は、OSの提供元の修正状況も確認してください。ご自身での作業が難しい場合は、早めに専門の会社に相談することをおすすめします。
Q. PHP 8.2を使っています。今回の修正版が出ているので、このままで大丈夫ですか？
今回の脆弱性については、PHP 8.2.35で修正されています。ただし、PHP 8.2のセキュリティサポートは2026年12月31日で終了します。それ以降は、新しい脆弱性が見つかっても、公式の修正が出なくなります。年内に、PHP 8.3以上への移行を計画することをおすすめします。
Q. 制作会社と連絡が取れません。どうすればよいですか？
契約書や請求書をたどると、サーバーの契約先や、管理している会社が分かることがあります。サーバーの契約者の情報があれば、サーバー会社の管理画面で、PHPのバージョンを確認できる場合もあります。それでも分からない場合は、現状を調べてくれる会社に、まず相談してみてください。
Q. 更新したら、サイトが動かなくなりました。
PHPのバージョンを上げたあとに、テーマやプラグインが古くてエラーが出ることがあります。まず、更新前のバックアップから元に戻せるかを確認し、そのうえで、原因となっているテーマやプラグインを調べる必要があります。元に戻した状態のままで放置すると、脆弱性が残ってしまうため、できるだけ早く、対応の方針を決めましょう。
PHPの脆弱性の確認・更新・保守体制づくりでお困りの企業様へ
マザーハンズ株式会社は、広島市中区で2017年から、ホームページの制作、WordPressの運用・保守、Web集客のご支援を行っています。PHPの脆弱性に関するご相談は、即日対応でお受けしています。
「PHPのバージョンが分からない」「制作会社と連絡が取れない」「サーバー会社に何を聞けばよいか分からない」「古いPHPのままのサイトをどうすればよいか相談したい」といった場合は、まずはご相談ください。
サイトの現状の確認から、移行の計画づくり、更新後の動作確認、そして日常の保守体制の整備まで、貴社の状況に合わせてご案内します。「どこに頼めばよいか分からない」という段階からで構いません。
ご相談は、お問い合わせフォームから承っています。
参考情報
- PHP公式サイト（ニュースおよびセキュリティアドバイザリ）
- PHP公式サイト：サポート対象のバージョン
- IPA：PHPの脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起
- エックスサーバー：PHPの脆弱性（CVE-2026-109618／CVE-2026-109619）に関するお客様のご利用サーバー環境への安全対策について
- ロリポップ！：PHPの脆弱性への対応に伴うメンテナンス完了と経緯のご報告
- さくらインターネット：PHPの脆弱性に関する当社の対応状況について
- KAGOYA：PHPの脆弱性に関する当社サービスへの影響について
- watchTowr：CVE-2026-109618のFAQ（英語）
- Unit 42：PHPの重大な脆弱性に関する脅威の概要（英語）
