「うちは大丈夫」が通用しない―php2shellから考える、ディレクターの初動と平時の備え

2026年10月23日 Webディレクション #セキュリティ #インフラエンジニア #Webディレクター #エンジニア #PHP #プロジェクトマネジメント #情報収集 #AI

本記事は2026年10月23日時点の情報に基づいています。 攻撃状況や各社の対応は日々更新されるため、実際の対応時にはPHPの公式情報や、利用中のサーバ会社・製品の告知を確認してください。

何が起きたのか

PHPは、WordPressをはじめ、世の中のWebサイトの相当な数を動かしているプログラミング言語です。そのPHP本体に、重大な脆弱性が2件見つかりました。

2026年10月21日、PHPはこの2件（CVE-2026-109618、CVE-2026-109619）を修正した版を公開しました。深刻度は、脆弱性の危なさを示す共通の物差し「CVSS v4.0」で、どちらも9.2/10、評価は「Critical（重大）」です。

「PHP2Shell」は、セキュリティ研究者や報道の間で使われている通称です。PHP公式が付けた名前ではありません。

今回の脆弱性は「遠隔コード実行」と呼ばれる種類です。悪用されると、外部の攻撃者が、PHPを動かしているプロセスの権限で、自分の用意したプログラムを実行できるおそれがあります。サーバ全体を無制限に操作できるという意味ではありませんが、そのサイトのファイルを書き換えたり、サイトが扱うデータにアクセスしたりする足場を与えてしまう可能性があります。実際に何ができるかは、PHPに与えられている権限やサーバの構成によって変わります。

経緯も異例だった

本来は10月22日に公表される予定でした。ところが10月20日に、CVE番号などの情報がネット上に出回ります。PHP Foundationによれば、その時点で技術的な詳細は漏れていませんでしたが、PHPは公開を1日前倒しし、10月21日のUTC 14時ごろ（日本時間21日23時ごろ）に修正版を出しました。

国内でも、IPA（情報処理推進機構）とJPCERT/CCが注意喚起を出しています。

「ニュースになる脆弱性」と「ならない脆弱性」の違い

脆弱性は毎週のように公表されています。それでも、大きく報じられるものとそうでないものがあります。今回ここまで騒がれた理由は、大きく3つあります。

ひとつ目：ログインなしで、外から突ける可能性がある

攻撃者がサイトにログインしなくても、脆弱性を悪用できる可能性があります。PHP公式は、CVE-2026-109619について、遠隔からのコード実行に加え、メモリの中身が漏れることも確認済みの影響としています。メモリには、パスワードやAPIキーなどの認証情報が含まれ得ます。

ただし、「ログイン不要」は「どの環境でも簡単に攻撃が成功する」という意味ではありません。CVSSの評価でも、攻撃の難しさは「高」とされており、攻撃が成立するかどうかはPHPの実行方式や設定に左右されます。

ふたつ目：サイト側のコードが正しくても影響を受ける

欠陥は、個々のサイトのプログラムではなく、サイトを動かすPHP本体（土台）にあります。そのため、WordPressやMagento、WooCommerceのように、サイト側のコードに問題がなくても影響を受ける可能性があります。WordPressなどのアプリケーションを更新するだけでは、PHP本体の脆弱性は直りません。

つまり「うちはちゃんと作ってるから大丈夫」は通用しない、ということです。

一方で、PHPを使っていればどこも同じ危険がある、というわけでもありません。PHP公式のアドバイザリによれば、Apacheのmod_phpという動かし方では、2件とも攻撃が実証されています。広く使われているPHP-FPMという動かし方では、CVE-2026-109619がアプリケーション側の条件がそろった場合に実証されている一方、CVE-2026-109618は完全な攻撃が実証されていません。自分の案件がどの動かし方をしているかで、危険の度合いは変わります。

みっつ目：すでに攻撃の試みが始まっている

AWSは、公表の4日前にあたる10月17日に、おとり用のサーバ（ハニーポット）で最初の攻撃の試みを観測したと報告しています。修正版の公開後は、広範な攻撃の試みが続いているとしています。

ただし、AWS自身が、観測した試みが実際のシステムで成功したかどうかは分からないとしています。「攻撃の試みが観測されている」ことと「侵入された」ことは、分けて考える必要があります。また、米CISA（サイバーセキュリティ・インフラストラクチャセキュリティ庁）の「悪用が確認された脆弱性の一覧（KEV）」に載っていないことも、攻撃がないことの証明にはなりません。

私が脆弱性のニュースを見るときに確認するのも、まさにこの3点です。「認証なしで外から突けるか」「影響範囲がどれだけ広いか」「すでに攻撃されているか」。この3つがそろっていれば、即対応です。

では、ディレクターは何を知っておくべきでしょうか。ここからが本題です。

1．自分の案件が「どのPHPのバージョンで動いているか」を把握しているか

意外と把握していないディレクターが多いのが、ここです。

今回、PHP公式から公開された修正版は次のとおりです。PHPは、アップデートだけが完全な対策だとしています。

PHP 8.5.12
PHP 8.4.27
PHP 8.3.36
PHP 8.2.35

問題は、これより古いバージョンです。PHP 8.1以前には、PHP公式の修正リリースは出ていません。セキュリティ企業のSansecは、PHP 5.4以降を使うWebサーバが影響を受けると報告しています。

