PHPの緊急脆弱性とレンタルサーバー16サービスの修正状況、番号では見分けられない「完了」の中身

※本文は2026年10月23日20時時点の情報です。各社のお知らせは、いまも更新が続いています。

WordPress の管理画面でサイトヘルスを開いたら、PHP の欄に 8.3.35 と出ていた。ニュースで見た修正版は 8.3.36 だったはずなのに、うちのサーバー会社はまだなのだろうか。そう引っかかったまま、制作会社に聞いていいものか迷っている社長や Web 担当の方へ、続報をまとめます。御社のサーバー会社の「完了」がどの種類の完了なのかを表で引けるようにし、制作会社に聞く3つの確認と、返事の読み方を添えました。

21日の夜から22日の未明は、各社のお知らせを追いながら前回の記事の追記を書き足していました。23日、完了の報告がおおむね出そろったところで、保守先のサーバーに入り、PHP の置き場に残った時刻を告知と照らし合わせています。中を読んだのは wpX、エックスサーバー、XServerビジネス、ConoHa WING、お名前.com です。

wpX のサーバーでは、修正版 8.3.36 の置き場が22日の2時45分にできていました。開発元が修正版を出してから、4時間ほどの時刻です。

保守の会社としては、お客様に「サーバー会社が全部やってくれました、ご安心ください」と一行で報告するのが楽ですし、たぶん喜ばれもします。それでも照合までしたのは、各社の告知を並べてみると、その「完了」という一語に中身の違う修正がいくつも入っていたからです。

16サービスのうち13が、2日のうちに「完了」と書いた

調べたのは、国内で WordPress のサイトによく使われている共用のレンタルサーバー16サービスで、保守でお預かりしているサイトが使っているものも含みます。告知がサービスごとに出ているので、運営会社が同じものも別々に数えました。

修正版が出た直後の夜中に各社のサイトを見に行くと、エックスサーバーもロリポップも休止を知らせる画面で、お名前.com のサイトは「メンテナンス作業中」と出る1枚だけでした。外から様子を知りたい側には、もどかしい数時間です。

2日後の夜には、16のうち13が「完了」を告知していました。うちエックスサーバー系の3つ、それにスターサーバーは 5.5 以下を作業中として残していて、お名前.com の完了は3つのプランについての報告です。修正版の公開前から管理画面を閉じ、夜通し修正を流し込み、XREA のように日付が変わって1時間もしないうちに片付けたところもありました。「サーバー会社が入れてくれる」という共用サーバーの仕組みは、今回きちんと働いたわけで、そこは素直にありがたいと思っています。

10月23日20時時点の16サービス

表は、左の判定より右の列を見てください。判定の言葉は各社の告知に沿っていて、私たちの評価ではありません。wpX の行は、お知らせが出ていないので、保守先のサーバーの中で読んだ時刻を入れています。

各社のお知らせへのリンクは、末尾の「出典」にまとめました。

右の列を見比べると、同じ「完了」でも書きぶりがずいぶん違うのが分かると思います。修正版の番号を書くところ、番号は変わらないと書くところ、番号には触れないところ。現場で読み分けているのは、この違いなんです。

まだのところに乗っているなら、今日のうちに制作会社へ

「完了」の外にあるものと、「完了」の中で作業中として残っている系統は、次のとおりです。

• CPI: 新しいプランの 8.2〜8.4 だけに修正版を入れ、ほかの版と旧プランは、利用者の側で緩和策か、修正済みの版への切り替えを、と案内しています。
• KAGOYA: レンタルサーバープランは更新を終え、共用・マネージド専用・WordPress専用のプランは方針を調整中で、そのあいだの公開停止やアクセス制限の検討を求めています。
• エックスサーバー系とスターサーバーの 5.5 以下: エックスサーバーと XServerビジネスは、23日の夕方にほとんどのサーバーで適用を終えたと追記しました。シン・レンタルサーバーとスターサーバーは、修正パッチの作成と検証を進めている段階です。

wpX は別の扱いです。後で書くとおり、告知が出ていないだけで、サーバーの中には修正が入っていました。

