2026年10月21日に修正版が公開されたPHPの重大な脆弱性(CVE-2026-109618・CVE-2026-109619。通称php2shell)は、PHP本体(WordPressなど多くのホームページを動かしている土台のプログラム)の弱点だったため、サイト側では防げず、サーバー会社の対応を待つしかない一件でした。エックスサーバーの管理画面停止から修正の適用完了まで、2日ほどで一区切りがつきました。この記事は、2026年10月25日時点の公式発表をもとにした「一旦の総括」です。
何が起きてどう収まったかを振り返ったうえで、インターネットの仕組みの限界、WordPressがPHPに頼っている構造、これからの作り方、中小企業のサイトの備えを順に整理します。第4章の「次の仕組み」は当社の予想であり、事実とは分けて書いています。個々の手順はPHPの重大な脆弱性の解説記事とエックスサーバー利用者がやることの記事にまとめているので、この記事では繰り返しません。
何が起きて、どう収まったか(10月21日〜23日)

要点は3つです。「修正版の公開前に中身が漏れ、国内では予防的にサービスを止める判断が広がった」「修正版が出た翌朝までに、主要なレンタルサーバーでサポート中のPHPへの適用が終わった」「サポートが終わった古いPHPにも、サーバー会社が独自に手当てをした」。日付ごとに追います。
10月21日|予告、漏えい、予防停止
PHPの開発チームは前日の10月20日に「10月21日の日本時間23時に重大な修正版を出す」と予告していました。ところが公開前に弱点の中身が外部に漏れ、IPA(情報処理推進機構。国が設けた、企業や個人にセキュリティの注意を呼びかける機関)は21日のうちに事前準備のお願いを出しました。エックスサーバーは21日12時までに攻撃のリスクを下げる暫定の対策を入れ、16時には公式サイトと管理画面を予防的に停止しました。お客様のサーバー自体は動き続け、サイトの表示やメールには影響がなかったと公式は説明しています。BASEやロリポップ!など、修正版が出るまで自ら止める判断をした会社も相次ぎました。この日の全体の流れは10月21日のまとめ記事に詳しく書いています。
10月22日|修正版の適用と、管理画面の再開
修正版(PHP 8.5.12、8.4.27、8.3.36、8.2.35)は21日23時ごろに公開されました。PHP公式の告知は「完全な回避策はなく、更新だけが安全な選択」と言い切っています。エックスサーバーは22日1時10分に8.2〜8.5への適用を始めて6時45分に完了し、9時30分から管理画面を順次再開、午後には7.4〜8.1と5.6〜7.3の適用も終えました(時刻は下の表)。さくらインターネットも同日、さくらのレンタルサーバで選べる全バージョン(8.3〜5.2)の修正を終えたと告知しています。IPAは同じ22日に対策の注意喚起を出し、PHP 8.1以前はサポートが終わっているため修正が出ないこと、修正が難しければアクセス制限や一時停止も選択肢であることを示しました。
10月23日|古いバージョンへの対応と、アクセス集中
エックスサーバーは23日17時の時点で、PHP 5.1〜5.5についても対象サーバーの過半数で修正を終えたとしています。同日13時15分の追記では、管理画面の再開後にアクセスが集中してサーバーパネルが開きにくい状況が続いていること、PHP 5.6〜8.5を使っている人は今回の対策として急いでバージョンを変える必要はないことが案内されました。公式のお知らせは25日時点でもこの23日の内容が最新です。なお、PHP公式は23日に「session.upload_progress という設定を無効にしておくことを勧める」という追加の注意も出していて、関連する修正は次の定期リリースで行うとしています。土台側の手当てはまだ続いている、ということです。
| 日時(日本時間) | 出来事 | 出典 |
|---|---|---|
| 10月20日 | PHP公式が重大な修正版の公開を予告(CVSS 9.2が2件) | PHP公式 |
| 10月21日 〜12時 | エックスサーバーが暫定の緩和策を適用 | エックスサーバー |
| 10月21日 16時 | エックスサーバーが公式サイト・管理画面を予防停止 | エックスサーバー |
| 10月21日 23時ごろ | 修正版 8.5.12/8.4.27/8.3.36/8.2.35 と詳細が公開 | PHP公式 |
| 10月22日 6時45分 | エックスサーバー、8.2〜8.5の適用完了 | エックスサーバー |
| 10月22日 9時30分〜 | エックスサーバー、管理画面を順次再開 | エックスサーバー |
| 10月22日 12時/14時 | エックスサーバー、7.4〜8.1/5.6〜7.3の適用完了 | エックスサーバー |
| 10月22日 | さくら、選べる全PHPバージョンの修正完了。IPAが対策の注意喚起 | さくら/IPA |
| 10月23日 17時 | エックスサーバー、5.1〜5.5の過半数で適用完了 | エックスサーバー |
サーバー会社ごとの対応の差
結果として主要なレンタルサーバーはどこも修正を終えましたが、進め方には差がありました。差が出たのは「止めたかどうか」「理由をはっきり書いたか」「古いバージョンまで手当てしたか」の3点です。エックスサーバーは管理画面を止めて2時間ごとを目安に進捗を公開し、サポート終了版にも独自の修正を当てました。さくらは当初の緊急メンテナンスの告知に理由を書かず、22日に対応完了の告知で全バージョンの修正を明らかにしました。ロリポップ!は停止の理由をいちばん明確に書き、ConoHa WINGとmixhostは「保守作業」「予防的なセキュリティ強化」という表現で、PHPという言葉は使っていません(いずれも10月22日朝の告知の時点)。各社の最新状況と利用者の確認手順は、さくら、ロリポップ!、ConoHa WING、mixhostの各記事で追っています。
当社が制作・管理しているお客様のサイト(エックスサーバー)についても、修正済みのPHPに入れ替わっていることを直接確認し、お知らせとして公開しています。
今回の件で見えた、インターネットの仕組みの限界

