PHP2Shellと「パッチが追いつかない」問題：Webサイトの前にCloudflareというセキュリティゲートを置く

2026年10月末、Webサイトの運用者はPHPのコアに存在する脆弱性PHP2Shellへの対応に追われました。技術チームがパッチ適用、アップデート、確認作業を進める一方で、攻撃者はパッチが公開される前から攻撃を始めていました。

本記事では、PHP2Shellで何が起きたのか、なぜパッチ適用だけでは間に合わないのか、そしてパッチ適用と並行して取れる補完策として、CloudflareでWebサイトの入口にセキュリティゲートを置く方法をまとめます。

1. PHP2Shellで何が起きたのか？

2026年10月21日、PHPは重大な2つの脆弱性CVE-2026-109618およびCVE-2026-109619（総称：PHP2Shell）を公表しました。いずれもCVSS v4.0スコアで9.2/10と評価されており、W3Techsによると世界中のウェブサイトの約70%で稼働しているPHPプラットフォーム自体に存在します。

注目すべき点は、修正パッチがリリースされる前に情報が漏洩し、実際の攻撃が行われていたことです。

2. PHP2Shellはどれほど危険なのか？

PHP2Shellを悪用すると、攻撃者はログインせずにリモートからコードを実行したり、メモリ上の機密データを読み取ったり、サービスを停止させたりできます。脆弱性はPHPのコアそのものにあるため、PHP 5.4以降を実行するすべてのWebサーバーが影響を受けます。

仕組み：2つのメモリ管理の不具合

どちらの不具合も、PHPがHTTPリクエストを処理している途中で中断されたときに発生します。

• CVE-2026-109618: メモリ不足になると、PHPはリクエストの内部データが半分しか初期化されていない状態で停止します。その後のクリーンアップ処理が、この不完全なデータを有効なデータとして扱ってしまいます。
• CVE-2026-109619: 致命的エラー（fatal error）の後も、内部状態が解放済みのメモリ領域を指したままになります。同じプロセスで処理される次のリクエストが、この古い状態を再利用する可能性があります。

攻撃者は特別に細工したリクエストでこれらの状況を引き起こします。PHPのアップロード進捗トラッキング機能（session upload progress）は、確認済みの攻撃経路の一つです。

影響を受けるのは？

PHPによると、Web向けのすべての実行方式にリスクがあります：PHP-FPM、Apache＋mod_php、php-cgi、FrankenPHP、LiteSpeed。最もリスクが高いのはmod_phpで、認証不要のリクエストによって、アプリケーションのコードが動く前に攻撃が成立する可能性があります。

脆弱性を公表した研究チームの一つはWordPress、Drupal、Joomlaで検証を行い、ログイン不要でリモートからコードを実行できること、さらにPHPのメモリからパスワード、認証トークン、APIキーを読み取れることを確認しました。

企業にとって何を意味するのか？

• サーバーの制御を失う：攻撃者がマルウェアを仕込んだり、Webサイトの内容を改ざんしたりできます。
• データ漏えい：顧客情報、データベースのパスワード、APIキーが盗み読まれる可能性があります。
• 事業の中断：Webサイトが停止させられ、販売や顧客対応に影響が出る可能性があります。

WordPressやプラグインを更新しても、この脆弱性は修正されません。サーバー上で動いているPHPそのものを更新する必要があります。

3. なぜパッチ適用だけでは間に合わないのか？

PHPへのパッチ適用は、PHP2Shellを根本から修正する唯一の方法です。しかしPHP2Shellの事例は、攻撃者が動き出してからサーバーへのパッチ適用が完了するまでの間に、常に空白期間があることを示しています。その空白期間には4つの理由があります。

