PHP2ShellはWAFで防げるか？パッチ適用までにWAFができること・できないこと
PHP2ShellはWAFで防げるのか。パッチ適用までにWAFができること・できないこと、ルールの検証手順、パッチを優先すべき判断基準を解説します。
PHP2ShellはWAFで防げるか？パッチ適用までにWAFができること・できないこと
WAFを導入済みなら、2026年10月21日のPHP修正版公開後に浮かぶのは「PHP2Shell対応は次のメンテナンス時でよいか」という疑問です。結論から言うと、WAFはパッチ適用までのPHP2Shellのリスクを下げられますが、安全性を保証するものではありません。PHPチームも、自らWAFを提供するAWSも、完全な対策はPHPの更新だけだと明言しています。
WAFは配管工が来るまでの水漏れ用テープです。効きますが、貼りっぱなしにはしません。2つの脆弱性の詳細はシリーズのメイン記事をご覧ください。
なぜWAFは「部分的」にしか効かないのか
PHP2ShellはHTTPリクエストとして届くので、WAFの監視位置を通ります。AWSによれば、2つの脆弱性はどちらも、アプリのコードが動く前にPHPがmultipart/form-data（ファイルアップロードの形式）を処理する部分にあります。
ただし、問題はPHP内部の処理にあります。AWSは、自社WAFがmultipartボディの内部構造を解析せず、PHPワーカーのメモリやサーバー設定も見えないと述べ、2つのうち1つはどのWAFでもほぼ届かないとしています。防御製品Shieldを持つSansecも、ルールを待たないよう警告しています。
パッチまでの間にWAFができること
OWASPは、脆弱なコードを変えずに既知の脆弱性への攻撃を遮断する手法を仮想パッチ（virtual patching）と呼びます。効くのは検査層を通る通信とルールが知る攻撃だけで、脆弱性は残るとOWASPは明記しています。以下はAWSのガイド（AWS自身が有効範囲を評価）の例です。
- 正規のmultipart通信がなければ
multipart/form-dataをブロック：アップロードフォームに加え、ファイルなしでmultipartフィールドを送るフォームやAPIクライアントも確認し、なければ、両脆弱性の主な侵入口を遮断できます（PHPチームも推奨）。
- トリガーに似たリクエストをブロック：AWSによると、CVE-2026-109619向けのカスタムルールは
POST、CookieかボディにPHPSESSID、ボディにPHP_SESSION_UPLOAD_PROGRESSの3条件がそろうと遮断します。
- ボディサイズの上限：CVE-2026-109618には8 KBを推奨しつつ評価は「部分的」。上限内の小さなパートヘッダーを大量に送る手口は防げません。
- レート制限：試行は減らせますが、1回の成功は止められません。
- ログ：何が届いたかの証拠になり、ログでのPHP2Shell痕跡調査に使えます。
WAFに見えないもの
- シグネチャは既知のパターン頼み：Amazonは10月17日にハニーポットで攻撃試行を観測し、AWSのWAFガイドは10月21日に出ました。
- WAFを通らない通信：TenableはCloudflareのルールをCloudflare経由の通信だけに効く暫定策としています。直接届くオリジンやWAF外の社内システムは守られません。
- サーバー側の状態と設定：AWSの表は、PHP 8.5の
fatal_error_backtraces設定と不正・非推奨のINI設定による診断を対象外としています。どちらもリクエスト処理に関わりますが、WAFの検査からは見えません。
- 検査上限と回避：AWS WAFが検査するのはボディの先頭だけで、ALBとAppSyncは8 KB固定、その他の連携先は初期値16 KBで変更可能です。上限は製品ごとに異なります。OWASPは照合や変換の見逃し、ブロックリスト型の回避されやすさを警告しています。HTTPリクエストスマグリング（PortSwigger）は前段一般の限界で、確認した情報源にPHP2Shellでの使用報告はありません。
前段に何もないなら、一般的なWeb攻撃対策とレート制限を備えたWAFは公開サイトやAPIの補助的な防御層として有効ですが、パッチの代わりにはなりません。
ルールが効くかの確認（本番は攻撃しない）
AWSとOWASPの資料に基づく手順です（ステージングは当社の推奨）。
- 変更前にWAFのログを有効にする
- ルールはまずカウント（ログのみ）モードで動かす。この間、一致した通信もオリジンに届く
- パッチ済みPHPの隔離ステージングを同じWAF配下に置き、本番データは使わない。AWSが勧める検証（通常のmultipart POST、上限超えのボディ、
PHPSESSID CookieとPHP_SESSION_UPLOAD_PROGRESSを含むPOST）を合成リクエストで限られた数だけ送る
- ルールごとに期待結果を決める。multipart全面ブロックはアップロードに、8 KB上限はそれ以上のJSONに設計上一致する。正規の通信と衝突したら記録し、そのシステムのパッチを優先する
- ブロック前にロールバック基準を決め、切り替え後はHTTP 403とルールのログを確認する
- 公開PoCは実行しない。1種類のテストリクエストを遮断できても完全な防御の証明にはならない（OWASP）
ボディやCookieの丸ごと記録は避けてください（パスワードやカード情報が残り得るとOWASPとCRSが警告）。記録はルールID、時刻、エンドポイント、結果、相関IDで足ります。
判断表：パッチが先か、WAFでしのぐか
| 状況 | 対応 | WAFの役割 |
|---|
| 公開＋未パッチ（最高リスクはApache mod_php） | 直ちにパッチ（Amazonは時間単位を推奨）。全PHPワーカーを再起動 | 期限付きの暫定策 |
| 正規のmultipart通信なし（アップロード、フォーム、APIを確認済み） | 緊急パッチを手配する間の暫定策としてmultipart/form-dataを前段でブロック | 最も効果的 |
| 正規のmultipart通信あり | パッチ優先。その間はsession.upload_progress.enabled=0をphp.ini、FPMプール、サーバー設定で指定（ini_set()や.user.iniは不可）し、全ワーカーを再起動 | リスクは減るが塞がらない（AWS） |
| すぐパッチできない | 暫定設定＋WAFルール＋見直し日付きの変更チケット。難しければ英NCSCは停止の検討を推奨 | 時間稼ぎのみ |
| PHP 7.4、8.0、8.1 | 公式修正リリースはなく、PHPセキュリティチームが最小限のソースバックポートを公開。他はベンダーのバックポートか移行 | 判断は変わらない |
| WAF外の社内システム | 公開システムの次にパッチ | 通信が見えない |
| パッチ済み | バージョン確認とワーカー再起動 | 補助策として残すか外す（AWS） |
1行目のサーバーが分からなければ、PHP2Shellの影響を受けるPHPバージョンの確認方法から始めてください。
「期限」はルール削除ではありません。OWASPは仮想パッチを通常のパッチ管理で記録し、定期的に見直すよう勧めています。ルールをパッチ延期の口実にしないでください。WAFを新たに検討中ならzcrWAFの導入形態と料金をご覧ください。それでも1行目は変わりません。
無料ツールでできること
PHPチーム自身が、デコード後のリクエストサイズ、フィールド数、パート数、ヘッダー数、ネストの深さをWebサーバーかプロキシで制限するよう勧めています。ボディサイズの上限は既存のWebサーバーで無料で設定でき、他の項目への対応はサーバーソフトウェア次第です。OWASP CRSは無料のオープンソースのルールセットで、パラノイアレベル1は誤検知がほぼ出ない設計の妥当な基本線です。ただし検知は汎用的で、新しい脆弱性まで捕まえるとは限りません。
zcrWAFの位置づけ
zcrWAFは、Webサイト、API、オリジンサーバーへの通信をOWASP Top 10や一般的な攻撃パターンについて検査するWebアプリケーションファイアウォールです。レート制限、CAPTCHAや認証チャレンジ、Allow・Block・Challengeのカスタムルール、監査証跡付きのリアルタイムセキュリティログ、メール・Teams・LINE・Webhook通知を備え、クラウド／SaaS、仮想・ICTハードウェアアプライアンスで導入できます。画面はデモページへ。
zcrWAFの製品情報にPHP2Shellへの対応は記載されていません。侵害が疑われる場合はPHP2Shellのインシデント対応へ。
お問い合わせ
どのPHPサーバーから優先してパッチを当てるべきか、今のWAFでどこまでカバーできるのか、気になりませんか。お気軽にご相談ください。無料でご相談いただけます。
参考資料
