大東 信仁（ものくろ） 
10月21日に、PHPの重大な脆弱性「php2shell」が公表されました。
それから3日間、状況が動くたびにYouTubeで動画を撮っていたら、4本になりました。
この記事では、その4本を順番に並べて、何が起きて、僕がどう動いたかをまとめておきます。
先に、いまの結論です。
さくらのレンタルサーバ、エックスサーバー、ロリポップ！、ConoHa WING、ヘテムル。
主要なレンタルサーバー5社は、提供しているPHPのバージョンすべてで対応が終わっています。
レンタルサーバーでWordPressを使っているなら、慌ててPHPのバージョンを上げなくて大丈夫です。
php2shellは、PHPそのものの穴
php2shellは、CVE-2026-109618とCVE-2026-109619という、2つの脆弱性の通称です。
WordPressやプラグインの穴ではなく、WordPressを動かしているPHPそのものの穴。
外から細工したアクセスをされると、サーバー上で好きなプログラムを実行されるおそれがある、深刻なものでした(CVSS 9.2)。
PHPの修正版は、日本時間の10月21日 23時ごろに公開されています。
8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 です。
サポートが終わっている7.4・8.0・8.1にも、PHPの開発チームが修正のソースを出してくれました。
なお、10月23日には、PHP公式から関連する別の脆弱性(CVE-2026-115560)の告知も出ています。
こちらは、珍しい設定とプログラムの組み合わせでしか起きないもので、次の定期リリースで直る予定とのことです。
10月21日 夕方、エックスサーバーの管理画面が止まった
最初の動画は、10月21日の夕方に撮りました。
エックスサーバーが、16時から公式サイトや管理画面へのアクセスを止めていた時間です。
管理画面が止まると、「何かあったの?」と不安になりますよね。
公式のお知らせによると、これは予防のための措置で、不正アクセスが起きたわけではありません。
Webサイトの表示や、メールの送受信は、通常どおり使えていました。
ただ、管理画面に入れないので、利用者がPHPのバージョンを上げることはできません。
なので、この時点で僕が伝えたかったのは、ひとつだけ。
PHPの更新はエックスサーバー側がやってくれるので、慌てず、公式の続報を待ちましょう、ということです。
10月21日 深夜、修正版が出て、ひとまず一安心
2本目は、修正版が公開されたあと、23時45分ごろに撮りました。
エックスサーバーの「よくあるご質問」に、利用中のサーバーにも、修正版が出る前の緩和策を含めた安全対策を順次入れている、と書かれていました。
管理画面に入れない僕たちの代わりに、サーバー会社が動いてくれている。
これで、ひとまず一安心です。
この日は、高市首相がXで「修正パッチを可及的速やかに適用できるよう準備を」と呼びかけていて、国内でも多くのサービスが予防的に緊急メンテナンスに入りました。
首相が「パッチを当てて」と呼びかける時代になるとは。
正直、驚きました。
その裏では、たくさんの事業者さんやエンジニアさんが、夜通し対応しています。
そのことが、少しでも伝わるといいなと思って撮った動画です。
10月23日、主要レンタルサーバー5社は全部OKに
3本目は、10月23日の17時時点の結論です。
当初は「PHP 8.2以降でないと修正版が出ない」という話でした。
が、ふたを開けてみると、古いバージョンのPHPにも、各社が修正を当ててくれていました。
ロリポップ！とヘテムルは、公式の修正がないPHP 7.3以前にも、自社で修正を作って当てています。
ここで気をつけたいのが、PHPのバージョン表記です。
ConoHa WINGのように、バージョンを上げずに修正だけを取り込む会社もあります。
その場合、WordPressのサイトヘルスで見ても、修正版の番号(8.5.12など)ではなく、これまでと同じ番号(8.5.11など)が表示されます。
表記が変わっていなくても、修正済み。
なので、自分のサーバー会社の公式発表を確認するのが確実です。
WordPressユーザーが、いまやること
動画でお話しした、やる順番はこうです。
- 慌ててPHPのバージョンを上げない(パッチは当たっています。管理画面も混み合っています)
- WordPress本体・プラグイン・テーマを更新しても壊れないか、先にチェックする
- そのあと、PHPを8.3以上へ上げる
PHP 8.2のサポートは、2026年12月31日で終わります。
今回の件がなくても、年内に8.3以上へ上げておきたいところです。
PHPを上げて画面が真っ白になっても、エラーで止まっているだけで、データは消えていません。
PHPのバージョンを戻せば、表示されます。
もちろん、作業の前にはバックアップを取ってください。
いちばん危ないのは、「アップデートしたら壊れるから、アップデートしない」です。
その時、僕はどう動いたか
4本目は、21日から23日まで、僕が実際にどう動いたかの記録です。
うろ覚えになる前に、撮っておきました。
実は、PHPの前には、Linuxカーネルの脆弱性の確認に追われていました。
PHPの件を知ったのは、21日の15時ごろ。
エックスサーバーの管理画面には入れないので、続報をウォッチしながら、ConoHaのサーバーには、修正版が出る前の緩和策を1行足しました。
この日の夜は講座があったので、講座のあとにCloudflareのCDNをオンにして、WAFで守る形に。
翌22日の朝は、古いPHPで動いているお客さまのサイトを、.htaccessで静的なメンテナンス画面に差し替えました。
このメンテナンス画面は、Claude Codeが作って、動作確認までしてくれています。
あとは、各社の「修正完了」を公式発表で確かめてから、メンテナンス画面を順に外していきました。
エックスサーバーは22日の昼に、ConoHaは夜に完了。
古いサーバーで動いているお客さまとは、引っ越しを前倒しする相談を始めています。
ふり返って思ったこと
ひとつは、Xが情報のインフラとして、本当に役に立ったこと。
もうひとつは、情報のウォッチは、人力でなくてもよかったな、ということ。
GrokなどのAIに見張りを任せる手も、ありました。
「WordPressか、新しい仕組みか」の二元論にしない
こういう騒ぎがあると、「WordPressはもう危ない」「AIで静的なサイトを作れば安全」という話も出てきます。
AIを使って、新しい仕組みでサイトを作る。
それも、いいと思います。
そして、WordPressを、いつでも最新版で運用し続けることも、AIを使えばできます。
今回のメンテナンス画面も、Claude Codeが作って、動作確認までしてくれました。
「こっちはいい」「こっちはあかん」。
二元論にすると、議論はかんたんかもしれません。
でも、二元論だと、結局、堂々巡りになる気がするんですよね。
もう一つ。
今回と同じことが、同じ形でまた起きるとは限りません。
再現性が、そうそうない世の中になっています。
起きるかもしれないこと全部に備えようとすると、備え過ぎて、しんどくなります。
なので、僕が考えたいのは、やりたいことを実現するために、なにをするのか。
WordPressで続けるのか、新しい仕組みに移るのかは、そのあとで決めればいい。
まとめ
今回、何か被害はありましたか?
ヒヤヒヤしただけ、という人がほとんどだと思います。
脆弱性が見つかって、ちゃんと直る。
その仕組みが回っていることが、WordPressとPHPの強さなんだなと、あらためて思いました。
不安のエネルギーからではなく、前に進むエネルギーで。
そっちで歩きませんか?
対応にあたったレンタルサーバー会社の皆さん、PHPの開発チームの皆さん。
不眠不休の対応、本当にありがとうございました。
ちなみに、3本目と4本目の動画は、撮影データをClaude Codeに渡して編集しています。
カット、字幕、テロップ、BGMまで、おまかせです。
動画の中で「うろ覚えなので、あとで確認して」と言っていた時系列も、各社の公式発表で裏取りして、補足のテロップに入れてくれました。