御社のサイトがこのどれかに乗っているなら、次の告知を待たず、今日のうちに制作会社へ連絡してください。緩和策は設定ファイルを書き換える作業で、CPI はその作業のサポートはしないと書いています。サイトの中身を知っている制作会社に頼むのが安全です。

そもそも自社のサーバー会社がどこなのか分からず、ここで困る方もいると思うんです。サーバー会社からの請求書や、契約したときのメールの差出人を見るのが早く、見つからなければ制作会社に聞けばすぐ分かります。

「完了」の一語に、3種類の修正が入っている

では「完了」の中身は何なのか。いちばん詳しく書いているのは、ロリポップの経緯報告でした。

• 8.2〜8.5: 開発元が公開した修正版を、そのまま入れた
• 7.4〜8.1: 開発元がサポート終了の版向けに出した修正を入れた
• 5.3〜7.3: 開発元の修正は出ていないので、公式の修正内容をもとに自社で修正を作り、検証して適用した

同じ GMOペパボのヘテムルも、同じ分け方で書いています。真ん中は、JPCERT/CC の言い方を借りれば、開発元が出した「最小限」の手当てです。さらに両社は全部の版で PHP の一部の機能を無効にしていて、その機能を使うフォームやアップロードのあるサイトに、動作の確認を求めています。

前回の記事では、今回の修正を車のリコールにたとえました。メーカーが部品を出し、整備工場が付け替える、という話です。その続きで言えば、8.2〜8.5 はメーカーの純正部品、7.4〜8.1 はメーカーが生産の終わった型のために今回出した部品、7.3 以前はメーカーの図面をもとに、古い型に合わせて整備工場が作り直した部品、という並びになります。

7.3 以前の修正は開発元から出ていないので、表の「提供中の全版に適用」は、それぞれの会社の申告として読むことになります。作り方まで書いているのは、ロリポップとヘテムル（開発元の修正をもとに自社で作成）、mixhost（CloudLinux の修正パッケージ）、エックスサーバー系の3つとスターサーバー（公式の修正版や独自の修正）でした。申告を疑うつもりはありません。ただ、開発元が出した修正と、サーバー会社が作ったと申告している修正を、私たちは同じ重さには置いていません。

番号の上がる修正、番号の変わらない修正

前回の記事では、共用サーバーで入る修正を「入れてもらえる修正」と書きました。サーバーの中を読んでみると、その中身がさらに2つに割れていました。番号の上がる修正と、番号の変わらない修正です。

wpX を含むエックスサーバー系では、8.3 のサイトが使う PHP が、修正版の 8.3.36 に切り替わっていました。番号のきちんと上がる、素直な修正です。ところが同じサーバーでも、サポート切れの系統は番号がそのままで、末尾の枝番だけが増えていました。

ConoHa WING とお名前.com のサーバーはもっと分かりにくく、明け方に 7.4〜8.5 の7つの系統がすべて入れ替わっているのに、番号は修正前のままでした。冒頭のサイトヘルスの番号が、まさにこれです。番号だけを見ると驚くと思いますが、ConoHa WING の終報そのものが、これまでと同じ番号が表示される場合がある、と書いています。お名前.com、mixhost、ABLENET も番号を変えずに修正を取り込んだと告知していて、私たちが中で読んだ入れ替えの時刻とも食い違いはありませんでした。

番号を据え置いたまま修正だけを前の版へ移すやり方はバックポートと呼ばれ、Red Hat のような企業向け Linux の配布元が長く続けてきた作法です。ConoHa とお名前.com のサーバーは、中で見た PHP の置き場所から CloudLinux の仕組みだと分かり、その CloudLinux も、修正済みの番号は php.net の修正版より小さいことがあるとブログに書いていました。サーバーの世界では、番号は中身の新しさを示すものというより、系統の名札に近いんですよね。

だから現場では、サイトヘルスの番号で安心もしないし、心配もしません。見る先は、サーバー会社の完了のお知らせと、その日付です。

