2026 年 10 月 21 日、PHP ランタイムの脆弱性「php2shell」（CVE-2026-109618、CVE-2026-109619）が公開されました。PHP 5.4 以降を使うすべての Web サーバーが対象になる深刻な脆弱性で、各所でパッチの適用が続いています。
Cloudflare は公開の約 9 時間前から WAF のルールを展開しており、10 月 21 日 3:02（UTC）、日本時間 12:02 の時点で、Free プランを含む WAF を利用しているお客様は既定で保護されていました。
一方で、お客様と話していると次のような状況をよく目にします。
- オリジンサーバーへのパッチ適用だけに追われ、その間の攻撃を観察・制御する手段がない
- PHP の対応に集中するあまり、同じ週に公開された別の脆弱性に気づいていない
この記事では、エッジのセキュリティで「いま」の攻撃を止め、時間を確保したうえで構造そのものの更新を計画する、という進め方を紹介します。あわせて、先日公開した設計ガイドで実際の画面を確認できる箇所と、PHP に依存しない CMS である EmDash も紹介します。
php2shell で何が起きているか
php2shell は、PHP が HTTP リクエストの処理中にエラーを扱うときの、メモリの管理に起因する脆弱性です。細工した HTTP リクエストによって、次のことが起きる可能性があります。
- PHP プロセスのクラッシュ（サービス停止）
- 機密情報の漏えい
- 攻撃者が送り込んだコードの実行（リモートコード実行）
| CVE | 内容 |
|---|---|
| CVE-2026-109618 | メモリ不足で処理が中断され、初期化が終わっていない内部データを、後片付けの処理が有効なデータとして使ってしまう |
| CVE-2026-109619 | 致命的なエラーで中断されたリクエストのメモリへの参照が残り、同じプロセスが次に処理するリクエストで解放済みのメモリにアクセスしてしまう |
重要なのは、これがアプリケーションやプラグインではなく、PHP ランタイム自体の脆弱性だという点です。WordPress のプラグインを更新しても解決せず、PHP 本体の更新が必要です。ホスティング事業者が PHP を管理している場合は、事業者による更新を待つことになります。
また、今回は正式な公開日の前に情報が漏れており、Cloudflare は公開前の時点で攻撃トラフィックを観測しています。攻撃者が保護を回避しようとペイロードを変化させていく様子も確認されています。「パッチを当てるまでの数日間」は、すでに攻撃を受けている期間だということです。
氷山の一角：同じ週に公開された BIND 9 の脆弱性
php2shell の翌日、10 月 22 日には JPRS から BIND 9 の脆弱性（CVE-2026-94300）について緊急の注意喚起が出ています。
| 項目 | 内容 |
|---|---|
| 対象 | BIND 9.11.0 以降のすべてのバージョン |
| 原因 | GSS-TSIG の実装の不具合。署名した UDP メッセージの再送で named のメモリ破壊を誘発できる |
| 影響 | サービスの停止、リモートコード実行の恐れ（ISC の評価は「高」） |
| 回避策 | なし。BIND 9.20.30 またはディストリビューションの更新を適用する |
| 注意点 | サポートが終了した系列には、ISC からセキュリティパッチが提供されない |
PHP は HTTP の層、BIND は DNS の層です。PHP の対応だけに目を向けていると、こうした別の層の脆弱性を見落とします。そして、層が違えば守り方も違います。ここが今回いちばんお伝えしたい点です。
Cloudflare WAF が「いま」できること
1. マネージドルールによる自動の保護
php2shell に対するルールは、Cloudflare が作成・更新するマネージドルールとして自動で展開されています。
| プラン | ルールセット | お客様の操作 |
|---|---|---|
| Free | Cloudflare Managed Free Ruleset | 不要（自動で有効） |
| Pro / Business / Enterprise | Cloudflare Managed Ruleset | ルールセットがデプロイされ、ブロックのモードになっているかを確認する |
有償プランでは、マネージドルールセットがデプロイされていなければ保護されません。ダッシュボードの セキュリティ ＞ セキュリティ ルール で、管理ルールの状態を確認してください。新しいルールの追加は WAF の changelog で追跡できます。
2. リクエストとレスポンスを組み合わせて判定する（full transaction detection）
php2shell の検出は、リクエストを見るだけでは難しいケースがありました。正常なリクエストと攻撃を区別する根拠が、リクエストの中だけでは足りないためです。
そこで Cloudflare は、同じ HTTP トランザクションのリクエストとレスポンスを組み合わせて判定する full transaction detection と、オリジンのレスポンスを攻撃者に届く前にブロックする レスポンスルール を新たにリリースしました。php2shell の保護は、この仕組みを使った最初のマネージドな検出です。
flowchart LR A[攻撃者] -->|細工したリクエスト| B[Cloudflare WAF<br/>リクエストの検査] B -->|ブロック| X[403] B -->|判定できず通過| C[オリジン<br/>PHP] C -->|レスポンス| D[Cloudflare WAF<br/>レスポンスの検査] D -->|攻撃が成功した兆候| Y[レスポンスを差し替えてブロック] D -->|問題なし| E[利用者]
| 機能 | 内容 | 対象プラン |
|---|---|---|
| Cloudflare Managed Response Firewall Default | レスポンス側のマネージドな検出。一致するとレスポンスをブロックし、WAF のブロックページを返す | Free を含む全プラン（自動でデプロイ） |
| カスタムのレスポンスルール | リクエストとレスポンスの項目を組み合わせた独自のルール。アクションはログとブロック | 全プランで最大 3 件 |
cf.waf.signature.response.* フィールド |
レスポンス側の検出結果（確度、カテゴリ、シグネチャ ID）をルールの条件に使う | 有償プラン（順次展開中） |
レスポンスルールは、攻撃者に情報が渡るのを止めるものです。オリジン側ですでに実行された処理を取り消すことはできません。だからこそ、パッチの適用が不要になるわけではありません。
3. 観察しながら対応する
WAF の価値は「止める」だけではありません。セキュリティ ＞ Analytics ＞ イベント でルール ID を指定して絞り込むと、どのパスに、どのような攻撃が、どれだけ来ているかを確認できます。
- 自社のどのアプリケーションが狙われているかを把握し、パッチ適用の優先順位を決める
- 誤検知があれば、マネージドルールの適用範囲（スコープ）を調整する
- パッチ適用後も保護を有効にしたまま、攻撃が続いているかを監視する
「オリジンを守りながら、観察し、対応する」。オリジンのパッチ適用だけでは得られない、この時間と情報こそがエッジで守る意味です。
WAF の守備範囲と、その外側
ここで誤解のないようにお伝えします。WAF が守るのは、Cloudflare を経由する HTTP/HTTPS の通信です。 BIND の脆弱性は DNS の層の問題で、WAF では守れません。
だからこそ、「どの層の、どの資産が、何で守られているか」を整理することが大切です。
| 層 | 今回の例 | Cloudflare でできること | 自社で必要な対応 |
|---|---|---|---|
| HTTP（アプリケーション） | php2shell | WAF のマネージドルール、レスポンスルール | PHP ランタイムの更新 |
| オリジンへの経路 | WAF を迂回した直接アクセス | Cloudflare Tunnel でオリジンを外部に公開しない構成にする | オリジンの受信を Cloudflare 経由に限定する |
| DNS（権威サーバー） | BIND 9 | Cloudflare DNS を権威 DNS にする。Enterprise では、既存のプライマリを残したまま Cloudflare をセカンダリにする構成も選べる | 自社で動かし続ける BIND の更新 |
| DNS（社内のキャッシュサーバー） | BIND 9 | Cloudflare Gateway の DNS リゾルバーへの切り替えを検討する | 自社で動かし続ける BIND の更新 |
特に見落とされがちなのが「オリジンへの経路」です。WAF を有効にしていても、オリジンの IP アドレスに直接アクセスできる状態では、攻撃者は WAF を迂回できます。Cloudflare Tunnel を使えば、オリジンからの外向きの接続だけで公開でき、受信のポートを開ける必要がなくなります。
DNS についても考え方は同じです。外部に公開している権威 DNS を Cloudflare に任せれば、自社で BIND を公開し続ける範囲を小さくできます。ただし、自社で BIND を動かし続ける限り、その更新は必要です。
設計ガイドで実際の画面を確認する
先日公開した設計ガイドでは、Cloudflare アプリケーションセキュリティのダッシュボードを、画面ごとに解説しています。
【設計ガイド】Cloudflare アプリケーションセキュリティ：検証環境A
今回の脆弱性対応に関係する箇所は次のとおりです。
| 設計ガイドの節 | 今回の対応との関係 |
|---|---|
| 00 はじめに ＞ リクエストの流れ | カスタムルール → レート制限 → 管理ルールの順に評価される。誤検知の調査では、どのフェーズで止まったかを先に確認する |
| 03 セキュリティルール ＞ 管理ルール | Cloudflare 管理ルールセットの状態の確認。php2shell のルールはこのルールセットに追加される |
| 03 セキュリティルール ＞ カスタムルール | 同じ条件で「ログ」と「ブロック」を対にして、影響を確認しながら段階的に強化する運用例 |
| 03 セキュリティルール ＞ IP アクセスルール | IP アドレスを許可すると、管理ルールもバイパスされる。緊急時ほど、安易な許可リストに注意する |
| 02 Web アセット ＞ 操作 | 使われていない API（zombie）や機密データを返す API（sensitive）の棚卸し。守るべき資産を把握する起点になる |
なお、設計ガイドの画面は 2026 年 10 月 19 日に取得したもので、php2shell のルールやレスポンスルールはまだ写っていません。レスポンスルールは、セキュリティ ＞ セキュリティ ルール 画面の下部に表示されます。
構造の更新を計画する
WAF で確保した時間は、構造の更新に使います。次のような段階で進めることをおすすめします。
| 時期 | やること |
|---|---|
| 今日 | 管理ルールセットがブロックのモードでデプロイされているかを確認する。レスポンスルール（Cloudflare Managed Response Firewall Default）が有効かを確認する。オリジンに直接アクセスできないかを確認する |
| 今週 | PHP と BIND を更新する。Security Analytics で攻撃の状況を確認し、狙われているアプリケーションから優先して対応する |
| 今月 | サポートが終了したバージョンを洗い出す。Web アセットで API を棚卸しし、使われていないものを廃止する |
| 中長期 | 自社で更新し続けなければならないランタイムやサーバーそのものを減らす構成を検討する |
最後の「中長期」が、今回の本題です。脆弱性は今後も公開され続けます。毎回パッチを当て続ける構造のままでよいのかを、この機会に見直す価値があります。
PHP に依存しない CMS という選択肢：EmDash
その選択肢の一つが、Cloudflare が 2026 年 4 月にベータとして公開した EmDash です。Cloudflare は EmDash を「WordPress の精神的な後継」と位置づけています。
| 特徴 | 内容 |
|---|---|
| PHP を使わない | すべて TypeScript で書かれ、Web フレームワークの Astro の上で動作する |
| サーバーレス | Cloudflare Workers で動作し、リクエストがなければゼロまでスケールする。Node.js のサーバーでも動かせる |
| プラグインの隔離 | プラグインは Dynamic Workers の独立したサンドボックスで動作し、マニフェストで宣言した権限（コンテンツの読み取り、メール送信など）しか使えない |
| 認証 | 既定でパスキーを使う。漏えいするパスワードがなく、総当たり攻撃の対象にならない |
| 移行 | WordPress の WXR ファイル、または専用のエクスポーターのプラグインからコンテンツを取り込める |
| ライセンス | MIT ライセンスのオープンソース |
Cloudflare のブログでは、WordPress のセキュリティ問題の 96% がプラグインに由来するという調査が紹介されています。WordPress のプラグインはサイトのデータベースやファイルシステムに直接アクセスできるため、1 つのプラグインの不備がサイト全体に及びます。EmDash は、この構造そのものを変えようとしています。
php2shell のような PHP ランタイムの脆弱性は、PHP で動くアプリケーションを選んだ時点で抱えるリスクです。EmDash を Workers で動かす場合は、PHP ランタイムを自社で更新し続ける運用から離れられます。
一方で、EmDash は v0.1.0 のプレビュー版です。既存の本番サイトをすぐに置き換えるのではなく、新しく立ち上げるサイトや、影響の小さいサイトから評価を始めるのが現実的です。また、どの CMS を選んでも、WAF によるエッジの防御が不要になるわけではありません。多層防御の考え方は変わりません。
まとめ
- php2shell に対しては、Cloudflare WAF が公開前から保護を展開しています。有償プランでは、管理ルールセットのデプロイ状況を必ず確認してください。
- 新しい full transaction detection により、リクエストだけでは判定できない攻撃も、レスポンスの段階で止められるようになりました。
- それでも、パッチの適用は必要です。WAF で「いま」を守り、観察しながら、確実に更新を進めてください。
- WAF は HTTP の層を守ります。BIND のような DNS の脆弱性や、WAF を迂回するオリジンへの経路は、別の手段で守る必要があります。
- 中長期では、更新し続けなければならないものを減らす構成を計画しましょう。EmDash は、その有力な選択肢の一つです。
実際の画面での確認方法は、設計ガイド をあわせてご覧ください。
参考資料
- Cloudflare deploys protections against php2shell vulnerability（Cloudflare Blog）
- Introducing full transaction detection for Cloudflare WAF（Cloudflare Blog）
- PHP のセキュリティアドバイザリ（php.net）
- （緊急）BIND 9.x の脆弱性について（CVE-2026-94300）（JPRS）
- CVE-2026-94300（ISC）
- Managed rules（Cloudflare Docs）
- WAF changelog（Cloudflare Docs）
- Cloudflare as Secondary（Cloudflare Docs）
- Cloudflare Tunnel（Cloudflare Docs）
- DNS policies（Cloudflare Docs）
- Introducing EmDash（Cloudflare Blog 日本語版）
- EmDash（GitHub）