チェック・ポイントが警告、PHP脆弱性「PHP2Shell」でWeb基盤の更新判断が急務に

編集: グリットアーツ編集部

公開日：2026年11月2日

3行解説

ニュースの概要

チェック・ポイント・リサーチは2026年10月30日、PHPの重大な脆弱性2件を狙う攻撃について最新分析を公開した。対象は「PHP2Shell」と呼ばれるCVE-2026-109618とCVE-2026-109619で、正式公開前の情報漏えい後、世界中の組織の10％が標的になったという。攻撃は深夜0時に活発化し、欧州では14％が標的となった。オランダとフィンランドでは、被害防止のため一部サイトを停止したとされる。

同社は、影響がWordPress、Drupal、Joomla、MagentoなどのWeb基盤や、共有ホスティング、cPanel、Plesk、商用アプリケーションに及ぶと説明した。攻撃者はログイン不要でサーバー上で任意のコードを実行でき、データ窃取や他システムへの攻撃、サービス停止につながるおそれがあるとしている。

何が新しいのか

今回のポイントは、脆弱性の場所がCMSではなくPHPエンジンそのものにあることだ。つまり、Webサイトの管理画面やプラグインを更新しても対処できず、サーバー側のPHPを直接更新しなければならない。修正版はPHP 8.2.35、8.3.36、8.4.27、8.5.12で提供され、PHP 8.1以前はバックポートがない限り脆弱なままとされる。

また、攻撃の広がり方も実務上の意味が大きい。正式公開前の情報漏えいで防御側の準備期間が短くなり、さらに攻撃ツールのスクリーンショットも出回り始めた。単なる理論上の脆弱性ではなく、実際の悪用が進みやすい状況に入っていると読める。

グリットアーツ編集部の分析

このニュースで重要なのは、チェック・ポイントが「CMS更新では不十分」「PHP 8.1以前は特に注意」と明示した点だ。多くの企業では、Web担当とインフラ担当、外部ホスティング事業者の責任範囲が分かれており、どこでPHPが動いているかを把握できていないと対策が遅れる。公開Webを止める判断が必要になるケースもあるため、可用性より先に侵害拡大を防ぐ設計が問われる。

一方で、更新後に再起動して本当に修正版で動いているかを確認しなければ、見かけ上は対策済みでも脆弱なまま残る可能性がある。これは、パッチ適用だけで終わらず、監視・再起動・通信制限まで含めた運用手順が必要という意味だ。特に外部委託や共有ホスティングを使う企業では、確認先を先に決めておくことが実務上の分かれ目になる。

日本の現場で考えると

日本企業では、Webサイト本体は自社、実行環境はホスティング事業者、更新作業は別ベンダーという分担が珍しくない。そのため、まず「PHPがどこで動いているか」を棚卸ししないと、更新対象の切り分けができない。特にECサイトや会員サイトのように止めにくいサービスでは、更新の順番と停止時間を先に決める必要がある。

また、今回の脆弱性は侵害後の兆候として、不審なPHPファイルや外部通信、Webサーバープロセスによるコマンド実行が挙げられている。日本の現場では、パッチ適用後もログ確認と再起動確認をセットにしないと、復旧したつもりで再侵害を見逃すおそれがある。サポート終了版のPHPを残している環境は、短期延命ではなく更改計画の見直し対象になる。

導入・検討時に確認したいこと

• 自社のWeb基盤でPHPが動いている場所はどこか。CMS、プラグイン、商用アプリ、共有ホスティングを含めて洗い出せるか。
• 利用中のPHPバージョンは何か。PHP 8.1以前を使っている場合、バックポートの有無を誰が確認するか。
• 更新後に再起動が必要な範囲はどこか。Webサイト、関連サービス、周辺システムへの影響を事前に把握できるか。
• 外部ホスティングや委託運用の場合、パッチ適用状況を誰に確認し、どの証跡で確認するか。
• 即時対応できない場合、どのサービスを一時停止し、どの通信を制限するか。

現時点で分かっていないこと

実際に侵害に至った組織の数や、国内企業への影響範囲は本文では確認できない。修正版が適用できないPHP 8.1以前の環境について、個別にどこまでバックポートされるかも不明だ。攻撃ツールの流通状況や、各社の検知・封じ込めの実効性も、現時点では限定的な情報しかない。

公開Webやホスティング環境の更新判断は、止める範囲と再開条件を先に決めておくことが重要です。自社のWeb基盤で何を優先して確認すべきか整理したい場合は、運用面から見直すきっかけになります。

出典: PR TIMES