要点は、「ホームページは何層もの部品の上に乗っていて、下の層に穴があると上の層では防げない」ということです。これは今回に限らない構造の話なので、少し整理しておきます。
土台に穴があると、上で動くサイトは自力では防げない
ホームページは、おおまかに「サーバーの機械」「OS(基本のソフト)」「PHPのようなプログラムを動かす土台」「WordPressなどの仕組み」「テーマやプラグイン」「記事や画像」という層の積み重ねでできています。今回の弱点はPHPの層にあり、WordPressが動き始める前の、通信を受け取って読み解く段階で起きるものでした。だからWordPress本体やプラグインを最新にしても防げず、PHP本体を入れ替えるしか直せません。家にたとえると、鍵をいくら強くしても、基礎にひびが入っていれば家そのものが危ない、という状態です。
共用レンタルサーバーでは「サーバー会社頼み」になる
中小企業のサイトの多くが使う共用レンタルサーバー(1台の機械を多数の契約者で分け合う形)では、PHP本体の入れ替えはサーバー会社しかできません。利用者ができるのは「お知らせを読む」「自分が選んでいるバージョンを確かめる」「必要なら切り替える」までです。これは不便なようですが、裏返せば、今回のように深夜から朝にかけて一斉に修正してくれる相手がいる、ということでもあります。自分でサーバーを管理するVPS(仮想の専用サーバー)では、エックスサーバーも「修正パッチの適用は行っていない」と明記していて、更新は利用者の責任です。どちらが良い悪いではなく、「誰が土台を直すのか」が契約の形で決まっている、と理解しておくことが大切です。
古いバージョンを使い続けるリスクが、具体的な形で現れた
PHPはバージョンごとにサポート期間が決まっていて、PHP公式の一覧では7.4は2022年11月28日、8.0は2023年11月26日、8.1は2025年12月31日に終了しています。今回、開発チームが正式な修正版を出したのは8.2以上だけで、8.1以前には「更新は提供しない」と明記しました(7.4・8.0・8.1向けには、自分で組み立てる人向けに最小限の修正のソースコードだけが公開されています)。エックスサーバーやさくらが古いバージョンにも独自の手当てをしたのは、事態の深刻さを考えた例外的な対応です。次に同じ規模の弱点が見つかったとき、同じ対応がされる保証はありません。「サポートが終わる」とは、こういう場面で取り残される可能性がある、という意味です。
「止める」が現実の選択肢になった
IPAの対策の注意喚起には、更新が難しい場合はアクセスを制限し、必要なら更新が終わるまでサービスを停止することも挙げられています。実際に21日は多くの企業が「修正版が出るまで止める」を選びました。売上や問い合わせに直結する停止を多くの会社が選んだという事実は、インターネットの土台がどれほど共通の部品に頼っているかを示しています。
WordPressはPHPに依存している、という構造
要点は、「WordPressはPHPで書かれたプログラムであり、PHPなしでは動かない。別の言語への乗り換えは、公式には言われていない」です。ここは事実として確認できることと、言われていないことを分けて書きます。
WordPressはPHPで書かれている(事実)
WordPress公式の紹介ページには「今日のWordPressはPHPとMariaDB(データベース)の上に作られている」と書かれています。記事を表示するとき、管理画面を開くとき、プラグインが動くとき、そのすべてでPHPが働いています。だからPHPの土台に弱点があれば、WordPressのサイトは例外なく影響を受けます。WordPressそのものの仕組みはWordPressとは何かを解説した記事で説明しています。
WordPressが求めるPHPのバージョン(事実)
WordPress公式の動作環境では、推奨はPHP 8.3以上、データベースはMariaDB 10.11以上またはMySQL 8.0以上です。古い環境ではPHP 7.4以上でも動きますが、公式は「サポートが終わったバージョンで、サイトを危険にさらすおそれがある」と注意を添えています。開発チームの2026年1月の発表によると、2026年5月20日公開のWordPress 7.0でPHP 7.2・7.3のサポートが打ち切られ、最低は7.4になりました。同じ発表に載っている利用状況(2026年1月時点)を足し合わせると、調べられたWordPressサイトのうちPHP 8.1以前で動いているものが約47%あります。つまり今回「正式な修正版が出なかった側」に、WordPressサイトのおよそ半分がいた計算です。
| PHPのバージョン | PHP公式のサポート(2026年10月時点) | WordPress公式の扱い |
|---|---|---|
| 8.5/8.4 | 通常のサポート中(8.4は2026年末まで、以後はセキュリティ修正のみ) | 推奨(8.3以上) |
| 8.3 | セキュリティ修正のみ(2027年12月31日まで) | 推奨 |
| 8.2 | セキュリティ修正のみ(2026年12月31日まで) | 動作する |
| 8.1/8.0/7.4 | サポート終了(今回の正式な修正版なし) | 7.4以上なら動くが、公式が注意を添えている |
| 7.3以前 | サポート終了 | WordPress 7.0以降は動かない |
WordPressが別の言語に乗り換える可能性|公式に言われていること
公式の情報として確認できるのは次の3点です。1つ目は、編集画面(ブロックエディター)はJavaScriptで作られていることです。開発者向けの公式資料では、ブロックの開発に新しいJavaScript(ESNextやJSX。JSXはReactというJavaScriptの仕組みから生まれた書き方)を使うと説明されています。2つ目は、2015年の年次講演でWordPressの創業者マット・マレンウェッグ氏が「JavaScriptを深く学ぼう」と呼びかけたことで、これは複数のメディアが報じています。3つ目は、WordPress Playgroundという公式の実験的な仕組みがあり、公式ページは「WebAssembly(ブラウザの中でプログラムを動かす技術)を使い、すべてブラウザ側で動く」と説明しています。つまりWordPressは、表示や編集の部分でJavaScriptの比重を上げ、PHPをブラウザの中で動かす実験までしています。
公式に言われていないこと
一方で、「WordPress本体をPHP以外の言語で書き直す」という計画や時期は、公式のロードマップのどこにも書かれていません。ロードマップに載っているのは、編集・カスタマイズ・共同作業・多言語という4段階の機能の計画と、2026年12月10日予定のWordPress 7.2までの日程です。Playgroundも、PHPを捨てる話ではなく、PHPをそのままブラウザで動かす仕組みです。したがって、2026年10月時点で「WordPressがPHPから離れる」と言える公式の根拠はありません。インターネット上で見かける「WordPressは近くPHPをやめる」といった話は、現時点では公式の裏付けのない見立てです。
次の言語・仕組みはどうなるか(ここからは当社の予想)