一方で、Linuxの配布元（ディストリビューション）やサーバ会社が、古いバージョンに独自の修正を当てているケースもあります。表示されているPHPのバージョン番号だけで、安全かどうかを判断することはできません。

怖い数字もあります。Mallory社が10月20日時点で調べたところ、PHPのバージョンを外部に表示しているネット上のサーバ約150万台のうち、59%が公式の修正リリースが出ないPHP 8.1以前の表示でした。外から見える表示を数えた数字なので、すでに修正が当たっている環境も含まれます。それでも、古いバージョン表示のサーバがこれだけ多い以上、「アップデートすれば終わり」と決めつけず、案件ごとに個別確認が必要です。

案件ごとに、まず次の点を確認します。

PHPを使っているか
PHPのバージョンと、動かし方（実行環境）は何か
PHPを更新・修正する担当者は誰か
サーバ会社や製品の提供元から、対応状況が公表されているか
修正が適用された日時と、その確認方法は何か

2．「暫定対策」は「解決」ではない

エンジニアから「とりあえず設定で塞ぎました」と報告が来ることがあると思います。

今回よく紹介されているのが、アップロードの進み具合を記録する機能を切る設定です。PHP公式によれば、この設定はCVE-2026-109619の特定の攻撃経路を抑えるもので、もう1件のCVE-2026-109618には別の緩和策が案内されています。いずれも、脆弱性を完全に解消するものではありません。設定変更が適切かどうかは、サイトやサーバの構成に応じてエンジニアが判断する必要があります。

WAF（不正な通信を手前で止める仕組み）も、位置づけは「時間稼ぎ」です。すべての攻撃を防げるとは限らず、WAFを経由しない通信には効果がありません。

さらに、修正版を当てても、それ以前に仕掛けられた裏口は消えません。JPCERT/CCは、修正の適用とあわせて、攻撃を受けていないかの調査を呼びかけています。AWSは、調査を公表日からではなく、最初の攻撃が観測された10月17日以降を対象に行うよう勧めています。

エンジニアから報告を受けたときは、次の3つの状態を混同しないようにします。

緩和策を実施した：一部の攻撃経路を抑える措置を行った
修正を適用した：修正済みのPHP、または提供元が修正済みと確認したパッケージを適用した
侵害調査を行った：過去に攻撃を受けた形跡がないか調査した

ディレクターとしては、クライアントへの報告で「暫定対策済み」と「根本対応済み」を絶対に混ぜないこと。ここが非常に大事です。

3．クライアントへの初動は「事実」「確認中のこと」「次の連絡時刻」

クライアントに聞かれて「エンジニアに確認します」と答えるのは、まったく間違っていません。ただ、大事なのはその次の一手です。

最初の連絡で伝えるのは、次の3つだけで十分です。

事実：「PHP本体に重大な脆弱性が公表されました」
確認中のこと：「御社サイトのPHP環境と、サーバ会社の対応状況を確認しています」
次の連絡時刻：「本日○時までに、確認できた内容をご報告します」

技術的なことを全部説明できなくて構いません。クライアントが一番不安なのは、「何も分からないまま放置されること」だからです。

なお、PHPの更新を誰が行うかは、契約や構成によって異なります。レンタルサーバでは事業者側が対応することが多い一方、VPS、クラウド、専用サーバ、コンテナなどでは、クライアント自身やインフラ管理会社、保守会社が対応する場合もあります。

【ここに自社での今回の初動対応の実例を入れる】

4．保守契約の範囲を、平時に握っておく

今回、「このサイト、そもそも保守契約あったっけ？」という案件が、業界中でたくさん出てきていると思います。古いPHPで動いているサイトは、バージョンアップに改修費がかかることも少なくありません。長期間更新していないサイトでは、PHPを新しくすると既存機能に影響が出る可能性もあります。

保守契約では、平時に次の範囲を確認しておきます。

PHPやサーバソフトウェアの更新を誰が行うか
更新前のテストや、更新後の動作確認を誰が行うか
緊急対応の費用と連絡方法
攻撃の形跡を調査する担当者と範囲
保守契約がない場合の連絡先や対応方針

もう少し先の話もしておきます。PHP 8.2のセキュリティサポートは、2026年12月31日で終了する予定です。あと2か月あまりです。今回8.2で修正版を当てたサイトも、年明けには「修正が来ないバージョン」の側に回ります。

こういうときこそ、「サーバやミドルウェア（PHPなど、サイトを動かす土台のソフト）のバージョンアップを、誰が、どの費用で見るのか」を、改めてクライアントと話すよい機会です。

【ここに自社の保守契約での線引きの考え方を入れる】

聞ける雰囲気でないときにどう動くか

エンジニアが緊急対応に追われていて、とても質問できる雰囲気ではない。そんな状況もあると思います。それなら、落ち着いてから聞けば大丈夫です。

その間、エンジニアが対応している横で「自分の担当案件のバージョン一覧を作りましょうか」と動けるディレクターは、本当にありがたい存在です。たとえば、次のような一覧があるだけで、影響確認やクライアントへの連絡がぐっと速くなります。

案件名	サーバ・提供元	PHPのバージョン	更新担当者	保守契約	対応状況
例：コーポレートサイト	例：利用中のサーバ会社	確認中	クライアント／サーバ会社／保守会社	あり／なし	未確認