「PHPに重大な問題って、うちのブログも危ないのかな?」
「管理画面に入れないけど、サイトまで止まってる?」
10月21日の夜に修正版が出たPHP2Shell。WordPressでブログやホームページを運営している人にとっても、気が気じゃない出来事でしたよね。
各社の公式発表を片っ端から読んでみると、22日の未明に提供中のPHPを全部直し終えたところもあれば、23日になっても一部のプランで「恒久的な対応は調整中」と案内していたところもありました。
ただ、「何時に終わったか」だけ見ても、本当の違いは見えてきません。
新しいPHPだけ直したのか、古いPHPまで直したのか。止まったのはサーバー会社の管理画面だけなのか、自分のサイトまで止まったのか。このあたりも一緒に比べてみました。
※2026年10月24日に確認した公開情報をもとにしています。時刻は日本時間です。各社の作業内容や、修正がちゃんと効いているかを私が独自に検証したわけではありません。
PHP2Shellで対応が早かったサーバーはどこ?各社の公式発表を調べて比べてみた【2026年10月】
PHP2Shellって何?WordPressの人にも関係ある?
PHPは、サイトの裏側で働く「調理担当」のようなものです。サーバーの中で動くプログラミング言語で、WordPressもPHPで動いています。
お店にたとえるなら、読者が見る記事ページが「料理」、WordPressが「料理を作る仕組み」、PHPがその仕組みを動かす「調理担当」です。
今回の問題は、その調理担当そのものの弱点でした。だから、WordPressやプラグインを最新にしても、土台のPHPは直りません。
問題は2件あって、CVE-2026-109618とCVE-2026-109619という番号が付いています。CVEは、セキュリティ上の弱点を取り違えないための、世界共通の整理番号です。
悪用されると、ログインしていない第三者に、サーバー上で勝手に命令を実行されてしまうおそれがあります。
専門用語では「リモートコード実行(RCE)」といいます。受付を通していない人の指示が、裏の作業場まで届いてしまうようなものです。
修正版は、PHP 8.2.35、8.3.36、8.4.27、8.5.12です。PHP公式は「完全な応急処置はなく、更新が唯一の安全な選択肢」と案内しています。
しかも、攻撃の試みは修正版が出る前から始まっていました。Amazonは、公開の4日前にあたる10月17日に、悪用の試みを観測していたと公表しています。
台風が来る前に雨戸を閉めるように、修正版の公開前から止まったサイトが多かったのは、そのためです。
比較の前に「直し終わった時刻」と「営業再開の時刻」を分けよう
各社が発表した時刻には、実はいくつか種類があります。
- PHPの修正が終わった時刻
- 更新作業ぜんぶが終わった時刻
- お客さんのサイトが、また見られるようになった時刻
- 管理画面やWebメールが戻った時刻
お店でいえば、「壊れた設備を直し終えた時刻」と「入口を開けて営業を再開した時刻」は別ものですよね。
しかも、新しいPHPが先に直って、古いPHPが後から終わった会社もあります。なので、単純な順位は付けていません。何が、どこまで終わった時刻なのかを表に添えました。
完了・再開の時刻を、早い順に並べてみた
10月22日の分を、時刻の早い順に並べています。
| 日時 | サーバー | 何が終わった時刻か | お客さんのサイト |
|---|---|---|---|
| 22日 0:50 | コアサーバーV1・バリューサーバー・XREA | 更新作業が完了。提供中の全PHP版(5.3〜8.5)に修正を適用 | 停止の告知なし |
| 22日 6:30 | さくらのレンタルサーバ等 | 更新作業が完了(21日23:00から作業)。選べる全PHP版に対応 | 止めず(数秒の接続断の案内のみ) |
| 22日 6:45 | エックスサーバー | PHP 8.2〜8.5の修正が完了 | 止めず(公式サイトと管理画面は21日16:00から停止) |
| 22日 朝まで | カラフルボックス | 全サーバーで更新が完了 | 止めずに更新と告知 |
| 22日 10:18ごろ | mixhost | PHP 5.2〜8.5の修正が完了 | 止めずに更新と告知 |
| 22日 10:20 | Oneレンタルサーバー | 提供中の全PHP版(5.6〜8.5)に修正を適用 | 停止の告知なし |
| 22日 11:13 | コアサーバーV2 | 提供中の全PHP版(5.2〜8.5)に修正を適用 | 停止の告知なし |
| 22日 11:24 | ヘテムル | 修正後に、お客さんのサイトの表示を再開(停止は3:05ごろから) | 約8時間、一部サーバーで停止 |
| 22日 12:00 | エックスサーバー | PHP 7.4〜8.1の修正が完了 | 止めず |
| 22日 13:00ごろ | ロリポップ! | 修正後に、お客さんのサイトの表示を再開(停止は3:09ごろから) | 約10時間、一部サーバーで停止 |
| 22日 14:00 | エックスサーバー | PHP 5.6〜7.3の修正が完了 | 止めず |
| 22日 14:23 | ムームーサーバー | サイトが閲覧できる状態に。15:36に全作業が完了 | 一時停止していた |
| 22日 20:45 | ConoHa WING | 提供中の全PHP版(5.6〜8.5)の修正と、メンテナンスが完了 | 管理機能などを一時停止 |
| 22日 24:00まで | KAGOYA(レンタルサーバープランのみ) | 14:40〜24:00に順次アップデート。完了の報告は23日12:30 | 事業者側では止めず |
| 確認できず | お名前.com レンタルサーバー | 22日の告知では「順次適用中」。完了時刻は確認できませんでした | サイト表示は通常どおりと案内 |
見るときの注意点が3つあります。
カラフルボックスは、公式に「朝まで」とあるだけで、分単位の時刻が確認できません。なので、前後関係は目安です。
同じ時刻でも、止めずに更新した会社と、いったん止めて更新した会社では意味が違います。表の右端の列も一緒に見てください。
あと、これは確認できたサービスの比較です。国内の全社を網羅した最速ランキングではありません。
PHP脆弱性への各社の対応を、もう少し詳しく
夜のうちに終わらせた会社
コアサーバーV1、バリューサーバー、XREA
コアサーバーV1、バリューサーバー、XREAは、22日の0時50分に更新作業を終えています。今回調べた中では、一番早い完了です。
公式は、提供しているPHP 5.3〜8.5の全バージョンに修正を適用したと案内しています。同じ系列でも、Oneレンタルサーバーは10時20分、コアサーバーV2は11時13分でした。会社名で一括りにすると、この差を見落としてしまいます。
さくらのレンタルサーバ・マネージドサーバ
さくらのレンタルサーバ・マネージドサーバは、21日23時から22日6時30分までの作業で、案内された接続断は数秒程度でした。
選べる全PHPバージョンに対応していて、利用者側の緊急対応は不要という説明です。店を開けたまま、気づかれないくらいの速さで鍵を取り替えたような印象でした。ただ、ウェブメールなどは別に復旧していて、すべての機能が6時30分に戻ったわけではありません。
エックスサーバー
エックスサーバーは、お客さんのサイトを動かしたまま修正を進めました。完了時刻はPHPの世代ごとに違います。
8.2〜8.5が22日6時45分、7.4〜8.1が12時、5.6〜7.3が14時です。5.5以下は、23日の昼の時点でも修正パッチを作成・検証中でした。
一方で、公式サイトや管理画面は21日16時から止まっています。再開後はアクセスが集中して、サーバーパネルがつながりにくい状況も続きました。「ブログは見られるのに、設定画面には入れない」という状態があったわけです。
カラフルボックス
カラフルボックスは22日の朝までに、mixhostは10時18分ごろに、それぞれ完了しました。
カラフルボックスは古いPHPも含めて対応済みで、利用者のバージョン変更は不要という案内です。mixhostはPHP 5.2〜8.5が対象で、表示上のバージョン番号を変えずに修正を入れました。
ConoHa WING
ConoHa WINGの完了は、22日20時45分でした。提供中の全PHPバージョンを対象に、修正を入れたと案内しています。
順次作業を進めていたので、それまで全部が未修正だったとは限りません。ただ、全体の完了を確認できる時点としては、朝から昼に終えた会社より後になります。
「番号が古いまま」でも修正済み?バックポートを知っておこう
mixhostやConoHa WINGなどは、PHPの番号を変えずに修正を入れました。こういう方法を「バックポート」と呼びます。
古い型の家電に、不具合を直した部品だけを取り付けるようなものです。型番は同じでも、問題の部品は交換されています。
だから、WordPressのサイトヘルスで「8.4.26」と出ていても、それだけで未対応とは決められません。確認するのは、契約中のプランと使っているPHPが、公式告知の対応範囲に入っているかどうかです。
サイトをいったん止めて直した会社
ロリポップ!とヘテムルは、お客さんのサイトを止める方法を選びました。
ヘテムルは22日の3時5分ごろに停止して、11時24分ごろに再開。ロリポップ!は3時9分ごろに停止して、13時ごろに再開しています。止まっていた時間は、ヘテムルが約8時間、ロリポップ!が約10時間です。
両社とも、停止の理由を公式に説明しています。
古いPHPには公式の修正版がなく、自社で修正を作って検証する間、設定による対策だけでは攻撃を完全には防げないおそれがあったこと。そして、脆弱性を狙ったとみられるアクセスが、実際に確認されていたことです。
ただし、不正アクセスや情報漏えいは、現時点で確認されていないとしています。
ここで知っておきたいのは、停止がサーバー単位だったことです。両社は「個別に切り分けるより、全員を速く守ることを優先した」と説明しています。
そのため、PHP 8.2以降を使っているサイトや、PHPを使っていないサイトも、同じように見られなくなりました。
予約フォームや広告の飛び先が開かない時間は、運営者にとっては痛いはずです。一方で、危険にさらされる時間を減らすという意味はあります。どちらが正解とは、簡単には言えません。
「じっくり直したから、他社より確実」とまでは言えない点も、念のため書いておきます。各社の修正を、外から検証したわけではないからです。
ムームーサーバー等は、22日14時23分にサイトが見られる状態になり、15時36分に全作業の完了を告知しました。
一部のプランで、翌日まで調整が続いた会社
KAGOYAのレンタルサーバープランは、22日の14時40分〜24時に対象のPHPを順次更新して、23日12時30分に完了を報告しています。
ただ、マネージド専用、共用、WordPress専用のプランは、その時点でも「恒久的な対応は調整中」でした。
恒久的な対応というのは、応急処置でしのぐ段階から進んで、問題の原因そのものを直す対応のことです。その間は、サイトの公開停止(メンテナンス画面への切り替え)やアクセス制限を検討してほしい、という案内でした。
ここは「KAGOYAが一番遅かった」と決めつけたくないところです。プランによって状況がまったく違うからです。
理由や内部の事情までは、公開情報からはわかりません。確認できた事実は、一部のプランで、他社の完了報告後も方針の調整が続き、利用者側にも公開を続けるかどうかの判断が求められた、というところまでです。
お名前.comレンタルサーバーは、22日の告知で、PHPのバージョンを維持したままセキュリティパッチを順次適用すると案内していました。
サイトの表示やメールは通常どおり使えて、ファイルマネージャーやphpMyAdmin、Webメールは予防的に止めていたそうです。
完了時刻は確認できませんでした。5系や7系を使っている場合は、バージョン変更が必要になることもあるとのことなので、公式のお知らせを直接確認してください。
23日にまた別の話が出た:CVE-2026-115560
実は、21日の修正で話が終わったわけではありません。23日に、PHP側から追加の案内が出ています。
CVE-2026-115560という別の番号で、「起きる可能性は低いけれど、リモートコード実行につながるかもしれない経路」という扱いです。
条件はかなり限られます。サーバーの設定で、セッションの保存形式が特定の種類になっていて、プログラムが動いている途中でその形式を元に戻していて、しかもアップロード進捗の機能が有効なまま、という組み合わせのときです。
ふつうのブログで、この条件が全部そろうことは多くないと思います。
PHPの案内は、次の通常リリースまで、session.upload_progress.enabledを0にしておくことです。21日に出た修正版では、この件は直っていません。
ロリポップ!とヘテムルがアップロード進捗の機能(session.upload_progress)を無効にしたのは、この流れです。
利用中のサーバーが追加の案内を出していないかも、あわせて見ておくと安心です。
並べてみて思うこと
今回確認できた範囲で、完了の早さが目立ったのは、未明に全提供版を終えたコアサーバーV1・バリューサーバー・XREAと、早朝に終えたさくらです。
エックスサーバーも、新しいPHPには早朝に対応しました。そのうえ、古いPHPの進み具合を、世代別に公表していました。
一方で、止めた会社は止めた分の理由と再開時刻が大事になります。「いつ再開するのかわからない」のは、運営者にとっていちばん不安ですから。
ただし、この比較は「世間の評判がどうだったか」を示すものではありません。今回の一件だけで、各社のセキュリティ全体を順位付けするのも無理があります。
古いPHPを使っているなら、これを機に見直しを
PHP 8.1以下は、公式の通常サポートがすでに終わっています。
今回は例外的に、7.4・8.0・8.1向けの最小限の修正コードが出ました。サーバー会社の多くは、それを使うか、独自に修正して対応しています。
でも、これは応急処置です。期限切れの保険に入り続けるようなもので、次の脆弱性が出たときに、また同じように直してもらえる保証はありません。ロリポップ!もヘテムルも、PHP 8.2以降への切り替えを呼びかけています。
まとめ:PHP脆弱性への対応が早かったサーバーは?自分のサイトで確認したいこと
まず、契約しているサービス名とプラン、使っているPHPのバージョンを整理してみてください。
同じ会社でも、新旧のプランやPHPの版によって対応が分かれていました。複数のサイトを運営している場合は、ドメインごとに見ていくと取りこぼしが減ります。
更新後は、記事が表示されるかだけでなく、お問い合わせフォーム、ログイン、画像やファイルの送信も動かしてみてください。アップロード進捗の機能を止めた会社があるので、その機能に頼っているサイトは特に注意です。
不審なファイルや動きに気づいたら、サーバー会社や保守の担当者に相談しましょう。サイトへのアクセスやエラーの記録(ログ)は、防犯カメラの映像のように、調べるときの手がかりになります。
ただ、JPCERT/CCも、痕跡が見つからないだけで攻撃を受けていないとは言い切れないと注意しています。しかも攻撃の試みは17日から確認されているので、見る範囲は21日からでは足りません。
あと、自分でVPSを借りて管理している人は、ここまでの共用サーバーとは話が違います。
共用サーバーが「設備の管理を大家さんに任せる部屋」なら、VPSは「室内の設備を自分で管理する部屋」です。契約先の共用サーバーが対応済みでも、自分のVPSの中のPHPまで更新されたとは限りません。
今回差が出たのは、修正の早さだけではありませんでした。どこまで対応したのか、何が使えないのか、利用者は何をすればいいのか。その説明のわかりやすさにも、差がありました。
「対応済みです」の一言から、自分のサイトが入っているかがわかるかどうか。緊急時のサーバー選びでは、そんな告知の書き方も、判断材料になりそうです。
参考にした公式情報
PHP公式(2026年10月21日の告知):https://www.php.net/archive/2026.php#2026-10-21-5
JPCERT/CC 注意喚起:https://www.jpcert.or.jp/at/2026/at260033.html
ロリポップ! 経緯のご報告:https://lolipop.jp/info/news/8239/
ヘテムル 経緯のご報告:https://heteml.jp/info/detail/id/2954/
エックスサーバー:https://www.xserver.ne.jp/news_detail.php?view_id=19734
KAGOYA:https://www.kagoya.jp/news/2026102337094/
Value-domain(コアサーバー・バリューサーバー・XREA・Oneレンタルサーバー):https://www.value-domain.com/information/detail/?no=20261022-1
お名前.com:https://www.onamae.com/news/article/11591/
コメント