この章は、制作会社としての予想です。確定した事実ではなく、外れる可能性もあります。それでも、今回の件を受けて「作り方の選択肢」を考えるお客様が増えると思うので、当社が見ている方向を4つ書きます。
予想1|「表示だけのサイト」に戻る動きが強まる
会社案内のように更新が年に数回のサイトなら、サーバーでプログラムを動かさず、できあがったHTMLと画像だけを置く「静的サイト」で十分なことが多くあります。サーバー側で動くプログラムがなければ、今回のようなPHPの弱点に直接さらされる面は小さくなります。問い合わせフォームだけは外部のフォームサービスを使う、という組み合わせです。当社がVercelの解説記事で紹介したような置き場所は、この作り方と相性が良いと見ています。ただし「更新画面がない」ので、更新のたびに制作会社に頼むか、別の仕組みを足す必要があります。
予想2|WordPressを裏方に回す「ヘッドレス」が中規模で増える
ヘッドレスとは、WordPressを記事の保管と編集だけに使い、見せる画面は別の仕組みで作る方法です。WordPressは外から見えない場所に置けるので、攻撃の入口を減らせます。更新画面を残しつつ土台を守りたい、という中規模のサイトで選ばれる場面が増えると予想しています。弱点は、作れる制作会社が限られることと、2つの仕組みを保守する分だけ費用がかかることです。
予想3|JavaScript・TypeScript系の比重が上がるが、PHPは消えない
新しく作られるWebの仕組みは、JavaScriptやTypeScript(JavaScriptに誤りを防ぐ仕組みを足した言語)で書かれるものが増えていて、WordPress自身も編集画面はJavaScriptです。この流れは続くと見ています。ただし、言語を変えれば弱点がなくなるわけではありません。どの言語の土台にも定期的にセキュリティの修正が出ていて、「更新を誰がいつやるか」という問題はそのまま残ります。既存サイトの多くがPHPで動いている以上、PHPが数年で消えることは考えにくいと見ています。
予想4|「更新をまとめて引き受ける」サービスが選ばれる
WordPress専用のサーバーや、ホームページ作成サービス(WixやStudioなど、仕組みごと提供側が面倒を見る形)は、土台の更新を利用者が意識しなくてよい点で、今回のような場面に強いと見ています。実際、Studioの記事で確認したように、PHPを使っていないサービスでは利用者側の作業はありませんでした。引き換えに、デザインや機能の自由度は下がり、サービスの都合(料金改定や終了)に左右されます。「自由に作る」と「面倒を任せる」の間で、どこに立つかを決める時代になる、というのが当社の見立てです。
| 作り方 | 土台の更新を担う人 | 向いているサイト | 注意点 |
|---|---|---|---|
| WordPress+共用レンタルサーバー | PHPはサーバー会社、WordPress・プラグインは利用者か保守会社 | 更新が多い中小企業サイト全般 | 古いPHPを選んだままにしない。保守の担当を決める |
| WordPress専用のマネージド型 | ほぼ提供会社 | 更新は多いが運用に手をかけたくない | 費用が上がる。細かな設定の自由度は下がる |
| 静的サイト(HTMLのみ)+外部フォーム | 置き場所の会社(更新対象が少ない) | 更新が年数回の会社案内 | 更新のたびに制作側の作業が要る |
| ヘッドレス(WordPressを裏方に) | 2つの仕組みをそれぞれ | 更新画面を残しつつ入口を減らしたい中規模 | 作れる会社が限られ、保守費が増える |
| ホームページ作成サービス | 提供会社 | 小規模・まず持つことが目的 | デザインや機能の制限。サービス都合の変更 |
中小企業のサイトは今後どう備えるか

