PHPの脆弱性騒動で分かった、Webサイトは「家」と同じだということ

まずは時系列です（時刻は日本時間）。

脆弱性は2件（CVE-2026-109618、CVE-2026-109619）で、通称「php2shell」。どちらも、外部から認証なしで、サーバー上で任意のプログラムを実行される恐れがあるものです。サイトの書き換え、データの盗み出し、ほかのサーバーへの攻撃の踏み台。乗っ取られたら何でもできる、という種類の脆弱性です。

ちなみに、この脆弱性を見つけたのはAIでした。OpenAIによると、同社のOSS脆弱性発見の取り組みの中で、セキュリティ企業がGPT-5.6 Solを使って特定したそうです。AIは守る側だけでなく、攻める側の手数も増やします。これからこういう騒ぎは増えると思っておいたほうがいいでしょう。

脆弱性のニュース自体は、珍しくありません。WordPressのプラグインに穴が見つかった、という話は毎月のようにあります。では、今回は何が違ったのか。

「特定の環境だけ」ではなかった

2年前（2024年6月）にもPHPの重大な脆弱性（CVE-2024-4577）が騒がれました。ただあのときは、WindowsでPHPをCGIモードで動かしている、日本語などの特定の言語設定の環境が対象でした。日本のWebサイトの多くはLinuxのレンタルサーバーで動いているので、大半は直接の対象外でした。

今回は違います。

• 入口になったのは、PHP本体の、標準でONになっている機能
• 一般的な構成（mod_php、PHP-FPM）や、WordPress・Laravelなどでも攻撃が再現するとされている
• 根っこは古く、PHP 5系から8系まで広く影響すると考えるべき、という分析も出ている

つまり、「うちは特殊な環境じゃないから関係ない」が通用しなかったわけです。

「HTMLだけのサイトだから大丈夫」でもない

SNSでは「PHPを使っていない、HTMLだけのサイトなら関係ない」という声もありました。でも、そのサイトが置かれているサーバーにPHPが入っていれば、サーバーごと乗っ取られる可能性は残ります。共用のレンタルサーバーなら、なおさらです。

公表前から攻撃が始まっていた

Amazonの脅威インテリジェンスは、公表前の10月17日から悪用の試みを観測していたと報告しています。修正版の公開直後には、セキュリティ企業のwatchTowrが実際の攻撃の試みを確認しています。「パッチが出てから考えればいい」という余裕は、最初からなかったわけです。

ここが今回、一番異例だったところです。

通常、深刻な脆弱性は「協調された開示」という手順で扱われます。

修正版が出る前に「こんな穴があります」と知られたら、攻撃者に先回りされてしまうからです。

今回は、この手順が崩れました。公式発表より先に、CVE番号と公開予定日がHacker NewsやSNSで出回り、さらに研究者側から攻撃の実演動画がXに投稿される（後に誤って投稿されたものと説明されています）など、情報が漏れ始めたのです。

一度漏れた情報は、もう隠せません。攻撃者だけが知っていて、守る側が何も知らない状態が一番まずい。だからPHP公式は、「何日の何時に修正版を出すから、準備しておいて」と、あえて先に宣言したわけです。当初は22日に予定されていたとみられる公開を21日に前倒しし、「詳細が出回ったり、悪用が確認されたりしたら、さらに早める」とも明言していました。実際、修正版は予告より少し早い22時40分頃に出ています。

予告があったおかげで、管理者は身構えることができました。その一方で、ニュースになり、首相まで呼びかける騒ぎになった。これが、後で書く「説明が大変」につながります。

ここが本題です。やるべきことは、サイトがどこに乗っているかでまったく違います。

レンタルサーバーの場合：待つしかない。でも、ただ待つわけじゃない

レンタルサーバーのPHPは、サーバー会社の管理範囲です。利用者が自分で入れ替えることはできません。サーバー会社が、自社で提供しているPHPの各バージョンにパッチを当てるのを待つことになります。

問題は、待っている間です。修正版が出た瞬間から攻撃が始まるので、パッチを当て終わるまでの数時間は、いたちごっこになります。だから今回は、サーバーごと、またはサイトを予防的に止めるという判断をした会社がありました。国家サイバー統括室も「パッチの適用が難しい場合は、サイトの一時停止も有効策の一つ」と発信しています。

各社の対応は次のとおりです（2026年10月22日現在。各社とも対応は継続中なので、最新の状況は公式の告知で確認してください）。

うちが使っているヘテムルは、一部のお客様サイトを予防的に止め、翌22日の昼前に再開しました。同じGMOペパボのロリポップも同様です。エックスサーバーは、サイトの表示は原則として続けたものの、緊急対応の間は管理画面がつながりにくいなど、断続的に影響が出ていました。同じGMOグループでも、ConoHa WINGはサイトの表示は続けたまま、ファイルマネージャーとWebメールだけを予防的に止めています。一方、さくらインターネットは、止めた気配がないまま、提供している全バージョンへの対応を完了させています。

会社によって判断が分かれたのは、どちらが正しいという話ではありません。「止めて守る」か「止めずに急いで直す」か。どちらにも理由があります。

VPSの場合：全部、自分の責任

VPSは、OSから自分で入れているので、対応も全部自分です。

とはいえ、PHPを自分でソースからビルドし直すのは現実的ではありません。基本は、使っているOS（Ubuntu、AlmaLinuxなど）や、PHPを入れたリポジトリが出す修正パッケージを待って当てるのがいいでしょう。OSやPHPもオープンソースで、それぞれのメンテナーが修正を出してくれます。