1. 攻撃がパッチより先に来る。情報は公表日より前に漏えいしており、Cloudflareはパッチ公開前から顧客を狙った攻撃トラフィックを観測していました。
2. すぐにパッチを当てられるとは限らない。多くのWebサイトは、プロバイダーがPHPを管理するホスティング上で動いています。その場合、企業はプロバイダーの更新を待つしかありません。
3. 古いバージョンにはもうパッチが出ない。PHP 8.1以前は、PHPプロジェクトから更新が提供されなくなっています。PHP 8.2も2026年12月31日にサポートが終了します。
4. パッチ適用後も派生脆弱性が残り得る。2日後、PHPはCVE-2026-115560を公表しました。一部のまれな構成では、8.5.12などパッチ適用済みのバージョンも影響を受けます。この派生脆弱性は次回の定期リリースで修正される予定です。

これこそが運用者にとっての「パッチが追いつかない」問題です。では、パッチを待つ間のリスクをどう減らせばよいのでしょうか？

4. 補完策：Webサイトの入口にセキュリティゲートを置く

サーバーごとのパッチ適用だけに頼るのではなく、もう一つの層を加えることができます。Webサイトへのすべてのトラフィックが、まず検問ゲートを通るようにするのです。このゲートは、悪意のあるリクエストが実際のサーバーに届く前にふるい落とします。Cloudflareはこの方式で動くサービスの一つで、サーバーの前に立ってトラフィックを検査し、攻撃の兆候があるリクエストをブロックします。

Cloudflareとは？

Cloudflareはインターネットインフラ企業で、コンテンツ配信ネットワーク（CDN）、Webアプリケーションファイアウォール（WAF）、DDoS攻撃対策などのサービスを提供しています。利用者の目に触れることは少ないものの、世界のWebサイトの約20%がこのサービスを利用しています。

非常に多くのWebサイトの前に立っているため、Cloudflareはネットワーク全体で新しい攻撃を観測し、すべての顧客向けにルールを更新できます。したがって、この防御層の効果は、ルールがどれだけ速く更新されるかに左右されます。

セキュリティゲートはどう機能するのか？

WebサイトのDNSレコードでプロキシを有効にすると、訪問者は実際のサーバーではなくCloudflareに接続します。Cloudflareがリクエストを検査し、正当なリクエストだけをオリジンサーバーに転送します。サーバーの実IPアドレスも隠されます。

正常なリクエストはCloudflare経由でオリジンサーバーに届きます。オリジンIPへの直接アクセスは、サーバーが以下の項目のように設定されている場合にのみブロックされます。

実際のサーバーを確実に守るための条件

IPを隠すだけでは不十分です。攻撃者がオリジンIPを突き止めれば、Cloudflareを迂回してサーバーに直接アクセスできます。Cloudflareは次の対策を推奨しています。

• オリジンサーバーへの接続はCloudflareのIPレンジからのみ許可し、それ以外はすべて遮断する。
• プロキシを経由しないDNSレコード（SPF、TXTなど）を見直し、サーバーのIPが漏れていないか確認する。
• メールサービスをWebサイトと同じサーバーに置かない。メールからIPが漏れる可能性があるため。
• Cloudflareへの移行後にサーバーのIPを変更する。過去のDNS履歴に古いIPが残っているため。
• またはCloudflare Tunnelを使う：サーバー側からCloudflareへ専用の接続（トンネル）を張るため、公開IPもポート開放も不要で、攻撃者が直接アクセスする経路がなくなります。

5. CloudflareはPHP2Shellをどうブロックしたか？

Cloudflareは脆弱性が正式に公表される前からPHP2Shellをブロックするルールを有効にしており、CloudflareのWAFを利用する顧客は、Freeプラン・有料プランを問わずデフォルトで保護されていました。

Freeプランと有料プランの違いは？

• Freeプラン：新しいルールはCloudflare Managed Free Rulesetに含まれ、自動で有効になります。追加の作業は不要です。
• Pro、Business、Enterpriseプラン：ルールはCloudflare Managed Rulesetに含まれます。管理者は、このルールセットがBlock（ブロック）モードで展開されているか確認してください。

