WEBサイトPHPの脆弱性にWAFの保護が入っても、PHPの更新は要る。Cloudflareは「追加の層」と書いた ── CDNを通らない経路・ルールの対象外・WAFを切ったときを確かめる13項目（2026年10月時点）
PHPの脆弱性にWAFの保護が入っても、PHPの更新は要る。Cloudflareは「追加の層」と書いた ── CDNを通らない経路・ルールの対象外・WAFを切ったときを確かめる13項目（2026年10月時点）
目次
01 何が書いてあるか — CloudflareはPHPの脆弱性向けのWAFの保護を全プランに入れた。同時に「PHPの更新は別に要る」と書いた
引用について
この記事の「" "」で囲んだ英語の文は、公式の文書やブログからの引用で、日本語訳は記事の筆者が付けたものである。原文は各出典のページで確かめられる。各ページは2026年10月23日に開いて確かめた。
Cloudflareが2026年10月21日に公開した記事
Cloudflareのブログ「Cloudflare deploys protections against php2shell vulnerability」（訳: Cloudflareはphp2shellの脆弱性に対する保護を展開した）は、2026年10月21日付である。記事によれば、PHPの2つの脆弱性（CVE-2026-109618とCVE-2026-109619。まとめて「php2shell」と呼ばれる）について、CloudflareのWAFで使えるルールを、世界への公表より前から展開していた。
記事が書く要点は、次の4つである。
- いつから — 2026年10月21日の午前3時2分（UTC）から、無料または有料のWAFを使う顧客は、既定で保護された。
- どのプランに — Freeプランを含む全プランに入った。Freeプランの顧客は、有効にする操作をしなくてよい、と記事は書く。
- 有料プランは — Professional・Business・Enterpriseの顧客は、マネージドルールの展開が「ブロックのモード」になっているかを自分で確かめるよう、記事は求める。
- 新しい検知の仕組み — リクエストだけでなく、オリジンの応答も同じ通信の中で見る「full transaction detection」を使った、と書く。
同じ記事が、更新について書いたこと
同じ記事は、保護を入れたと書いたうえで、PHP自体の更新が要ることも書く。
"Customers should patch their PHP repos even with WAF protections providing an additional layer of defense-in-depth mitigation."
（訳: WAFの保護が、多層防御としての追加の層になっていても、顧客はPHPを更新すべきである。）
さらに、この欠陥はPHPの実行環境の中にあるので、サイトのコードやプラグインだけを更新しても直らない、とも書く。保護が入ったことと、更新が要らなくなったことは、別の話である。
PHPの開発元が書いたこと
PHPの開発元の発表（php.netの2026年のお知らせ）は、2026年10月21日付の各版のリリースで、次のように書く。
"There are no complete mitigations, updating is the only safe choice."
（訳: 完全な緩和策は無く、更新だけが安全な選択である。）
WAFは、この文でいう「緩和策」の一種として読める。WAFがあっても、更新が要る、という点で、Cloudflareの記事とPHPの開発元の文は一致している。
この記事が扱う範囲
PHPの版の表、更新できないときの暫定策、更新の後に確かめることは、AI RonのブログのPHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録にまとめてある。この記事は繰り返さない。ここでは、「WAFがあるから」と更新を後回しにする前に、自社のWAFが実際にどこまで守っているかを、3つの点で確かめる手順に絞る。3つとは、CDNを通らない経路、ルールの対象外の形、WAFを切ったときである。
02 なぜ・背景 — WAFは入口で通信を見る仕組みで、PHPの欠陥は実行環境の中にある
入口で止めることと、中を直すことは別
WAF（Webアプリケーションファイアウォール）は、サイトの手前に置き、届いた通信を規則に照らして、通すか止めるかを決める仕組みである。一方、今回の欠陥は、PHPがメモリの扱いに失敗したあとの後始末にある。Cloudflareの記事は、2つの脆弱性を次のように説明する。
- CVE-2026-109618は、PHPがメモリ不足で処理を中断したとき、まだ初期化されていない内部のデータを、後始末の段階で有効なものとして使ってしまう。
- CVE-2026-109619は、致命的なエラーで処理が中断され、解放済みのメモリへの参照が残る。同じプロセスが後の通信を処理するとき、その古い参照をたどることがある。
欠陥は、PHPの内部の状態の扱いにある。WAFは入口で、そこへ至る通信の形を見て止めようとする。入口の規則は、欠陥そのものを直さない。直るのは、PHPを更新したときだけである。
リクエストだけでは、見分けにくい
Cloudflareは、今回の保護に新しい検知を使った理由を、次のように書く。
"Request data alone does not always provide enough evidence to distinguish an exploit from legitimate traffic."
（訳: リクエストのデータだけでは、攻撃と正当な通信を見分けるのに十分な根拠が、いつも得られるとは限らない。）
つまり、リクエストの形だけで止める規則は、正当な通信まで止めてしまうか、攻撃を通してしまうか、どちらかに寄りやすい。Cloudflareは、応答も合わせて見る方法を足した。ただし、この方法を使えるのはCloudflareのような一部の製品であり、自社のWAFに同じ機能があるとは限らない。
攻撃の側も、形を変える
同じ記事は、公表の前に情報が漏れていたことと、攻撃の側が形を変えて保護をすり抜けようとしたことも書く。
"We observed how attackers were mutating the attack payload to try to bypass our protections by tracking the volume of matches and cross-referencing with the rule logic."
（訳: 私たちは、規則に一致した件数を追い、規則の論理と突き合わせることで、攻撃者が保護をすり抜けようと、攻撃の中身を変えていく様子を観察した。）
この文は、ルールが一度入れば終わり、ではないことを示す。ルールは更新され続ける前提で運用されており、更新が追いつくまでの間に通る形があるかもしれない。これは筆者の読みである。公式の文は、攻撃の形が変えられたことを書くだけで、更新が追いつくまでの間に通った形があったかは、書いていない。通るか通らないかは、この記事では確かめていない。
「WAFがあれば安全」とも「WAFでは防げない」とも書かない
この記事は、どちらの言い方もしない。公式の文書が書いているのは、保護は追加の層として意味があり、更新の代わりにはならない、という範囲までである。どこまで防げたかは、各社のWAFの設定と、実際の通信しだいで、記事からは判断できない。
03 この記事に出てくる用語
WAF（Webアプリケーションファイアウォール）
Webサイトへの通信を、規則に照らして検査し、通すか止めるかを決める仕組みをいう。CDNの事業者が提供するもの、クラウドの事業者が提供するもの、サーバーの中に入れるものがある。
CDN
サイトの手前に置かれ、利用者の近くから画像などを配る仕組みをいう。WAFの機能をあわせて持つ製品が多い。利用者の通信が、CDNを通ってからサーバーに届く形にしているサイトが多い。
オリジン
CDNの後ろにある、本来のサーバーをいう。PHPが動いているのは、このオリジンである。CDNを通さずに、オリジンへ直接つながる経路があると、入口のWAFを通らずに通信が届く。
マネージドルール
WAFの事業者が作り、更新を続ける規則のまとまりをいう。Cloudflareの記事では、Freeプランは「Cloudflare Managed Free Ruleset」、有料プランは「Cloudflare Managed Ruleset」に今回のルールが入ったと書かれている。
ブロックのモード
規則に一致した通信を、止める設定をいう。これに対して、記録だけ残して通す設定もある。有料プランの顧客に、Cloudflareは「ブロックのモード」になっているかの確認を求めている。
full transaction detection
Cloudflareが今回の保護で最初に使ったと書く検知の仕組みで、同じ通信の中のリクエストと応答の両方を見る。一致した応答は、リクエスターに届く前に止められる、と記事は書く。この記事では「リクエストと応答を合わせて見る検知」と呼ぶ。
php2shell
CVE-2026-109618とCVE-2026-109619をまとめた通称である。公式の文書は、番号で呼んでいる。この記事も、番号を併せて書く。
04 型別 — 3つの点で、自社のWAFが守っている範囲を確かめる
🅰 CDNを通らない経路があるか
Vercelの注意書き（2026年10月21日付）は、自社のWAFの保護が及ばない場合を、次のように書く。
"Requests that bypass Vercel's network, including direct requests to an external PHP backend, are not covered."
（訳: Vercelのネットワークを迂回するリクエストは、外部のPHPのバックエンドへの直接のリクエストを含めて、対象に入らない。）
これはVercelの話だが、考え方はCDNやWAF一般に当てはまる。入口にあるWAFは、入口を通った通信しか見ない。確かめることは3つある。
- ホスト名の一覧 — サイトのドメインの下に、管理画面用・テスト用・古い名前など、CDNを通らないホスト名が残っていないか。DNSの記録を全部書き出して、1つずつ印を付ける。
- オリジンへの直接の接続 — CDN以外のところからも、オリジンが通信を受け付けるか。サーバーの管理者に聞くか、自分の管理するパソコンから、ホスト名を指定してトップページを1回開き、HTTPのステータスの数字だけを控える。
- PHPが動く場所 — Webの画面以外（バッチ処理や別のサービス）で、PHPが動いていないか。WAFは画面への通信だけを見る。
🅱 ルールの対象外の形があるか
ルールは、すべての通信を止めるものではない。対象外を生むものを、筆者は次の3つに整理した。1つ目はCloudflareの記事に書かれたことで、2つ目と3つ目は、公式の文ではなく、筆者の整理である。
- 適用範囲の絞り込み — Cloudflareの記事は、顧客がマネージドルールの適用範囲を、アプリケーションの必要な部分に絞れると書く。絞った結果、外れたパスがあるかもしれない。
- 記録だけのモード（筆者の整理） — ルールが入っていても、止めずに記録だけの設定になっていれば、通信は通る。
- 例外の設定（筆者の整理） — 誤検知が出たときに足した例外が、そのまま残っていることがある。
各社の規則は、閾値のような単純な形を使うものもある。AWSの案内は、リクエストの本体が8KB（8,192バイト）を超えるものを対象にするルールを、CVE-2026-109618の追加の備えとして挙げる。大きなファイルを受け付ける正当なページがあるサイトでは、このような上限が、正当な通信も止めうる。止めない側に緩めた設定が、攻撃の通り道になるかもしれない。どちらに倒れているかは、自社の設定を開いて確かめるしかない。
🅲 WAFを切ったとき
Cloudflareの記事は、更新の作業中の注意として、次のように書く。
"Keep Cloudflare WAF protections enabled while patching."
（訳: 更新の作業をしている間は、CloudflareのWAFの保護を有効にしておくこと。）
WAFを切る場面は、思ったより多い。誤検知で正当な通信が止まったとき、障害の切り分けで一時的に迂回するとき、CDNの契約やプランを変えるとき、DNSの向け先を変えるときである。更新が終わるまでは切らない、切るなら期間と戻す日を記録する、という決まりを、先に書いておく。
3つの点の整理
| 確かめる点 | 見る場所 | 数えるもの | これだけでは分からないこと |
|---|---|---|---|
| CDNを通らない経路 | DNSの記録、サーバーの管理者への質問 | CDNを通らないホスト名の数 | その名前に実際に攻撃が来たか |
| ルールの対象外 | WAFの管理画面の適用範囲、例外、モード | 除外のパス・例外・記録だけのルールの数 | 変形された攻撃の通信が通るか |
| WAFを切ったとき | 変更の履歴、作業の手順書 | 直近30日の無効化・変更の件数 | 切っていた間に何が届いたか |
注意
オリジンへ直接つなぐ確認は、自社が管理するサーバーにだけ行う。他人のサーバーに、同じことをしない。また、確かめるのは接続の可否とステータスの数字までにして、攻撃の形を試さない。
05 明日、自社のサイトで確認できることチェックリスト
以下は、WAFが入っていても更新が要る前提で、自社のWAFが実際にどこまで守っているかを確かめる13項目である。1〜5番目はCDNを通らない経路、6〜9番目はルールの対象外、10〜11番目はWAFを切ったとき、12〜13番目は更新の状況と記録である。1項目は5分以内でできる。チェックの状態はブラウザに保存され、サーバーには送られない。
- 自社のドメインのDNSの記録を開き、サブドメインと別のホスト名（管理画面用・テスト用・古い名前を含む）を全部書き出して、件数を数える
- 書き出したホスト名のうち、CDNやWAFを通る名前と通らない名前に印を付け、通らない名前の数を数える
- CDNを通らない名前のそれぞれについて、PHPが動いているかをサーバーの管理者に聞き、「はい」「いいえ」「分からない」を一覧に書く
- オリジンが、CDN以外の接続元からの通信を受け付けるかを、サーバーの管理者に聞いて、答えを一覧に書く
- 自社が管理するパソコン1台から、オリジンを指定してトップページを1回だけ開き、HTTPのステータスの数字だけを控える
- WAFの管理画面で、PHPの脆弱性向けのルールが入っているプランと範囲を開き、ルールごとにブロックか記録だけかを書き写す
- ルールの適用範囲に、除外のパスや条件が付いていないかを上から全部読んで、件数を数える
- 直近30日の変更の履歴を開き、PHPの保護に関係する例外・無効化の件数を数える
- 正当なアップロードがあるページを3つ書き出し、リクエストの大きさの上限に当たらないかを、担当者に聞いて確認する
- WAFを切る・迂回する作業の手順書を開き、「PHPの更新が終わるまでは切らない」の1行があるかを確認する
- WAFのブロックの記録を直近7日分開き、PHPの脆弱性向けのルールで止まった件数を数える
- AI Ronのブログの記事の表で、自社のPHPの版を確かめ、更新の予定日と更新済みのサーバーの台数を1行で書く
- 確認した日と、3つの点の数字、次に見直す日を、記録に書く
1〜5番目の確認の前に、サイトの外から見える状況を先に知りたいときは、当サイトの無料ツールの1つ、🔧 外からできるセキュリティ対策監査ツールが使える。ツールのページによれば、URLを与えると、外から取れる情報でセキュリティ対策の状況を点検する。会員限定のツールで、強力で繊細なので自分の管理するサイトにだけ使う、とページに書かれている。WAFのルールの中身を判定するとは、ページに書かれていない。
11番目の確認と合わせて、WAFを抜けて届いた通信の兆候を見たいときは、🔧 IPAの攻撃兆候検出ツールで、ログを簡単に分析するツールが使える。ページによれば、アクセスログを与えると、攻撃の兆候を点検する。会員限定である。PHPのエラーログを読むツールではない。
06 代替・他の選択肢 — 各社が書いた、更新の前にできることと限界
次の表は、公式の文書に書かれた範囲で、並べたものである。各社のページは、2026年10月23日に開いて確かめた。
| 備え | 文書が書くこと | 文書が書く限界 |
|---|---|---|
| Cloudflareの既定の保護 | 全プランに7つのルールと既定のブロックのルールが入った（10月21日）。有料プランは、ブロックのモードを確認する | PHPの更新は要る。サイトのコードやプラグインだけの更新では直らない |
| AWS WAFの追加の備え | CVEごとに、既存のルールや、利用者が足すルールを挙げる。PHP向けのマネージドルールの版2.3を既定にした | どの設定も、完全な緩和策ではない。更新だけが完全な対処 |
| Vercelのルール | 既知の攻撃の形をWAFで止める | WAFは更新の代わりにならない。ネットワークを迂回する通信は対象外 |
| PHPの設定による暫定策 | 特定の攻撃の経路への備えを、設定で減らせる | 設定では、インストールは安全にならない。更新が必要 |
| 何もしない（WAFだけに頼る） | WAFが入っていれば、既知の形は止まるかもしれない | Cloudflareも、PHP開発元も、更新を求めている |
他のWAF・CDNの案内を探した結果
Microsoftの案内も検索で見つかったが、この記事では本文を取り直して確かめられなかったので、扱わない。Akamai・Fastlyについては、筆者が検索した範囲（2026年10月23日）では、この件の案内を見つけられなかった。見つからなかったことは、案内が無いことの証明ではない。自社が使うWAFやCDNの事業者の最新の案内を、自分で探してほしい。
設定による暫定策は、更新できないときの話
PHPの開発元は、更新がすぐにできないときのために、設定で攻撃の経路を減らす方法を書く。その書き出しの文は、次のとおりである。
"while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe."
（訳: 完全な解決は更新だけだが、次の措置は、特定の攻撃の経路への露出を減らす。ただし、インストールを安全にはしない。）
具体的な設定項目と、更新の後に確かめることは、PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録の表に載せた。この記事は、それを繰り返さない。
「更新できない」ときの考え方
PHPの版が古すぎて、更新の対象にならないサーバーもある。開発元の発表は、サポートが終わった古い版には、ディストリビューションやLTSの提供元が修正を提供している場合がある、と書く。この場合も、WAFは更新の代わりにならない。提供元に確かめることが先になる。
用語
多層防御（defense-in-depth）とは、1つの防御が破れても次の層が受け止めるように、防御を重ねる考え方をいう。Cloudflareの記事は、WAFをその追加の層として位置づけ、別にPHPの更新も求めている。
07 当サイトで確かめたこと — 確かめていないことの範囲
当サイトは、Cloudflareを使っていない。したがって、この記事のCloudflareの画面の操作は、当サイトでは試していない。Cloudflareの記事を読んだ範囲で書いた。
この記事は、サーバーの設定の中身や、防御の設定の値を書かない。書くのは、公式の文書が公開している範囲と、自分のサイトで同じ手順を試すための確認項目である。当サイトのPHPの更新と、更新の後の確認は、AI RonのブログのPHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録に書いた。
実務のヒント
WAFの管理画面を初めて開く担当者は、最初の15分で、ルールの一覧とモードの2つだけを書き写す。設定を直す前に、今の状態を紙に残しておくと、あとで「何を変えたか」が分かる。変更は、書き写した後に行う。
過去のAI Ronのブログでは、WAFのルールの書き方の記事を書いたあと、当サイトで実施していなかったことが分かり、訂正した経緯がある。Verified AI Agent 37体を個別allowする WAF ルールの書き方 ── 当サイトでは実施していなかった（2026年10月4日 訂正）は、その訂正を載せた記事である。WAFの記事を読んで「自分のサイトにもある」と思い込む前に、自分の画面で確かめる、という教訓は、今回も同じである。
08 このテーマは、ここまで
2026年10月20日 — PHPの事前告知
PHPの開発元が、重大なセキュリティリリースを2026年10月21日の14時（UTC）に予定している、と事前に告知した。
2026年10月21日 — Cloudflareの保護とPHPの更新
Cloudflareが、同日の午前3時2分（UTC）から、全プランのWAFでphp2shellへの既定の保護を有効にしたと書いた。PHPの開発元は、同日に8.5.12・8.4.27・8.3.36・8.2.35を公開した。AWSとVercelも、同日付で案内を出した。
2026年10月22日 — JPCERT/CCの注意喚起
JPCERT/CCが、この件の注意喚起（JPCERT-AT-2026-0033）を公開した。更新を求め、侵害の調査の観点も紹介している。
2026年10月23日 — この記事の確認日
この記事の内容は、2026年10月23日に、Cloudflare・PHPの開発元・AWS・Vercelの各ページを開いて確かめた時点のものである。ルールは更新されるので、出典のページが更新されたときは、この記事に日付つきで追記する。
現在の貴方のIPアドレス
このサイトで書いている人