注意点はいくつかあります。

• ディストリビューションの修正版も、PHPの番号は変わらないことがある。更新履歴（changelog）で修正が入ったかを確認する
• 更新したら、PHP-FPMやApacheを再起動する。古いPHPがメモリに残ったままでは意味がない
• 修正パッケージを待つ間は、暫定的な設定変更（session.upload_progress.enabled = 0 など）も選択肢になる。ただし、GMO Flatt Securityは「これだけでは完全に回避できない」としている。不安なら、公開を止めるのも立派な判断
• 修正後は、攻撃を受けていなかったかログを確認する

AWSなどクラウドの場合：VPSと同じ。ただし範囲を確認

EC2のような仮想サーバーなら、考え方はVPSと同じです。

マネージドなサービスを使っている場合は、提供側がどこまで面倒を見てくれるかで変わります。クラウドには「責任共有モデル」という考え方があり、OSやランタイムをどこまで提供側が直すかは、サービスごとに違います。自分で作ったコンテナイメージを使っているなら、再ビルドは自分の仕事です。

加えて、クラウドで万一侵入されていた場合は、そのサーバーが持っている権限（IAMロールなど）の確認も必要です。そこから他のサービスに横展開されるのが、クラウドの怖いところです。

今回、日本でこれほど騒ぎが大きくなった理由の一つは、日本のWebサイトの多くがレンタルサーバーで動いていて、そのほとんどにPHPが入っているからです。WordPressもPHPで動いています。

レンタルサーバーだけではありません。同じ夜、Cygamesの『ウマ娘 プリティーダービー』『グランブルーファンタジー』『Shadowverse: Worlds Beyond』、スクウェア・エニックスの一部サイトやサービス、セガの製品情報サイトなど、ゲーム関連でも緊急メンテナンスが相次ぎました。ニコニコやpixiv、BASEといったWebサービスも同様です。ゲームのスマホアプリも、裏側ではWebのサーバーとやり取りしていて、そこにPHPが使われているわけです。

ここ数年、「PHPはオワコン」と言われることもありました。でも、これだけ社会的な影響が出るということは、それだけ広く、深く使われているということです。オワコンどころか、インフラです。

まあ、その話は置いておいて。

ニュースになり、首相まで発言しちゃったもんだから、Webに詳しくないお客様からも、たくさんの連絡が来ました。

心配してくださるのはありがたいんです。でも、どこから説明したらいいのか。

「PHPって何？」から始まる方もいれば、「うちはWordPressだけど関係ある？」という方も、「サーバー会社から止めるってメールが来たけど、どういうこと？」という方もいます。相手によって、説明の入り口がまったく違う。一斉送信の定型文では済みません。

特に説明が難しかったのが、この3つです。

今回の騒動で、あらためて思いました。Webサイトは、家と同じです。

マンションには修繕積立金があります。毎月少しずつ積み立てておくから、外壁や配管が傷んだときに、慌てずに直せる。普段から管理会社が建物の状態を見ているから、何かあったときにすぐ動けます。

Webサイトの保守費も、同じです。毎月積み立てて、適時メンテナンスしてもらっていれば、今回のようなことが起きたときに、すぐ対応してもらえます。そこには、普段からサイトの状態を知っているという信頼関係も含まれます。

逆に、積み立てがないとどうなるか。何か起きるたびに、ドカーンと修繕費がかかります。しかも、まず現状調査から始めることになるので、時間もかかります。今回のように「今夜中に」という事態では、それが致命的になることもあります。

もちろん、予算の都合で保守契約を付けられないこともあるでしょう。それでも、最低限やっておいてほしいことがあります。

制作会社とは、密に連絡を取っておく

保守がなくても、制作会社との関係は切らないでください。

ただし、困ったときだけタダで聞く、はおすすめしません。ページの更新やちょっとした修正など、適度に仕事として頼んでおくほうがいい。そうすれば、制作会社もサイトの今の状態を把握できますし、いざというときに「あのお客様のサイトなら」とすぐ動けます。

自分のサイトの「登記簿」を把握しておく

家の権利書がどこにあるか分からない、という人はいないはずです。Webサイトも同じです。

これが分かっているだけで、何かあったときの対応速度がまったく違います。

今は、AIでもサイトが作れます。WordPressなら、専門知識がなくても簡単に作れます。それ自体は良いことです。

でも、今回のような事態に対応できるかは、また別の話です。

同じ専門家ですら、今回の対応では知見に差が出ました。どの情報を信じるか、暫定策をどこまで信用するか、止めるか止めないか。判断の材料はニュースではなく、経験と、そのサイトを普段から知っているかどうかです。

作るのは簡単になりました。でも、守り続けるのは、相変わらず人の仕事です。

• 今回のPHPの脆弱性は、標準でONの機能が入口になり、一般的な構成で広く影響した。情報が先に漏れたため、公式は異例の「公開時刻の予告」に踏み切った
• レンタルサーバーはサーバー会社の対応待ち（予防停止もあり）、VPS・クラウドは自分で修正パッケージを当てて再起動する
• 「最新にしていれば安全」ではない。いたちごっこを前提に、直し続けられる体制を持つことが大事
• Webサイトは家と同じ。保守費は修繕積立金。保守がなくても、制作会社との関係と、自分のサイトの「登記簿」は持っておく