新機能が必要だった理由：Full Transaction Detection

Cloudflareによると、リクエストだけを見ても、攻撃と通常のアクセスを常に区別できるとは限りません。そこで同社はFull Transaction Detectionを開発しました。同じHTTPトランザクション内のリクエストとオリジンサーバーからの応答の両方を検査する新しいWAF機能です。

この機能による防御は2段階です。

1. 明らかな攻撃の兆候があるリクエストは、Cloudflareで即座にブロックされます。
2. リクエストがすり抜けた場合でも、Cloudflareはオリジンサーバーの応答が攻撃者に届く前にブロックできます。これにより、漏えいしたデータが外部に出るのを防ぎます。

PHP2Shellのブロックルールは、Cloudflareがこの機能を使って公開した最初のルールです。この機能はFreeを含むすべてのプランで自動的に有効になっています。

終わりのない競争

Cloudflareは、攻撃者がルールを回避するためにペイロードを絶えず変化させていることを確認しており、同社の分析チームはそれに合わせてルールを更新しています。

10月23日に公表された派生脆弱性CVE-2026-115560について、Cloudflareは既存のルールで引き続き保護できるとしています。ただし条件があり、Webサイトがsession.upload_progress.nameのデフォルト名を変更していないことが前提です。

6. セキュリティ以外のメリット：高速化、負荷軽減、低コスト

入り口にCloudflareを設置することは、単なる攻撃防御にとどまりません。同じレイヤーによって、運用面で3つの大きなメリットが得られます。

• ウェブサイトの読み込みが高速化。 Cloudflareは世界中のデータセンターにコンテンツのコピー（キャッシュ）を保持し、ユーザーの近くから配信します。
• サーバー負荷の軽減。 キャッシュからコンテンツが配信されるため、オリジンサーバーへ到達するリクエスト数が減少します。また、DDoS防御もCDNと統合されています。
• 低い初期導入コスト。 無料（Free）プランでもPHP2Shellブロックルールを含むWAFルールセットが自動有効化されます。より高度なルールセットが利用できるProプランは年払いで月額20ドルから利用可能です。

（AWSやAzureなどのクラウドプロバイダーも同様のWAFサービスを提供していますが、料金体系やデフォルト構成が異なります。）

導入は複雑なのか？

多くの場合、システムの書き換えは不要です。主なステップは、ドメインのDNS管理をCloudflareに移管し、ウェブサイトのDNSレコードでプロキシを有効にするだけです。

ただし、オリジンサーバーへの直接アクセスを防ぐには、セクション4に記載されている追加のサーバー設定が必要です。この作業は技術チームが実施することが推奨されます。

7. Cloudflareは万能薬ではない

Cloudflareはパッチ適用までのリスクを軽減しますが、PHPのパッチ適用の代わりにはなりません。Cloudflare自身も顧客に対してPHPのパッチ適用を強く推奨しており、WAFを補次的な防御レイヤーとして位置付けています。知っておくべき6つの限界があります：

1. ルールが存在するもののみブロック可能。 WAFはベンダーが発行したルールに基づいて攻撃を検出します。新しい脆弱性に対してルールが未提供の場合、背後のウェブサイトは悪用される可能性があります。PHP2Shellでは公表前にルールが有効化されましたが、次回も同様である保証はありません。
2. すでに実行された処理は取り消せない。 レスポンスをブロックしてデータ流出を防ぐことはできますが、オリジンサーバー上で実行されてしまったコードを取り消すことはできません。
3. ルールは回避される可能性がある。 攻撃者はWAFを迂回するためにペイロードを常に変化させます。
4. Cloudflareを経由するトラフィックのみ保護。 オリジンサーバーのIPに直接送信されたリクエストは検査されません。
5. 設定に依存する。 有料プランでは正しいBlockモードの設定が必要です。また、session.upload_progress.nameを変更したサイトは、亜種CVE-2026-115560に対してWAFで保護されません。
6. 外部依存関係が増加する。 Cloudflareで障害が発生した場合、これを利用しているウェブサイトも影響を受けます。

