パッチだけでは終わらない理由と企業が今取るべき対策（ZDNET Japan）

　2026年10月21日、ウェブサイトを支えるプログラミング言語「PHP」に、重大な脆弱（ぜいじゃく）性が公表されました。「PHP2Shell」と呼ばれるこの脆弱性群は、条件がそろうとログインしていない第三者がサーバー上でプログラムを実行できるおそれがあるもので、国内でも安全確認のために一部のサービスを一時停止する動きが見られました。修正版はすでに公開されていますが、多くの企業にとって本当の課題は「パッチを当てること」そのものではなく、「自社のどこでPHPが動いているのかを、全て把握すること」にあります。本稿では、PHP2Shellの何が問題なのか、なぜ従来の手段では対応が難しいのか、そして企業が今取るべき対策を整理します。1. PHP2Shellとは何か　PHPは、「WordPress」などのCMSや、会員サイト、予約・注文システムなど、多くのウェブサイトや業務システムの土台として使われているソフトウェアです。調査会社の Wiz Research は、PHPが世界のウェブサイトの約7割を支えていると説明しています。　PHP2Shellは、このPHP本体に見つかった2件の脆弱性（CVE-2026-109618、CVE-2026-109619）の総称です。特定のウェブサイトやプラグインの不具合ではなく、その下で動く共通の土台の問題であるため、影響を受ける可能性のある範囲が非常に広いのが特徴です。深刻度は、PHPの開発元による評価でCVSS v4.0のスコア9.2（緊急）とされています。　PHPの開発チームは10月21日に修正版（8.5.12、8.4.27、8.3.36、8.2.35）を公開しました。米国のCISA（サイバーセキュリティ・インフラストラクチャセキュリティ庁）は組織に対して直ちに修正を適用するよう強く求め、国内でもIPA（情報処理推進機構）とJPCERT/CCが注意喚起を出しています。2. PHP2Shellが深刻な問題となっている背景ログイン機能では防げない段階で攻撃される可能性がある　ウェブサイトへの通信は、ウェブサーバーが受け付けた後、PHP本体が送られてきたデータを読み取って準備し、その後でWebサイト側のログイン確認や注文処理などが動く、という流れで処理されます。PHP2Shellの攻撃経路は、PHPの構成によって異なります。　PHP開発チームによると、CVE-2026-109618ではApacheのmod_phpで、アプリケーションコードが動き始める前に到達する経路が実証されており、PHP-FPMではアプリケーション側のコード経路を通じたリモートコード実行も確認されています。そのため、ログイン機能があるだけでは安全とは言えません。　また、攻撃経路によっては、アプリケーションの処理が始まる前に問題が起きるため、ウェブサイトの操作履歴だけでは、攻撃の手掛かりを十分に得られない場合があります。プログラムを実行されなくても、情報が漏れるおそれがある　研究者からは、不正なプログラムの実行に至らなくても、PHPが処理中に保持しているメモリーから、パスワードや認証トークン、APIキーなどを読み取れることも報告されています。「乗っ取られた形跡がないから情報漏えいの心配もない」とは言い切れない点も、今回の問題の厄介なところです。「攻撃は難しい」は安全の根拠にならない　公開されている攻撃の実演コードの多くは、実際にはうまく動作しないと報告されています。ただし、「攻撃が難しい」とは、公開コードをそのまま使うのが難しいという意味であり、脆弱性が悪用不能ということではありません。必要な技術と環境に応じた調整ができる高度な攻撃者にとっては、悪用可能性があります。　タニウムの脅威ハンティングチームは、未修正のPHP 8.5.11を使ったApache mod_php（x86-64、単一ワーカー）のラボ環境で、CVE-2026-109619について、HTTPリクエストのみでコード実行に到達することを確認しました（手法は悪用防止のため非公開としています）。　CISAは10月23日時点で、実環境での悪用の成功は観測していないとしていました。その後、10月26日にCVE-2026-109618とCVE-2026-109619の両方をKnown Exploited Vulnerabilities（KEV）Catalogに追加しました。CISAの基準では、KEV掲載は実環境での悪用試行または悪用成功について信頼できる証拠があることを示します。ハニーポットへの攻撃試行もこの基準に含まれるため、KEV掲載だけで個別組織の侵害を断定することはできませんが、米連邦行政機関向けには米国時間の10月29日までの対応期限が設けられています。国内でも相次いだ予防的な停止　国内では、修正版の公開直前から、安全確認や予防のためにサービスや機能を一時停止する動きが見られました。報道や各社の公式発表によれば、地方銀行のホームページとアプリ、自治体の公文書検索システム、ホスティング事業者やウェブ制作サービスの一部機能などが一時的に停止し、修正版の適用後に順次再開しています。