要点は、「土台は自分で直せないが、土台の状態を知り、直す人を決め、直しやすい形にしておくことはできる」です。今回の件が落ち着いた今のうちに、次の5つを進めておくことをおすすめします。
ステップ1|バージョンの棚卸しをする
会社案内、採用サイト、ネットショップ、昔のキャンペーンページまで、運用中のサイトを一覧にし、それぞれ「どのサーバー」「PHPのバージョン」「WordPressのバージョン」「管理している人」を書き出します。WordPressなら管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」で、レンタルサーバーなら管理画面のPHPバージョン設定で確かめられます。確認の仕方はPHPのバージョンの基礎記事にまとめています。制作の現場では、本体のサイトは8.3なのに、放置された古いサブドメインのサイトが7.4のまま、という例をよく見ます。
ステップ2|「誰が更新するか」を契約で決める
サーバー会社がPHP本体を直してくれても、WordPress本体・テーマ・プラグインの更新、PHPのバージョンを上げる作業、上げたあとに崩れたときの修正は、誰かがやらなければ進みません。制作会社と保守契約を結んでいる場合は、その範囲に「PHPのバージョン切り替え」と「切り替え後の動作確認」が入っているかを確認してください。入っていなければ、都度の依頼にするか、契約に足すかを決めます。IPAの注意喚起にも、経営層・予算・保守の担当者を含めて計画するようにと書かれています。
ステップ3|サーバー会社を「告知」と「古い版の扱い」で選ぶ
今回の対応を見て、サーバー会社を選ぶ目安が1つ増えました。「何が起きているかを早く、はっきり告知するか」です。加えて、サポートが終わったバージョンまで手当てをしたか、利用者がPHPのバージョンを自分で切り替えられるか、切り替え後に前のバージョンへ戻せるかも見ておきます。料金や速さだけでなく、こうした場面での動き方を比べるのは、今回のような一件が教えてくれたことです。
ステップ4|サイトの役割に合った作り方を選び直す
前の章の表を使って、「このサイトは本当にWordPressである必要があるか」を一度考えてみてください。すでにWordPressで動いていて問題がないなら、無理に変える必要はありません。大事なのは、選んだ形の「土台を直す人」が誰かを知っていることです。
ステップ5|年に1回、部品の寿命を見る日を決める
PHP 8.2は2026年12月31日でセキュリティ修正が終わり、8.3は2027年12月31日までです。WordPressも年に3回の大きな更新を予定しています。こうした期限は毎年動くので、年に1回、サイトを支えている部品のサポート期限をまとめて確かめる日を決めておくと、次に同じことが起きたときに「うちは対象か」をすぐ答えられます。
よくある失敗と注意点
今回のような一件のあとは、「もう終わった」と気を抜くことと、「怖いから全部変える」と慌てることの両方が失敗につながります。
「サーバー会社が直したから安心」で止まる
今回の分は直りましたが、古いPHPを選んだままなら、次の弱点では修正が来ない可能性があります。エックスサーバーの「急いで変更する必要はない」は今回の件についての案内であり、古いバージョンを使い続けてよいという意味ではありません。サポート中のバージョンへの切り替えを、表示の確認をしながら計画的に進めてください。
PHPを上げて崩れたので、古い版に戻したまま放置する
バージョンを上げて表示が崩れるのは、古いテーマやプラグインが原因であることが多いです。一時的に戻すのはやむを得ませんが、原因を特定して直し、改めて上げる日を決めておかないと、弱点が残り続けます。
SNSの数字や予言に振り回される
21日の夜は「公開から15分で乗っ取られる」といった投稿が出回りましたが、根拠のある情報ではありませんでした。確認する先は、PHP公式、IPA、契約しているサーバー会社の公式ページと公式Xの3つで足ります。
よくある質問
Q. 今回の件は、もう終わったと考えてよいですか?
A. 主要なレンタルサーバーでは修正の適用が終わり、一区切りです。ただしPHP公式は10月23日にも追加の注意を出していて、エックスサーバーもPHP 5.5以前への対応を続けています。契約先の告知は引き続き見ておいてください。
Q. WordPressを使っている限り、同じことが繰り返されますか?
A. PHPの土台に弱点が見つかれば、WordPressに限らずPHPで動くすべてのサイトが影響を受けます。これはWordPressの欠点ではなく、土台を共有する仕組みの性質です。対策は、サポート中のバージョンを使い、直す人を決めておくことです。
Q. WordPressはPHPをやめる予定があるのですか?
A. 2026年10月時点で、公式のロードマップにそのような計画は書かれていません。編集画面にJavaScriptを使う流れや、ブラウザの中でPHPを動かす実験はありますが、PHPから離れるという公式の発表はありません。
Q. PHP 7.4のサイトは、すぐに8.3へ上げるべきですか?
A. 今回の分はサーバー会社の修正で手当てされていますが、7.4は2022年にサポートが終わっており、次の弱点では修正が出ない可能性があります。テスト環境で表示や問い合わせフォームを確認しながら、サポート中のバージョンへ計画的に上げることをおすすめします。
Q. 制作会社に何を聞けばよいですか?
A. 「うちのサイトはどのサーバーの、どのPHPのバージョンで動いていますか」「今回の修正は適用されていますか」「PHPのバージョンを上げる作業と、その後の確認は保守の範囲ですか」の3つで十分です。
THREE D PLUS は大阪の Web 制作会社です。今回の件を機に「うちのサイトは大丈夫か」「作り方を見直したい」と感じた方は、現状の棚卸しからご相談いただけます。お問い合わせはこちら。