8. 企業が今すぐやるべきこと

最も重要なのはPHPへのパッチ適用です。その他の手順は、パッチ適用中と適用後のリスクを減らすためのものです。

根本対策：パッチ適用

• ☐ PHPが動いているサーバーとそれぞれのバージョンを洗い出す。ホスティング事業者がPHPを管理している場合は、更新を依頼する。
• ☐ 利用中のブランチに応じて、8.2.35、8.3.36、8.4.27、8.5.12以降にアップグレードする。
• ☐ PHP 8.1以前：ディストリビューターや長期サポート（LTS）事業者に連絡してバックポートされたパッチを入手するか、サポート中のバージョンにアップグレードする。
• ☐ 2026年12月31日までにPHP 8.2からの移行を計画する。

一時的なリスク軽減（パッチ適用の代わりにはならない）

• ☐ session.upload_progress.enabled=0をphp.ini、FPMプール、またはサーバー設定で設定し、すべてのワーカーを再起動する。この設定にはini_set()や.user.iniを使わない。
• ☐ CVE-2026-115560を防ぐため、PHPの次回定期リリースまでこの設定を維持する。

Cloudflareのセキュリティゲート

• ☐ Webサイトを指すDNSレコードでプロキシ（オレンジの雲）を有効にする。
• ☐ オリジンサーバーへの直接アクセスを遮断する：ファイアウォールでCloudflareのIPのみ許可するか、Cloudflare Tunnelを使い、cloudflaredを定期的に更新する。
• ☐ 有料プラン：Managed RulesetがBlockモードになっているか確認する。
• ☐ CloudflareのSecurity > Security Analytics > EventsでPHP2Shellのルールを絞り込み、Webサイトがスキャンされたかどうかを確認する。

9. Webサイトが攻撃された疑いがある場合

PHP2Shellはパッチ公開前に悪用されていたため、その期間にパッチが間に合わなかったWebサイトは確認が必要です。異常の兆候が見つかった場合は、次の順序で対応してください。

1. サーバーを隔離する。オリジンサーバーのネットワーク接続を切断します。Cloudflareのルールによるブロックは、Cloudflareを経由するトラフィックにしか効かず、サーバーへの直接アクセスは防げません。
2. ログを確認する。Cloudflareのセキュリティイベント（PHP2Shellのルールで絞り込み）とWebサーバー・PHPのログを照合し、攻撃リクエストがいつ、どこから来たかを把握します。
3. 再開前にPHPにパッチを当てる。クリーンなバックアップから復元しても、パッチ未適用のサーバーでは再び攻撃される可能性があります。
4. すべての秘密情報を変更する。データベースのパスワード、APIキー、トークン、アプリケーションの秘密鍵を変更します。この脆弱性により、これらを含むPHPメモリ上のデータが漏えいした可能性があるためです。

10. まとめ：内側でパッチを当て、入口で守る

PHP2Shellは、パッチが出る前に攻撃者が動き得ることを示しました。PHPへのパッチ適用は必須ですが、Cloudflareのようなセキュリティゲートはパッチ適用が完了するまでの空白期間のリスクを減らすのに役立ちます。しかも低コストで始められ、多くの場合システムを大きく変える必要もありません。

対策は2層構成です。内側でソフトウェアにパッチを当て、入口ではCloudflareが守る。2つの層は互いに補完し合い、どちらも他方の代わりにはなりません。

参考資料

• Cloudflare – Cloudflare deploys protections against php2shell vulnerability
• PHP.net – News Archive 2026（10/21および10/23のアドバイザリ）
• Cloudflare Docs – Protect your origin server
• Cloudflare Docs – Secure your origin
• Cloudflare Docs – Restrict external connections
• Kinsta – Cloudflare Market Share
• PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet
• Cloudflare – Plans