　公表された範囲では、いずれも攻撃による被害ではなく予防的な措置と説明されています。影響がウェブサイトの閲覧にとどまらず、アプリやフォーム送信など利用者向けの機能にも及び得ることを示す事例です。

3. PHP2Shellへの対応において考慮されるべき点　修正版はすでに公開されています。それでも対応が難しいのは、次のような理由で、従来の資産管理や脆弱性管理の手段では、PHPの所在とリスクを正確に把握しきれないためです。PHPの利用実態が把握しづらい点　CISAも、PHPは他のソフトウェアの構成要素として使われることが多く、利用の実態が直接見えない場合があると指摘しています。具体的には、次のようなケースがあります。　Windowsでは「インストール」されていないことが多い: PHPは圧縮ファイルを展開しただけの状態や、開発用のパッケージに同梱された形で置かれていることが多く、インストール済みソフトウェアの一覧に表示されません。業務アプリや製品に組み込まれている: 製品が独自のPHPを内蔵している場合、修正はOSの更新ではなく、製品の提供元の対応を待つ必要があります。コンテナの中にある: コンテナーイメージに含まれるPHPは、ホストのソフトウェア一覧には現れません。サーバーだけでなく、開発者の端末にもある: ローカルの開発環境やツールを通じて、業務用PCにPHPが入っていることがあります。　インストール済みソフトウェアの一覧や、定期的に作成する資産台帳を前提とした管理では、こうしたPHPを見落とす可能性があります。バージョン番号だけで判断するリスク　Linuxの多くのディストリビューションでは、古いバージョン番号のまま修正を取り込む「バックポート」という方式で更新が提供されます。そのため、バージョン番号だけで判定すると、修正済みのものを「脆弱」と誤認したり、その逆が起きたりします。ネットワーク越しに外部から確認する方法では、そもそも内部のバージョンや構成までは分かりません。URLの拡張子や外部からの診断結果だけで影響の有無を決めず、実際の稼働環境と製品・サービス提供元の情報を照合する必要があります。すぐに更新できないシステムの存在　日本経済新聞は、PHPを利用するサイトの半数では、開発元が公表した修正の適用が難しいとの推計を報じています。サポートが終了した古いPHPや、長期間更新されていないサイトが背景にあるとみられます。古いバージョンからの移行には、アプリケーションの互換性確認が必要になるため、「パッチを配れば終わり」とはいきません。監視と痕跡発見の難しさ　前述のとおり、攻撃経路によってはアプリケーションの処理より前の段階で問題が起こるため、アプリケーションのログやWAF（ウェブアプリケーションファイアウォール）だけでは見逃す可能性があります。　JPCERT/CCは、WAFや設定変更などの緩和策は特定の攻撃経路への対処にとどまり、アップデートのみが対策であると説明しています。また、痕跡が見つからなくても攻撃を受けていないとは断定できない、とも注意を促しています。修正前に侵害されていた場合、後からパッチを当てても侵入された事実は消えません。　つまり、今回求められているのは、（1）全てのPHPを見つけ、（2）正確なリスクを判断し、（3）修正を確実に反映し、（4）修正前の侵害の有無まで確かめる、という一連の作業です。これを、台帳や手作業の突き合わせで短期間に終えるのは容易ではありません。4. 企業が今取るべき対策　CISA、IPA、JPCERT/CCの推奨と、タニウムの調査チームの知見を踏まえると、企業は次の順序で対応を進めることが有効です。全てのPHPを洗い出す。 サーバー、業務用PC、製品に組み込まれたもの、コンテナを含め、所在と正確なバージョンを記録します。インターネットへの露出度に応じて優先順位を付ける。 インターネットに公開しているシステムを最優先とし、構成や業務への影響を踏まえて順位を決めます。修正版へ更新し、確実に反映する。 OSや製品の提供元の案内に従って更新し、PHPやウェブサーバーを再起動して、新しいプログラムが実際に動いていることを確認します。すぐに更新できない場合は、リスクを抑える措置をとる。 外部からのアクセス遮断や一時停止を含めて検討し、設定変更やWAFなどの緩和策は「更新までのつなぎ」と位置付けます。期限と責任者を決めて、放置しないことが重要です。侵害の痕跡を確認する。 ウェブサーバーのプロセスが不審なプログラムを起動していないか、不審なファイルが書き込まれていないか、見覚えのない外部への通信がないかを確認します。Amazonは、少なくとも10月17日にハニーポットで悪用の試みを観測したと報告しています。調査対象は公表日以降に限定せず、少なくとも同日までさかのぼって確認します。情報漏えいが疑われる場合は、影響し得るパスワードや認証情報の変更も検討します。古いPHPや不要なサイトを整理する。 サポートが終了したPHPは移行を計画し、使われていないサイトは所有部門と確認の上で停止・廃止します。5. AI時代の脆弱性対応に求められるもの　今回の脆弱性は、AIを活用した研究によって発見や検証が進んだと報告されています。Wiz Research は、10年以上存在していた欠陥について、AIを使った発見や悪用可能性の検証を行ったと公表しています。AIによって脆弱性の発見が加速すれば、公表から攻撃が始まるまでの時間も短くなっていくと考えられます。今回も、修正版の公開前から悪用の試みが観測されていました。　こうした状況では、脆弱性が公表されるたびに「どこで使っているか」の調査から始めていては間に合いません。平時から、端末やサーバー上のソフトウェアを部品レベルでリアルタイムに把握し、外部への露出や業務への影響を踏まえて優先順位を付け、更新や隔離といった対処、そして結果の確認までをつなげておくことが求められます。自動化できる部分は自動化しつつ、重要なシステムの停止や変更の判断は、事業への影響を踏まえて人が行う。その体制を、担当者個人の努力に頼らず、組織の運用として整えておくことが重要です。6. おわりに　PHP2Shellは、特定の製品の問題ではなく、多くのシステムが共有する「土台」に影響の大きな脆弱性が見つかった事例です。今後も同様の事態は起こり得ます。重要なのは、脆弱性が公表されたその日に「どこに、何が、どの状態であるのか」を答えられること、そして修正を確実に反映し、その結果を確かめられることです。　タニウムは、今回の状況を踏まえ、「フロンティア AI レスキュープログラム」による無償ライセンスの利用期間を2027年3月末まで延長します。本プログラムは、タニウムを未導入で、1500〜2万台規模のエンドポイントを持つ組織を対象に、Core、Endpoint Management、Exposure Managementの無償ライセンスを最長6カ月間提供するものです。参考情報・PHP Foundation「Today's PHP Security Release, and How We're Strengthening PHP Security」（2026/10/21）・CISA「Critical Vulnerabilities in PHP Require Immediate Patching」（2026/10/23改訂）・IPA「PHPの脆弱性対策について」（2026/10/22）・JPCERT/CC「PHPにおける複数の脆弱性に関する注意喚起」（2026/10/22）・Wiz Research「PHP2Shell」（2026/10/21）・日本経済新聞「PHP脆弱性、利用サイトの半分が修正困難　バージョン古くサポート終了」（2026/10/23）・タニウム ブログ「PHP2Shell: Responding to CVE-2026-109618 and CVE-2026-109619」（2026/10/21）・HuntIQ「Why php2shell Is Real and Still Hard to Exploit」（2026/10/22）・HuntIQ「Hunting php2shell Post-Exploitation with Tanium」（2026/10/22）小松 康二タニウム合同会社　上席執行役員副社長　最高技術責任者

タニウム製品を有効活用いただくための提案や導入運用支援を行うチームを統括している。タニウム入社前は、米国ネットワーク機器製造ベンダーの日本法人をはじめ、米国IT企業3社の日本法人にて、一貫してITインフラやセキュリティソリューションの日本の顧客への導入に従事してきた。2018年にタニウムに入社し、顧客のタニウム導入やパートナーのマネージドサービスの開発を支援。2020年から日本および韓国のテクニカルアカウントマネジメントチームを統括し、2022年からアジア太平洋日本地域のテクニカルアカウントマネジメントチームおよびエンタープライズサービスチームを統括する。著書には「SDNの実践技術（インプレスR＆D）」など。