WEBサイトCloudflareはWAFを突破できるか試す公開の催しを始め、同じ記事に「更新の代わりにならない」と書いた ── 事業者が自分で試す理由から、自社のWAFの守りが届かない所を確かめる13項目（2026年10月時点）
CloudflareはWAFを突破できるか試す公開の催しを始め、同じ記事に「更新の代わりにならない」と書いた ── 事業者が自分で試す理由から、自社のWAFの守りが届かない所を確かめる13項目（2026年10月時点）
目次
01 何が書いてあるか — CloudflareはWAFを突破できるか試す公開の催しを始め、同じ記事に「更新の代わりにならない」と書いた
引用について
この記事の「" "」で囲んだ英語の文は、Cloudflareのブログ、AWSとVercelの公式の告知からの引用で、日本語訳は記事の筆者が付けたものである。各ページは2026年10月29日に開き、本文を取り直して、1文字ずつ照らして確かめた。出典に書かれていない筆者の読みは、「筆者の読み」と書いて分ける。催しへの参加の方法と、突破の手がかりは、この記事には書かない。
2026年10月27日に、Cloudflareが公式ブログで、「Introducing the Cloudflare PHP Capture the Flag challenge」（訳: CloudflareのPHP旗取り（Capture the Flag）の催しの紹介）を公開した。書いたのはCelso Martinho、Sven Sauleau、Dan Jonesの3人で、読む時間は5分と表示されている。内容は、PHPの重大な脆弱性「php2shell」に対するCloudflareのWAF（ウェブアプリケーションファイアウォール）の守りを、外の研究者に破らせて試す、という催しの案内である。
この記事は、催しの案内ではない。事業者が自分のWAFを、外の人に公開で試させる理由と、そこから担当サイトの持ち主が読み取れることに絞る。WAFを使っているサイトの担当者が、自社の守りの「届く所」と「届かない所」を確かめる手順までを書く。
何をする催しか（原文の範囲）
原文は、催しの中身を次のように書く。
"We've put a deliberately vulnerable PHP installation behind our WAF, and we're inviting security researchers on HackerOne to try to bypass the protections and capture a flag."
（訳: 私たちは、わざと脆弱にしたPHPの環境をWAFの後ろに置いた。そして、HackerOneのセキュリティ研究者に、守りを破って旗を取ってみてほしいと呼びかけている。）
「旗（flag）」は、環境の中に置かれたファイルの中身のことである。守りを破って環境の中でコードを動かし、その旗を読み出せたかどうかで、成功を判定する形である。催しは、Cloudflareの報奨金制度（Bug Bounty）の一部として、期間を限って行われる。報奨金の条件や、重複の扱いは、HackerOneの規約とCloudflareのプログラムの規則が優先する、と原文は書く。
狙われる脆弱性は、php2shellの2つ
催しが対象にするのは、CVE-2026-109618とCVE-2026-109619の2つである。どちらも、2026年10月21日にPHPの開発元が公表した、認証なしでコードを動かされうる重大な脆弱性で、修正版は8.5.12、8.4.27、8.3.36、8.2.35である。Cloudflareは、2つの違いを、前者はPHPがメモリ不足で処理を中断し、内部のデータが初期化される前の状態で後始末に入る問題、後者は致命的なエラーで中断した要求のメモリへの参照が残り、あとの要求で使われてしまう問題、と書く。仕組みの詳しい解説は、当サイトの記事に任せる。
標的の構成と、環境の扱い
標的の構成は、原文に次のように書かれている。
- PHPは、標準の拡張を入れた素の8.5.11。
- Webサーバーは、Apache 2（mod_php経由）。
- 中身が空の入口のPHPファイルを、Cloudflareのコンテナの中で動かす。
- その前に、2つの脆弱性向けの、既定のWAFの保護ルールを有効にして置く。
- 環境は、旗のファイルも含めて、数分ごとに初期化される。
筆者の読みでは、PHP 8.5.11は、AWSのセキュリティ速報が「影響を受ける版は8.5.0〜8.5.11、最初の修正版は8.5.12」と書く範囲に入る。つまり、修正前のPHPを意図的に置いて、WAFだけの守りで、どこまで止まるかを試す形である。原文は「わざと脆弱にした（deliberately vulnerable）」と書く。8.5.11が修正前であることは、AWSの速報で確かめられる。
同じ記事が、最後に書いたこと
催しの紹介の後ろに、原文は「Not a substitute for patching」（訳: 更新の代わりにならない）という見出しを置き、次のように書く。
"Our WAF protects you, but it is not a replacement for fixing vulnerable software. Response blocking can prevent exposed data from reaching an attacker, but it cannot undo actions already performed at the origin. If you run PHP, follow the latest PHP security advisories and apply the relevant updates."
（訳: 私たちのWAFはあなたを守るが、脆弱なソフトウェアを直すことの代わりにはならない。応答のブロックは、露出したデータが攻撃者に届くのを防げるが、配信元ですでに行われたことを取り消すことはできない。PHPを動かしているなら、最新のPHPのセキュリティ勧告を追い、該当する更新を適用してほしい。）
事業者が、自分のWAFを公開で試す記事の中で、WAFは更新の代わりにならないと書いている。この記事の軸は、この2つの並びにある。守りを強くする取り組みと、守りに頼りきらない呼びかけが、同じページに載っている。
02 なぜ・背景 — 事業者が公開で試す理由は、原文に3つ読み取れる
原文が、公開で試す理由として書いたことを、順に並べる。筆者の読みと、原文の言葉は、分けて書く。
理由1: 守りは、続けるものだから
"Protecting systems from vulnerabilities like these is always an ongoing process, not a one-time event."
（訳: このような脆弱性からシステムを守ることは、いつでも続けていく過程であり、1回で終わる出来事ではない。）
1回ルールを入れたら終わり、ではないという立場である。守りのルールは、出したあとも直され続ける前提で書かれている。10月21日の記事でも、Cloudflareは、新しい手口が今後の数時間から数日のうちに出てきたら、ルールを更新する、と書く。
理由2: AIの普及で、新しい攻撃の経路が速く見つかるから
"The widespread adoption of AI allows attackers to discover new vectors with unprecedented speed and efficiency, so collecting real-world data to test our assumptions and strengthen defenses is essential."
（訳: AIが広く使われるようになり、攻撃者は、これまでにない速さと効率で新しい経路を見つけられるようになった。だから、私たちの想定を試し、守りを強めるために、現実のデータを集めることが欠かせない。）
この1文に、理由の2つ目と3つ目が入っている。2つ目は、攻撃の経路が見つかる速さが上がった、という認識である。
理由3: 現実のデータで、想定を確かめたいから
3つ目は、同じ文の後半である。原文は、現実のデータで想定を試すことが欠かせないと書く。なお原文は別の段落で、試行のメタデータと要求の中身を記録して、報告の分析に使うと書いている。
実務のヒント
「事業者が自分で試している」ことと、「自社のサイトで破られない」ことは、別の話である。事業者が試しているのは、事業者が用意した標的で、自社のサイトの設定や、古いプラグインや、版の違いは、そこに入っていない。
10月21日の記事が書いた、攻撃の変化
催しの6日前、10月21日の別の記事で、Cloudflareは、守りを出した後の状況を書いている。
"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."
（訳: 私たちは、攻撃者が、守りを破ろうとして、攻撃の中身を変えていく様子を、ルールに当たった件数を追い、ルールの論理と照らし合わせて、観察した。）
同じ記事は、保護を、公表の約9時間前に出した、とも書く。日本時間で10月21日12時2分から、無料プランも有料プランも、既定で守られた、と書いている。それでも、攻撃の中身は変えられていた、というのが原文の観察である。ルールが出たあとも、攻撃の側は形を変えてくる。公開の催しは、その変化を、先回りして集める場でもある、と筆者は読む。
催しの条件から読めること（筆者の読み）
催しの条件に、次の趣旨の規則がある。報酬の対象は、同じPHPの脆弱性でも、WAFを破る方法が実質的に違うものに限る。同じ破り方の報告は、中身が違っても、重複として扱う。
これは、報告の重複を避けるための報奨金の決まりで、ルールの作りを示すものではない。なお、10月21日の記事の表には、1つの番号に対して、無料プランで7つ、有料プランでも7つのルールが出ている。
| 日付 | 何が書かれたか | 出どころ |
|---|---|---|
| 2026年10月21日 | PHPの重大な脆弱性2件が公表され、修正版が出た。Cloudflareは、WAFの保護を全プランに既定で入れた | PHP開発元、Cloudflareのブログ |
| 2026年10月22日 | JPCERT/CCが注意喚起（JPCERT-AT-2026-0033）を公開した | JPCERT/CC |
| 2026年10月23日 | PHP開発元が、関連する3つ目の問題（CVE-2026-115560）の情報を出した。Cloudflareは、設定を変えた場合は守りの対象外と追記した | Cloudflareのブログ（追記） |
| 2026年10月27日 | Cloudflareが、WAFを破れるか試す公開の催しを案内した | Cloudflareのブログ |
利用者が、ここから読み取れること
理由と条件から、WAFを使っている側の担当者が受け取れることを、3つに整理する。整理は筆者のもので、出典に書かれたものではない。
- ルールは、直され続ける。だから、WAFの提供元の更新履歴を、決まった日に見る習慣が要る。
- ルールの中身は、提供元の側にある。自社で書き換えなくても守られる代わりに、守られているかを、自分の目で確かめる手段が要る。
- PHPの更新は、別の手で行う。WAFの更新と、PHPの更新は、担当者も、期日も、別である。
03 用語 — 出てくる言葉を、先にそろえる
WAF（ウェブアプリケーションファイアウォール）
用語
サイトの手前に置き、サイトに届く通信を見て、攻撃の形に当てはまるものを止める仕組み。ルールの集まりで動き、ルールは提供元が出す場合と、自分で書く場合がある。
突破（バイパス）
WAFのルールをすり抜けて、止められるはずの通信を通すことを指す。原文は「bypass」と書く。ルールの書き方の穴を突く場合も、通信の形を変える場合もある。
旗取り（Capture the Flag・CTF）
用語
環境の中に隠した「旗」（ファイルなど）を、守りを破って取る競技の形式。セキュリティの学習や、守りの試験によく使われる。今回は、事業者が自社の守りを試すために開いた。
配信元（オリジン）
CDNやWAFの後ろにある、元のサーバーのこと。原文の「origin」は、この意味で使われている。WAFは配信元の手前に立つので、配信元の中で起きたことは、WAFの外の話になる。
応答のブロック（full transaction detection）
要求だけでなく、配信元が返した応答も合わせて見て、攻撃が成功した兆候があれば、応答が相手に届く前に止める仕組み。原文は、10月21日に、無料プランを含む全プランに入れたと書く。当サイトの記事「CloudflareのWAFは、リクエストと応答を対にして見る検知と応答のルールを全プランに入れた ── 自社の画面とルールを確かめる13項目（2026年10月時点）」で、画面の確かめ方を書いた。
パッチ（修正版への更新）
用語
欠陥そのものを直した版に入れ替えること。原文の「patching」はこの意味で使われている。WAFは通信を止める備えで、パッチは欠陥を直す作業であり、役割が違う。
緩和策（ミティゲーション）
完全な修正ができないときに、被害を減らすためにとる、一時的な備えのこと。WAFのルールも、PHPの設定による備えも、緩和策に入る。緩和策は、修正の代わりではなく、修正までの時間を稼ぐものである。
04 型別 — WAFの守りが届く所と、届かない所
催しの記事と、同じ週に出た各社の告知から、WAFの守りが届く範囲と、届かない範囲を、公式の文書に書かれた範囲で並べる。
🅰 守りが届く所（原文が書いた範囲）
Cloudflareの10月21日の記事は、次のことを書く。
- 保護は、WAFを有効にした全プランに、既定で入る。
- 無料プランは、無料向けの管理ルールの中に、7つのルールが入る。
- 有料プランは、管理ルールの中に7つのルールが入る。ただし、有料プランは、ルールの一式がブロックのモードで動いているかを、自分で確かめるように、と書かれている。
- 要求だけで判断しにくいものは、応答も合わせて見て、応答を相手に届く前に止める。
🅱 守りが届かない所（各社が書いた範囲）
届かない所は、4つ読み取れる。いずれも、出典に書かれた文を元にしている。
すでに配信元で行われたこと
催しの記事の、前に引いた1文のとおりである。応答のブロックは、情報が攻撃者に届くのを防げる。しかし、配信元の中で、すでに動いたことは取り消せない。
設定を変えている場合
10月23日に、Cloudflareは、関連する3つ目の問題について、次のように追記している。
"Customers who have changed session.upload_progress.name are not covered by the WAF rule."
（訳:
session.upload_progress.nameを変更している利用者は、そのWAFのルールの対象外である。）
この設定は、PHPの、アップロードの進み具合を扱う機能の項目名である。既定の名前に当てはまるように書かれたルールは、名前を変えたサイトには当たらない。守りが、設定の既定値を前提にしている例である。
WAFを通らない経路
Vercelの告知は、次のように書く。
Vercelの告知は、同じ向きで、Vercelのネットワークを通らない要求（外部のPHPの配信元への直接の要求を含む）は対象外と書く。確かめ方は、当サイトの記事「PHPの脆弱性にWAFの保護が入っても、PHPの更新は要る。Cloudflareは「追加の層」と書いた ── CDNを通らない経路・ルールの対象外・WAFを切ったときを確かめる13項目（2026年10月時点）」にある。
ルールの版を固定している場合
AWSの速報は、AWS WAFのルールについて、次のように書く。
"Customers who have pinned a specific version should update to the latest version to receive this protection."
（訳: 特定の版に固定している利用者は、この保護を受けるために、最新の版に更新する必要がある。）
既定の版を使っていれば自動で保護される、と同じ速報は書く。固定している場合は、自分で更新しない限り、新しいルールが入らない。
| 届かない場合 | 何が起きるか | 書いた出典 |
|---|---|---|
| 配信元で起きたこと | 応答は止められても、すでに動いたことは取り消せない | Cloudflareのブログ（10月27日） |
| 設定を変えた場合 | 既定の名前で書かれたルールは、変更後のサイトに当たらない | Cloudflareのブログ（10月23日の追記） |
| WAFを通らない経路 | 配信元への直接の要求は、WAFの対象外になる | Vercelの告知（10月21日） |
| ルールの版を固定 | 新しいルールを、自分で入れない限り受けられない | AWSのセキュリティ速報（2026-143-AWS） |
催しが測っていないこと
催しの標的は、空の入口のファイルと、標準の拡張だけを入れた、素の環境である。実際のサイトは、CMS、プラグイン、独自のコード、古い版、別のサーバーソフトなどが重なっている。催しの結果は、素の環境でのWAFの強さを示すもので、担当サイトの守りの強さを示すものではないと、筆者は読む。原文も、催しの結果から、実際のサイトの安全を言うとは書いていない。
🅲 手順 — 3つの点で、自社のWAFの守りを確かめる
確かめる点を、次の3つに絞る。順番どおりに、自社のWAFと、サーバーに当てる。
- WAFの状態を、自分の目で見る。ルールが入っているか、ブロックのモードか、除外が付いていないか、を管理画面で見る。
- WAFを通らない経路が無いかを、聞く。配信元に直接届く名前や入口があるかを、サーバーの管理者に聞く。
- PHPの更新が済んでいるかを、版で確かめる。配布元が修正を取り込んだ版は、番号が変わらないことがある。その場合は、配布元の勧告に書かれた版やパッケージで確かめる（方法は、ブログのPHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だった ── 修正が入ったかを値で確かめる4つの方法と、3本目の知らせ（CVE-2026-115560）を当サイトで確かめた記録）。WAFの確認と、更新の確認は、別々に行う。
注意
WAFの管理画面で「ルールが入っている」と出ていても、それは、PHPが更新済みであることを示さない。2つは、別々の画面で、別々の担当者が持っていることが多い。確認の記録も、別々に残す。
05 明日、自社のサイトで確認できることチェックリスト
以下は、担当サイトの前に置かれたWAFの提供元が、守りをどう公開しているかと、PHPの更新が済んでいるかを確かめる13項目である。1〜2番目は使っているWAFの特定と更新履歴、3〜6番目は提供元の公開の仕方、7〜8番目は有料プランの状態と管理画面の確認の済み、9〜10番目はPHPの版、11〜13番目は設定、暫定策、記録である。管理画面でのルールの状態・除外・応答のルール・記録・配信元への直接の経路は、当サイトの記事「PHPの脆弱性にWAFの保護が入っても、PHPの更新は要る。Cloudflareは「追加の層」と書いた ── CDNを通らない経路・ルールの対象外・WAFを切ったときを確かめる13項目（2026年10月時点）」と「CloudflareのWAFは、リクエストと応答を対にして見る検知と応答のルールを全プランに入れた ── 自社の画面とルールを確かめる13項目（2026年10月時点）」の項目に任せる。1項目は5分以内でできる。チェックの状態はブラウザに保存され、サーバーには送られない。
- 担当サイトの前に置かれているWAFまたはCDNの名前を、契約書か管理画面で調べ、サイトごとに1行で書き出す（WAFを使っていないサイトは「なし」と書く）
- 書き出したWAFの提供元の更新履歴のページを開き、2026年10月21日以降に、PHPの脆弱性（CVE-2026-109618・CVE-2026-109619）向けのルールを足したという記述があるかを確かめ、あれば日付を控える
- 提供元のセキュリティのページで、守りを外の人に試してもらう仕組み（報奨金制度や公開の試験）があるかを調べ、「ある・ない・見つからない」で書く
- 同じページで、脆弱性の報告の受付窓口が公開されているかを調べ、あれば窓口の名前かアドレスを控える
- 提供元の10月の告知に、何が守れて何が守れないか（更新の代わりにならない、配信元で起きたことは取り消せない、など）の記述があるかを探し、無ければ提供元への問い合わせ文を1通書く
- 提供元の告知に、保護を出した日時が書かれているかを確かめ、あれば、自社のPHPの更新日と並べて1行で書く
- 有料プランのサイトでは、管理ルールの一式がブロックのモードで動いているかを確かめ、記録のみになっていれば、直す担当者の名前と日付を決める
- 前記の2本の記事の確認項目（ルールの状態・除外・応答のルール・記録・配信元への直接の経路）を済ませた日を、サイトごとに1行で書く
- 担当サイトのPHPの版を確かめ、修正済みの版（8.5.12・8.4.27・8.3.36・8.2.35以上）かを書く。配布元が修正を取り込んだ版は番号が変わらないことがあるので、その場合は配布元の勧告に書かれた版やパッケージで確かめる
- 修正済みの版に上がっていないサイトについて、更新の予定日を1行で書き、更新を担当する人の名前を添える
- PHPの設定を見られる人に、
session.upload_progress.nameを既定の値から変えていないかを聞き、変えていれば、そのサイトの名前を書き出す - 更新までの暫定策（PHP開発元が書いた設定）を、「実施済み・未実施」の一覧にして、実施した日を書く
- 確かめた日と、1〜12番目の結果の数字、次に見直す日を、担当サイトの記録に1行で書く
実務のヒント
提供元の告知に答えが書かれていない項目は、「書かれていない」と記録して、問い合わせにまわす。書かれていないことを、守られていると読まない。
当サイトの無料ツールで補えることもある。サイトを外から調べて、使われているWAFやCDNを含む技術の情報を集めるには、🔧 WEBサイトを外から調べて、セキュリティ対策の状況を点検する、外からできるセキュリティ対策監査ツールが使える。ツールのページによれば、検出の項目にはCMS、フレームワーク、CDN、WAFが入る。会員限定のツールで、管理しているサイトだけに使う、とページに書かれている。ルールの中身が有効かを判定するツールではない。
WAFを抜けた通信の兆候を見たいときは、🔧 IPAの攻撃兆候検出ツールで、アクセスログを簡単に分析するツールが使える。ページによれば、アクセスログを与えると、攻撃の兆候を点検する。会員限定である。PHPのエラーログを読むツールではない。
06 代替・他の選択肢 — 各社が書いた、WAFの限界と、並べて書いた備え
次の表は、WAF、PHPの更新、設定による暫定策の3つを、守れる所・守れない所・手間で比べたものである。内容は、Cloudflare、AWS、Vercel、PHP開発元の文書に書かれた範囲で、まとめ方は筆者の整理である。各ページは、2026年10月29日に開いて確かめた。
| 備え | 守れる所 | 守れない所 | 手間 |
|---|---|---|---|
| WAFのルール | 既知の攻撃の形の要求。応答も見て止める仕組みもある | 配信元で起きたこと、WAFを通らない経路、設定を変えたサイト | 提供元がルールを更新する。自社は状態の確認が要る |
| PHPの更新 | 欠陥そのもの | 更新までの間と、更新の前に起きたこと | サーバーの担当者の作業と、更新後の確認が要る |
| 設定による暫定策 | 特定の攻撃の経路への露出を減らす | インストールを安全にはしない | 設定の変更と、PHPの処理の再起動が要る |
更新までの暫定策は、PHP開発元の文書で見る
更新がすぐにできないときの暫定策は、PHP開発元が文書にまとめている。完全な解決は更新だけで、暫定策は特定の攻撃の経路への露出を減らすが、インストールを安全にはしない、と書く。具体的な設定の項目は、当サイトの記事「PHPの脆弱性にWAFの保護が入っても、PHPの更新は要る。Cloudflareは「追加の層」と書いた ── CDNを通らない経路・ルールの対象外・WAFを切ったときを確かめる13項目（2026年10月時点）」と、ブログのPHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録に載せた。
WAFを使っていないサイトでは
WAFを使っていないサイトにとって、この件の読み方は、1つに絞られる。守りは、PHPの更新と、設定による暫定策だけである。事業者が公開で試しているのは、WAFを持つ側の話で、持たないサイトには、ルールが自動で入ることもない。
その場合、確認項目の1〜8番目は「なし」で終わる。9番目以降が、そのまま本体になる。PHPの版と、更新の予定日を、先に決める。WAFを新しく入れる検討は、更新が済んでから、別の話として行う。
「更新できない」ときの考え方
PHPの版が古く、修正版が出ない系統（8.1以前）のサーバーもある。AWSの速報は、5.4〜8.1に公式の修正版は無く、サポートされている版への移行が必要、と書く。PHP開発元は、7.4・8.0・8.1向けに、ソースからビルドする人などのための最小限の修正を出した。この場合も、WAFは更新の代わりにならない。提供元の保守契約や、配布元が出す修正に、先に問い合わせる。
07 当サイトで確かめたこと — 試したことと、試していないこと
当サイトは、CloudflareのWAFを使っていない。したがって、この記事のCloudflareの管理画面の操作は、当サイトでは試していない。Cloudflareの記事と、各社の告知を読んだ範囲で書いた。
当サイトのPHPは、10月22日の未明に、修正を含む版へ入れ替えた。経緯と、入れ替えのあとに確かめたことは、ブログのPHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録と、PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だった ── 修正が入ったかを値で確かめる4つの方法と、3本目の知らせ（CVE-2026-115560）を当サイトで確かめた記録に書いた。
この記事は、サーバーの設定の中身や、防御の設定の値を書かない。書くのは、公式の文書が公開している範囲と、自分のサイトで同じことを確かめるための項目である。
確かめていないこと
Cloudflare以外のWAFの製品（Akamai、Fastlyなど）が、この件で、どんなルールを、いつ出したかは確かめていない。催しの結果（誰が、いつ、どの方法で破ったか）は、この記事の公開時点では出ていない。結果が出たら、日付つきで追記する。
08 このテーマは、ここまで
WAFと更新の関係は、この1週間、同じ問いを違う角度から書いてきた。
WAFがあっても、PHPの更新は要る
PHPの脆弱性にWAFの保護が入っても、PHPの更新は要る。Cloudflareは「追加の層」と書いた ── CDNを通らない経路・ルールの対象外・WAFを切ったときを確かめる13項目（2026年10月時点）は、10月21日の保護の発表を読んで、WAFの届かない3点を確かめる形にした。今回の記事は、事業者が自分で試す側に、軸を置いた。
応答も見て止める仕組み
CloudflareのWAFは、リクエストと応答を対にして見る検知と応答のルールを全プランに入れた ── 自社の画面とルールを確かめる13項目（2026年10月時点）は、応答のルールの画面と、設定の確かめ方を書いた。
2026年10月29日 — この記事の確認日
この記事の内容は、2026年10月29日に、Cloudflareのブログ3本、AWSの速報、Vercelの告知、PHP開発元とJPCERT/CCのページを開いて確かめた時点のものである。催しの結果や、ルールの更新が出たときは、日付つきで追記する。
現在の貴方のIPアドレス
このサイトで書いている人