御社のサイトヘルスに出ていた番号は、修正版の番号でしたか、それとも前のままでしたか。前のままでも、表で「番号は変わらず」としたサービスなら、慌てなくて大丈夫だと思います。

お知らせの出ていないサービスは、中を読む

wpX のお知らせ一覧には、この件の告知が載っていません。同じエックスサーバー社が運営するエックスサーバーの告知も、対象のサービスにエックスサーバー、XServerビジネス、XServer for WordPress を挙げていて、そこに wpX の名前はありません。

こういうとき、保守の現場ではサーバーへ入って時刻を読みます。wpX のサーバーには冒頭の時刻に修正版が入っていて、エックスサーバーの告知にある作業の時間帯とも合っていました。お知らせの出る速さとサーバーの中の速さは、いつも揃うわけではありません。そのずれを、中を読むことで埋めています。

紛らわしいものは、ほかにもあります。スターサーバーの一覧に並ぶ「PHP 8.2〜PHP 8.5 アップデート」の完了は、修正版の一つ前の番号へ上げる定例の更新で、今回の修正とは別の告知です。見出しだけで取り違えると厄介なので、気をつけてください。

止まっていた数時間に、届かなかった問い合わせはないか

休ませ方も、サービスごとに違いました。エックスサーバーが休止したのは公式サイトと管理画面で、お客様のサイトの表示には影響がないとしています。ロリポップは22日の未明から昼過ぎまで、一部のサーバーでサイトの表示そのものを停止し、最新の系統のサイトや PHP を使っていないサイトまで見られなくなった、と経緯報告に書いています。

修正のためなら、それもひとつの判断だと思います。気になるのは、その数時間に送られてきたはずのものです。問い合わせフォーム、予約、ネットショップの注文。送ろうとした人が「送れなかった」と思って、そのまま別の会社に連絡していたら、と考えると少し怖い話です。

保守の現場では、サイトが休んでいた時間帯をサーバーの記録で確かめ、取りこぼしがあればお客様に知らせるところまでを、修正の後始末と考えています。御社のサイトは、あの日のどの時間帯に見られなかったでしょうか。制作会社から報告が無ければ、遠慮なく聞いてください。

余談ですが、この記事のためにエックスサーバーのお知らせを開いたときは、最初の何回かがエラーやタイムアウトで、読めたのは数分あとでした。お知らせには、サーバーパネルへのアクセスの集中が続いているという追記もあり、ロリポップも、問い合わせへの返答が遅れているとお詫びを出しています。いまはサーバー会社の窓口より、まず制作会社に寄せるほうが話は早いでしょうね。話を戻します。

悪用の試みは17日から、侵入の確認はまだない

私たちは、修正が入ったかどうかと同じくらい、修正が入る前の数日に何もなかったかを見るべきだと考えています。この穴を狙う動きは、公表より前から始まっていたからです。

Amazon は自社のおとりのサーバーで、10月17日にすでに試みを1件観測していたと発表しました。JPCERT/CC は注意喚起で、対策とあわせて、侵害されていないかの調査を求めました。NVD は2件のうち1件に10点満点で9.8をつけ、IPA の注意喚起では「PHP2shell」と呼ばれています。

一方で、侵入に成功した悪用を確認したと発表した公的機関や開発元は、この記事の時点でありません。ロリポップとヘテムルも、狙ったとみられるアクセスはあったものの、不正アクセスや情報漏えいは確認していないとしています。

見る目印は、前回の記事に挙げたものから変わりません。ユーザー一覧に覚えのない管理者が増えていること、会社名の検索結果に見知らぬ文字が混じること、そして取引先からの「メールが迷惑メールに振り分けられていた」という一言です。どれかに心当たりがあれば、保守の担当にサーバーの中を見てもらってください。

「完了」のあとにも続きがあります。開発元は23日の夕方（日本時間19時ごろ）、起こりにくい別の経路について追加のお知らせを出し、CVE-2026-115560 という別の番号を振りました。修正は緊急のリリースではなく次の定例のリリースに回され、それまでは PHP のある機能を切っておくよう呼びかけています。ロリポップとヘテムルは、その機能をすでに全部の版で無効にしています。

