「うちはPHPなんて使っていないはずだから関係ない」。
このニュースを見て、そう思った方も多いのではないでしょうか。 ところが、話はそう単純ではありません。
2026年10月21日、PHPの開発元が重大な脆弱性2件（CVE-2026-109618・CVE-2026-109619、通称「php2shell」）を修正した版を公開しました。どちらも、ログインなしで外からサーバー上のプログラムを動かされうる種類の欠陥です。深刻度はCVSS v4.0で各9.2。銀行などが一部のサービスを止めたと報じられています。
PHP公式の勧告は、はっきりこう書いています。完全な回避策は無く、更新することだけが安全な選択だ、と。
ただ、更新は「どこに当てるか」が分かっていて初めてできます。 この記事の結論は一つです。今日まず確かめるべきは、パッチの当て方ではなく、自社のどこでPHPが動いているかです。そして、場所によって「直すのは誰か」が変わります。
※本記事は2026年10月22日時点で公開されている情報にもとづいています。当社はセキュリティの専門会社ではなく、公開情報を整理して、企業の担当者が判断する順番として解説しています。
PHPは、ウェブサイトの裏側で動く言語として長く使われてきました。W3Techsの調査では、サーバー側の言語が分かっているウェブサイトのうち69.3%がPHPを使っています（2026年10月21日時点）。報道で「ウェブの7割」と言われているのはこの数字です。
問題は、自社で「PHPを選んだ」覚えがなくても、使っている場合があることです。
IPAも、PHPを使っているものを「可能な範囲で棚卸し」すること、そして製品や機器の内部でPHPが使われていないかを開発元・提供元の情報で確かめることを求めています。
つまり、「使っているか」は記憶ではなく、調べて初めて分かることなのです。
棚卸しをすると、PHPが動いている場所は大きく3つに分かれます。ここを分けておかないと、社内で「誰がやるのか」が決まらないまま時間が過ぎます。
| 場所 | 直すのは誰か | 自社がやること |
|---|---|---|
| 自社で管理しているサーバー（VPS・クラウドの仮想サーバーなど） | 自社（または保守を頼んでいる会社） | 修正版（8.2.35／8.3.36／8.4.27／8.5.12）へ更新。すぐ無理なら止めることも検討 |
| レンタルサーバー（共用サーバー） | 主にサーバー会社 | 事業者のお知らせを確認。PHPのバージョンを自分で選べる場合は、古い版を選んでいないか確認 |
| SaaS（フォーム・カート・MA・会員サイトなど） | サービス提供元 | 提供元の告知を確認。止まる時間帯に、配信予約や申込みが重なっていないか確認 |
いちばん重いのは、自社で管理しているサーバーです。誰も代わりに直してくれません。
特に注意したいのが、PHP 8.1 以前の古い版です。開発元からの修正版はもう出ません。一部のLinuxディストリビューションや延長サポートの会社が独自に直している場合はありますが、それが無ければ「当てるパッチが無い」状態です。8.2 も2026年12月31日でサポートが終わります。
どうしてもすぐに更新できない場合、PHP公式は設定による緩和策（たとえば session.upload_progress.enabled を無効にしてワーカーを再起動する、など）を挙げています。ただし公式自身が「攻撃の経路を減らすだけで、安全にはならない」と書いています。
首相が「対応が難しい場合はサイトの一時停止も有効策の一つ」と呼びかけたのは、この状況を指しています。止めるかどうかは技術の話ではなく、経営の判断です。止めて失う売上と、乗っ取られたときの被害を比べて、誰が決めるのかを先に決めておく必要があります。
当社でも、報道を見てすぐに確かめました。やったのは、AI（Claude Code）に自社のドメインとサブドメインを洗い出させ、それぞれがどこのサーバーで動いているかを外から調べさせることです。
結果はこうでした。
「関係なかった」で終わる話に見えるかもしれません。 でも、もし転送ページの代わりに、昔のWordPressがそのまま残っていたらどうでしょう。誰も更新していないPHPが、会社のドメインで動き続けていたことになります。
ここで大事なのは、調べるまで、誰も正確には知らなかったことです。担当者の記憶にある「たぶん全部移した」と、実際に外から見える状態は、一致しているとは限りません。
AIに頼んだときの指示文は、次のようなものです。そのまま使えます。
当社が持っているドメインとサブドメインを、リポジトリや設定ファイル、DNSの設定から洗い出してください。 それぞれについて、DNSの行き先と、サーバーが返す応答（Server ヘッダーなど）を調べ、 「自社で管理するサーバー」「レンタルサーバー」「SaaS」「PHPを使わない配信基盤」のどれかに分けて表にしてください。 PHPが動いている可能性があるものには、その根拠と、確認すべき事業者のお知らせを書いてください。 攻撃につながる調べ方（脆弱性を試す送信など）はしないでください。外から見える応答を確かめるだけにしてください。
最後の一文は必ず入れてください。自社の資産であっても、攻撃を試すような確かめ方は、それ自体が事故のもとになります。
なお、AIの調べた結果は「外から見える範囲」です。社内ネットワークの中の機器や、契約しているSaaSの裏側までは分かりません。そこは提供元への確認が要ります。
順番に書きます。
1 と 2 は、今日中に終わらせたい作業です。
起きてしまった場合の動き方は、情報漏えいの初動対応は「手順書」より先に「誰が決めるか」 で整理しています。止める判断を誰がするのかも、ここで決めておけます。
正直に書いておきます。
AIを業務に入れる会社ほど、ドメインもツールも増えていきます。増えたものを把握し続けるのは、人の記憶では難しくなります。
だからこそ、今回のような「全部を今すぐ確かめる」場面で、AIに棚卸しをさせる仕組みを持っておく価値があります。自社のどこで何が動いているかを、AIで定期的に確かめる体制づくりのご相談は、お問い合わせからどうぞ。
出典: