PHPの緊急脆弱性「PHP2Shell」で考える、そのサイトのアップデートは誰の仕事か

先週、X のタイムラインがしばらく「PHP2Shell」一色でした。10月21日、PHP に深刻な脆弱性が2件（CVE-2026-109618、CVE-2026-109619）見つかったと PHP の開発チームが公表し、緊急のセキュリティリリースを出したんです。

PHP は WordPress を動かしている言語なので、「うちのホームページも関係あるの？」と聞かれそうな話です。実際、Cloudflare は「PHP はウェブサイトのほぼ70%で使われている」と書いていますし、国内でも JPCERT/CC と IPA が10月22日に注意喚起を出しています。

技術的な中身は専門の記事に任せるとして、今回は「中小企業やお店が自社のサイトについて何を確認すればいいか」と、もう一歩踏み込んで「そのサイトのアップデートは、そもそも誰の仕事なのか」を考えてみます。

01｜何が起きたのか

PHP の公式アドバイザリによると、ポイントはこうです。

脆弱性は2件で、どちらもログインなしで、外から細工したリクエストを送るだけで、サーバー上で好きなコードを実行される可能性があるもの
影響するのは、Web のリクエストを処理しているすべての PHP（PHP-FPM、Apache の mod_php、php-cgi、FrankenPHP、LiteSpeed）
修正版は PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
PHP 8.1 以前には公式の修正版が出ない（サポート終了のため）。ディストリビューションやLTSベンダーのパッチを使うか、新しいバージョンに上げる必要がある
一時的な回避策は案内されているものの、公式は「完全な対策はアップデートだけ」とはっきり書いている

発見したのは Calif、Wiz、OpenAI などの研究者で、AI を使って見つけたことも話題になりました。また Cloudflare は、公表より前から情報が漏れて攻撃の通信が来ていたと書いています。watchTowr というセキュリティ会社も、実際の悪用を観測したと報告しています。

02｜「うちは関係ない」と言い切れる会社は意外と少ない

中小企業やお店のサイトでいうと、PHP が使われている可能性が高いのはこのあたりです。

WordPress で作ったコーポレートサイトやお店のホームページ
EC-CUBE などで作ったネットショップ
昔、制作会社に作ってもらった問い合わせフォームや予約フォーム
レンタルサーバーに置いたままのキャンペーンページや古い採用サイト

厄介なのは、サイトを使っている本人が、それが PHP で動いていることを知らないことが多い点です。CISA（米国のサイバーセキュリティ機関）も「PHP は他のソフトの部品として入っていることが多く、外から見えにくい」と書いています。

自分も制作の相談を受けていて、「サイトはあるけど、どこのサーバーで、誰が管理しているかは分からない」というケースにけっこう出会います。今回のような話が出たとき、まずここで止まってしまうんですよね。

03｜まず確認すること

エンジニアがいなくても確認できる範囲で、順番に書いておきます。

自社のサイトを全部書き出す。メインのサイトだけでなく、キャンペーンページや古いサイトも含めて
それぞれ、どこのサーバー（レンタルサーバー、VPS、制作会社の管理など）に置いているかを確認する
PHP のバージョンを確認する。WordPress なら管理画面の「ツール」→「サイトヘルス」→「情報」の「サーバー」欄で見られます。レンタルサーバーなら、たいていコントロールパネルに PHP のバージョン設定があります
8.1 以前なら要注意。公式の修正版が出ないので、サーバー会社のパッチが当たっているか確認するか、新しいバージョンに上げる相談をする

サーバーに入れる人なら、確認はこれだけです。

php -v

php-fpm -v   # 環境によっては php-fpm8.3 -v など

コマンドラインの php と、実際に Web を処理している PHP のバージョンが違うことがあるので、両方見ておくのが安全です。アップデートした後は、PHP のプロセスを再起動するまで古いまま動き続ける点にも注意してください。

なお JPCERT/CC は、アップデートに加えて攻撃を受けていないかの調査も勧めています。不自然に長い PHPSESSID の Cookie、メモリ上限のエラーや HTTP 500 が急に増えていないか、PHP のプロセスが頻繁に落ちていないか、などです。ただし痕跡が残らない場合もあるので、「見つからなかった＝大丈夫」とは言えないとも書かれています。

04｜「作ってもらったサイト」のアップデートは誰がやるのか

ここからが今日いちばん書きたかったことです。

サイトを制作会社に作ってもらった場合、よくあるのが制作の契約はあったけど、保守の契約はないというパターンです。この状態だと、

制作会社は「納品したので、その後の更新はお客さん側」と思っている
お客さん側は「何かあったら制作会社がやってくれる」と思っている
レンタルサーバー会社は「サーバーの PHP の切り替えはお客さんがやるもの」としている

と、誰も自分の仕事だと思っていない、ということが起きます。普段は困らないので気づかないんですが、今回のような緊急のアップデートが来たときに初めて表に出ます。

IPA の注意喚起には、技術的な対策だけでなく「長期間更新していないシステムは、担当者の不在や保守契約の終了で対策が難しくなっている場合がある」「経営層も含めて、人員・予算・保守体制を確保できるか検討してほしい」「体制が確保できないなら、公開の終了やシステムの廃止も含めて検討してほしい」とまで書かれています。セキュリティの注意喚起で「やめることも考えて」と書くのは、かなり踏み込んだ書き方だと思います。

作る側として正直に言うと、Web サイトは作った瞬間から、何かを更新し続けないといけないものです。WordPress 本体やプラグインだけでなく、その下で動いている PHP やサーバーも含めて、です。なので、サイトを作るときや見直すときには、最低限ここは決めておいてほしいです。

PHP やサーバーのアップデートは誰がやるのか（制作会社か、サーバー会社か、自社か）
緊急のときに誰に連絡すればいいのか
使わなくなったページやサイトを、誰がいつ閉じるのか

05｜AIで脆弱性が見つかる速さが変わっている

もう一つ、今回の件で考えさせられたのは、AI によって脆弱性が見つかるペースが上がっていることです。

PHP2Shell も AI を使って見つかったものですし、Cloudflare は同じ日に出したブログで「最新のモデルが、広く使われているソフトの奥に埋もれた脆弱性を見つけ出していて、守る側にも攻める側にも新しい道を開いている」と書いています。AI のエージェントが、手を変え品を変え攻撃を試し続けることにも触れていました。

これは中小企業にとっても他人事ではなくて、「数年に一度、大きな脆弱性が出たら対応する」という前提が通用しにくくなっている、ということだと思います。対策として現実的なのは、

アップデートを「事件が起きたらやる作業」ではなく「定期的にやる作業」にする
自分で全部持たない。サーバーの管理まで自分でやる必要がないなら、PHP の更新まで面倒を見てくれるマネージドなサービスや、保守込みで見てくれる会社に任せる
入口を減らす。使っていない古いサイトは閉じる。Cloudflare の WAF（攻撃っぽい通信を手前で止める仕組み）は今回、無料プランも含めて自動で防御ルールが入りましたが、Cloudflare 自身も「それでもパッチは当ててほしい」と書いています

あたりかなと思っています。

「サイトを持っている」ということは、「その下で動いているソフトの面倒を見続ける」ということでもある。今回の PHP2Shell は、そのことを思い出すいいきっかけだと思います。自社のサイトの PHP のバージョンと、アップデートの担当者、今週中に一度確認してみてください。

参考リンク：