【緊急】PHPに深刻な脆弱性「php2shell」— Cloudflareは公開の約9時間前から防御。次の脆弱性にも先手を打つ仕組みとは

2026年10月29日

2026年10月21日、Webサイトの約7割で使われているプログラミング言語「PHP」に、外部から攻撃者のコードを実行されるおそれのある深刻な脆弱性「php2shell」（CVE-2026-109618／CVE-2026-109619）が公開されました。

Cloudflareはこの脆弱性に対し、公開の約9時間前からWAF（Webアプリケーションファイアウォール）で防御を始めていました。
サーバーのPHPを更新するまでの「無防備な時間」を、Cloudflareが肩代わりした形です。

本記事では、php2shellの概要と危険性、CloudflareのWAFがどのように攻撃を止めているのかを解説します。
あわせて、Cloudflareを導入していると何が違うのか、そして今後同じような脆弱性が出たときにもCloudflareが先手を打ってくれる理由を紹介します。

php2shellとは？PHPそのものに潜む脆弱性

php2shellは、PHP 5.4以降を動かしているすべてのWebサーバーが影響を受ける脆弱性です。WordPressなど、PHPで動くCMS・ECサイト・自社開発のシステムは、ほぼすべて対象になり得ます。

項目	内容
通称	php2shell
CVE番号	CVE-2026-109618、CVE-2026-109619
公開日	2026年10月21日
影響範囲	PHP 5.4以降を実行するWebサーバー
想定される被害	PHPのクラッシュ（サイト停止）、機密情報の漏えい、攻撃者のコード実行
根本対策	PHPを修正版に更新する

仕組みをざっくり説明すると

PHPは、メモリ不足などで処理が途中で止まったとき、「後片付け」を安全に行えないことがありました。

CVE-2026-109618：準備が終わっていないデータを、後片付けのときに使ってしまう
CVE-2026-109619：中断したリクエストの情報が残り、次のリクエストがすでに無効なメモリを使ってしまう

攻撃者は細工したHTTPリクエストを送るだけでこの状態を作り出し、サーバー上で好きなコードを動かせる可能性があります。

さらに10月23日には、関連する脆弱性 CVE-2026-115560（セッションのアップロード進捗機能に関するもの）も公表されました。
こちらは最新のPHP 8.5.12でも未修正で、次回の定期リリースで修正される予定です。

なぜ危険なのか？3つのポイント

1. プラグインやアプリを更新しても直らない

問題はWordPressやプラグインではなく、PHPの実行環境そのものにあります。普段の「プラグイン更新」では対応できず、サーバー側のPHPを入れ替える必要があります。

2. すぐには更新できないサイトが多い

PHPの更新は、動作確認やレンタルサーバー事業者の対応待ちが発生しやすく、「公開されたその日に更新」は現実的に難しい作業です。古いPHPでしか動かないシステムも少なくありません。さらに関連脆弱性 CVE-2026-115560 は、修正版がまだ出ていません。

3. 攻撃は公開直後から始まる

Cloudflareはすでにこの脆弱性を狙った攻撃を観測しており、攻撃者が防御をすり抜けようと攻撃コードを変形させてくる動きも確認しています。脆弱性が公開されると、攻撃者は条件を確かめることなく世界中のサイトを機械的に探し回ります。「うちのような小さなサイトは狙われない」は通用しません。

つまり、脆弱性の公開からPHPを更新し終えるまでの「空白期間」をどう守るかが、被害を出すかどうかの分かれ目になります。

CloudflareのWAFはどう守ったのか

公開の約9時間前に防御ルールを配信

Cloudflareは脆弱性の公開に先立ち、2026年10月21日 3:02（UTC）に専用のWAFルールを世界中のネットワークへ配信しました。マネージドルールを有効にしているサイトでは、利用者が何もしなくても、公開された瞬間からすでに守られていたことになります。

このように、サーバーを直す前にWAFで攻撃を止めるやり方を「仮想パッチ」と呼びます。パッチを当てるまでの時間を稼ぐ、もっとも現実的な守り方です。

新機能「フルトランザクション検出」で、行きも帰りもチェック

従来のWAFは、主に「入ってくるリクエスト」を検査する仕組みでした。今回、Cloudflareは**リクエストと、サーバーから返るレスポンスをセットで分析する「フルトランザクション検出」**を新たに開発し、php2shell対策がその最初の適用例となりました。

行き（リクエスト）：攻撃の特徴を持つリクエストを、サーバーに届く前にブロック
帰り（レスポンス）：万一すり抜けても、攻撃が成功したとき特有の応答を検知し、攻撃者に届く前にブロック

攻撃者がリクエストの形を変えてきても、「結果」の側でもう一度止められる二段構えの防御です。また、新しい手口が見つかるたびにCloudflareがルールを更新しており、10月23日には関連脆弱性 CVE-2026-115560 の既知の攻撃にも対応しました。

Cloudflareを導入していると、何が変わるのか

Cloudflareでは、Cloudflareのセキュリティチームが防御ルール（マネージドルール）を作成し、世界中のネットワークへ配信・更新します。今回のphp2shell対策ルールも、利用者が操作することなく自動で配信されました。自社で脆弱性情報を追いかけ、防御ルールを書く必要はありません。

Cloudflareで得られるもの	php2shellでは
マネージドルール（WAF）	専用ルール「PHP Remote Code Execution Attack」#1〜#7を、脆弱性の公開前に配信
レスポンス側の検査	攻撃が成功したときの応答を、攻撃者に届く前にブロック
ルールの継続的な更新	攻撃コードの変形や、関連脆弱性 CVE-2026-115560 にも追従
Security Analytics	どの攻撃を止めたかを、ダッシュボードで確認できる

導入後に大切なのは「ブロック」で動かすこと

導入後は、マネージドルールが「ブロック」で動いているかを確認しておきましょう。
ルールが入っていても、「ログのみ」の設定では攻撃は止まりません。

また、関連脆弱性 CVE-2026-115560 への防御（ルール#6）が効くのは、PHPの設定 session.upload_progress.name が初期値のままのサイトだけです。
導入するときは、WAFの設定とサーバー側の設定をあわせて確認することが大切です。

なお、ルールは今後も攻撃の変化に合わせて更新されます。
最新状況は Cloudflare WAFの変更履歴で確認できます。

導入前に確認しておきたいチェックリスト

WAFは「PHPを更新するまでの時間を稼ぐ盾」であり、PHPの更新は引き続き必要です。
そのうえで、Cloudflareの導入を検討するときは、次の点を確認しておくとスムーズです。

サイトがPHPで動いているか、バージョンは何か（PHP 5.4以降は影響あり）
PHPをすぐに修正版へ更新できるか（難しいほど、WAFで守る期間が長くなる）
ファイルアップロードなど、狙われやすい機能があるか（不要なものは止め、サイズに上限を設ける）
session.upload_progress.name を初期値から変更していないか
導入後、WAFを「ブロック」で運用し、検知状況を確認できる体制があるか（社内で難しければ代理店の運用支援を使う）

今回の教訓：次の脆弱性でも、Cloudflareなら先手を打てる

今回の件で、Cloudflareを使っているサイトとそうでないサイトの差ははっきりしました。

	CloudflareのWAFあり	WAFなし
脆弱性の公開時点	すでに防御ルールが稼働	無防備
PHP更新までの間	攻撃をブロックしながら落ち着いて更新できる	更新が終わるまで攻撃にさらされる
攻撃の変形	Cloudflareがルールを随時更新	自力で情報収集・対応
修正版がない脆弱性	WAFで既知の攻撃を防ぐ	打つ手が限られる