整備工場の部品は、次のリコールでも出てくるか

サポート切れの系統のサイトについて、私たちの見解を書いておきます。

今回は、手当てしてもらえました。これはありがたいことです。ただ、サポートの終わった系統には、本来、開発元の修正は出ません。7.4〜8.1 に修正が出たのは例外で、それは開発元自身が書いています。php.net は「Given the severity of these vulnerabilities」と前置きして最小限の修正を出し、JPCERT/CC も「脆弱性の深刻さを考慮し」と同じ事情を伝えています。7.3 以前は、その例外にも入っていません。

ロリポップとヘテムルの告知には、今後見つかる脆弱性では公式の修正が出ない、または自社で対応できない可能性がある、とあります。ロリポップは 8.1 以下の対策を「応急的なもの」とも書いていて、保守の目から見ても、その言葉どおりだと思います。

車のたとえに戻ると、生産の終わった型にまで整備工場が部品をこしらえてくれたのは、今回のリコールが特別に深刻だったからです。次のリコールでも同じ手間を引き受けてくれる保証は、どこにもありません。

各社の告知も、8.2 以上か 8.4 以降への切り替えをそろって促しています。私たちはもう一歩踏み込んで、乗り換えるなら 8.3 以上だと考えています。8.2 は今年の大晦日でセキュリティの修正が終わるので、いま移っても、2か月あまりでまた同じ相談をすることになるからです。それは避けたいですよね。

急ぎ方は系統で分けます。8.1 以前のサイトは、年内を待たずに段取りを組んでください。前回「年内に」と書いたのは 8.2 のサイトで、こちらはその予定のままで間に合います。前回は、修正が来ないかもしれないという心配から乗り換えを勧めました。今回は、修正が来たうえで勧めます。来た部品が、今回限りの特別な部品だったからです。

制作会社への確認は、今回は3つ

いま制作会社に聞くことは、次のとおりです。

• うちのサーバー会社の「完了」のお知らせはいつ出たか。うちのサイトの系統には、どの種類の修正が入ったか
• サイトが見られなかった時間に、届かなかった問い合わせや注文はないか
• 系統が 8.2 以前なら、乗り換えをいつにするか

メールで聞くなら、こんな書き出しで足ります。

先日の PHP の脆弱性の件で、サーバー会社から「完了」のお知らせが出たと聞きました。3点教えてください。①弊社のサイトの PHP の系統と、その系統に入った修正の種類（サーバー会社のお知らせの日付も） ②10月21日〜22日に、サイトや管理画面が見られなかった時間があったか、その間の問い合わせや注文に取りこぼしがないか ③系統が 8.2 以前の場合、8.3 以上への乗り換えの時期と費用の目安。お手数ですが、よろしくお願いいたします。

返事の最初の項目に「完了のお知らせの日付」と「うちの系統」が書いてあれば、それで十分です。系統さえ分かれば、上の表と図1で、どの種類の修正が入ったかを御社の側でも引けます。届かなかった問い合わせの件は、日がたつほど連絡をし直しにくくなるので、早めに返事をもらいたいところです。

wpX のようにお知らせの出ていないサーバーや、番号だけでは判断がつかない場合は、HOMELY のお問い合わせからサーバー会社の名前を添えてご相談いただければ、サーバーの中を読んで告知と照らし合わせます。

出典

• 出典（各社のお知らせ。10月23日20時16分〜25分に取得、エックスサーバー・XServerビジネスは20時44分に取り直し）: エックスサーバー／XServerビジネス／シン・レンタルサーバー／wpX のお知らせ一覧／スターサーバー／ロリポップ／ヘテムル／ConoHa WING／お名前.com／さくらのレンタルサーバ／カラフルボックス／mixhost／XREA／コアサーバー／ABLENET／CPI／KAGOYA
• 出典（公的機関・開発元ほか）: JPCERT/CC 注意喚起／IPA 注意喚起／NVD CVE-2026-109618／php.net のお知らせ（2026年）／Amazon の発表／CloudLinux のブログ