WordPressのmu-pluginsに潜むPopCashマルウェアを見つけて削除する方法
WordPressサイトで意図しないタブが勝手に開くポップアンダー攻撃が続く場合、通常のプラグインではなく mu-plugins フォルダにマルウェアが隠れている可能性が高い。全プラグインを無効化しても症状が消えないなら、必須プラグイン領域とテーマ内の偽 JavaScript ファイルを点検し、該当ファイルを削除したうえで Thrive Architect を最新版へ更新する。
なぜマルウェアはプラグイン無効化後も残るのか
mu-plugins フォルダは「必須プラグイン」とも呼ばれ、/wp-content/mu-plugins/ に置いた PHP ファイルは自動的に読み込まれる。WordPress 管理画面からプラグインを一括停止しても、このフォルダの中身は対象外になるため、攻撃者はここにファイルを置くと症状を消さずに済む。
今回確認された手口では、テーマフォルダ内の js ディレクトリに PHP ファイルが置かれ、JavaScript として配信されていた。拡張子が .php のまま配信時の形式だけを JavaScript に偽装し、テーマの script タグから読み込まれる形を装う。
この PHP ファイルは外部の api-js.popcash.net にサーバー間通信でアクセスし、得たコードを訪問者のブラウザへそのまま流す。ローカルファイル自体には難読化や eval がなく、「広告ネットワークの API を呼び出すだけのコード」に見える。これが Wordfence や Sucuri などのスキャナーに検出されない理由だ。
設定にはポップアンダーを有効にする pop_fback というオプションが含まれる。さらに curl、shell_exec、file_get_contents へ順に切り替えるフォールバックを持つため、サーバー側の関数制限が厳しくても動き続ける。
mu-pluginsに潜む感染ファイルを見つける手順
調査は FTP または SSH でファイルを直接確認するのが確実だ。感染ファイルは管理画面から見えない場所に置かれるため、ブラウザ上のプラグイン一覧だけでは発見できない。
感染ファイルを検出する調査フローを4ステップで示す。以下で各手順を詳しく説明する。
mu-pluginsフォルダ内の全ファイルを確認する
FTP アプリや SSH で /wp-content/mu-plugins/ を開き、ファイル名を目視で確認する。今回確認が取れているのは wp-ppck-assets.php という名前だが、同じ攻撃ツールは qtt-ppck-core.php や qtt-ajax-core.php といった別名でも置かれる。通常のサイト運営で作った覚えのない .php ファイルが1つでもあれば、削除候補として控えておく。
暗号めいた名前をキーワード検索する
ppck、qtt-、popcash といった文字列がファイル名やディレクトリ名に含まれていないか検索する。一見無害な英数字列に変えられたケースもあるため、名前だけで安全と判断せず、中身と更新日時も確認する。
テーマフォルダ内でPHPファイルが.jsとして呼ばれていないか確認する
テーマディレクトリの js フォルダや assets フォルダに、拡張子が .php のファイルが script タグで読み込まれる形跡がないか確認する。JavaScript の置き場所に PHP があること自体が不自然だ。今回のペイロードは qtt-ppck-core.php という PHP ファイルがテーマの js フォルダに置かれ、外部 API から取得したスクリプトを訪問者へ配信していた。
findコマンドで直近に変更されたPHPファイルを洗い出す
SSH が使える環境なら find コマンドで直近60日以内に変更された PHP ファイルを一覧化する。攻撃者は設置後に修正日時を偽装していないことが多いため、この一覧は感染日の特定に有効だ。
find /path/to/wordpress -type f -mtime -60 -name "*.php"マルウェア本体とドロッパーを完全に削除する
感染ファイルを特定したら、本体だけでなく侵入に使われたアップローダーも削除しなければ再感染する。ここでは削除対象と優先順位を整理する。
感染時に存在した不要ファイルと削除後の状態を対比する。削除対象は本体だけに留めない。
最初に該当ファイルをすべて削除する
mu-plugins 内の wp-ppck-assets.php と、テーマ内の qtt-ppck-core.php を削除する。同じツールキットは qtt-ajax-core.php や wp-tmp-up.php、_w10_up.php といった別名でも設置されるため、検索でヒットした全ファイルを対象にする。削除前には必ずバックアップを取り、削除後はサイトの表示と管理画面へのログインが正常にできることを確認する。
ルート直下の検証用テキストファイルも削除する
攻撃者は任意のファイル書き込みが可能か確認するために、WordPress のルートディレクトリへランダムな英数字20文字の .txt ファイルを置くことがある。今回の例では 52faade47ac664d8d0d3.txt というファイルが確認されており、削除対象になる。同様の .txt が残っていれば侵入テストの痕跡として除去する。
バックドアのパターンを全PHPから検索する
ファイルを消しただけでは、別の場所に置かれたバックドアが残る可能性がある。eval(、base64_decode(、gzinflate(、shell_exec(、assert( などの危険な関数が含まれる PHP を全検索する。正規のプラグインが使っている場合もあるため、検索結果はファイルの出所と更新日時を確認しながら判定する。
grep -Rl -e "eval(" -e "base64_decode(" -e "shell_exec(" /path/to/wordpressThrive Architectの脆弱性を塞ぐアップデート手順
今回の感染経路は Thrive Architect のクロスサイトスクリプティング脆弱性だった。プラグインを更新するだけでは設置済みのマルウェアは消えないため、削除作業の後に必ず更新する。
CVE-2026-66694の影響範囲
2026年8月6日に公開された CVE-2026-66694 は、Thrive Architect バージョン10.9.3.1以前に存在する未認証のクロスサイトスクリプティングと任意コード入力の脆弱性だ。自動化されたボットが未パッチのサイトをスキャンし、ファイル書き込み権限を取得してマルウェアを展開した。対象バージョンを使い続けると、同様の侵入が繰り返される。
最新版への更新と注意点
管理画面の更新画面または公式の入手経路から Thrive Architect をバージョン10.9.3.2以降へ更新する。更新によって脆弱性は塞がるが、すでにアップロードされたドロッパーやバックドアは自動的に削除されない。必ず先に感染ファイルの除去を行い、その後で更新する順番を守る。更新後は改めて不審な PHP が増えていないか確認する。
感染後の再発防止と全パスワード変更
マルウェアの削除と脆弱性対策が完了しても、攻撃者が別の認証情報を持っていれば再侵入される。認証情報の変更とログの確認まで行って、初めて駆除は完了する。
全パスワードを必ず変更する
WordPress の管理者、FTP や SFTP、データベース、ホスティングコントロールパネルの全パスワードを変更する。特に FTP や SFTP の認証情報が流出していた場合、管理者パスワードを変えただけでは再侵入を防げない。使い回しのパスワードは避け、二要素認証が使える場所では必ず有効化する。
WordPress本体と全テーマ・プラグインを更新する
WordPress コア、テーマ、すべてのプラグインを最新版にする。使用していないプラグインやテーマは削除する。海賊版や未更新のテーマは既知の脆弱性を多く含むため、公式に配布されている正規品だけを使う。更新後は管理画面と公開ページの動作を確認する。
サーバーログで侵入日時と経路を確認する
アクセスログには攻撃者の痕跡が残っている。今回の例では、任意ファイル書き込みの検証としてルート直下にランダムな .txt が作成され、約30分後に隠しアップローダーへ POST が送られ、その3秒後に curl でペイロードの動作確認が行われていた。ログを感染日の前後で精査すると、同じ手口で侵入されていないか、他に不審なリクエストが残っていないかを確認できる。
よくある質問
mu-pluginsとは何か、普通のプラグインと何が違うのか
mu-plugins は WordPress の必須プラグインフォルダで、手動で .php ファイルを置くと自動的に読み込まれる。管理画面から停止できないため、すべてのプラグインを無効化する操作の対象にならない。普段使わない環境なら中身が空であることが多いが、攻撃者はこの盲点を狙って設置する。
なぜWordfenceやSucuriは検出できなかったのか
マルウェア本体が外部 API を呼び出すだけのシンプルな構成で、eval や base64_decode などの典型的な攻撃パターンを含まないため、シグネチャ検出に引っかからなかった。ローカルファイル自体は無害に見え、危険なコードは外部から動的に取得される。このため、手動でのファイル名確認と日時調査が欠かせない。
Thrive Architectを更新すればマルウェアは自動で消えるか
消えない。アップデートで脆弱性は塞がれるが、すでに書き込まれたドロッパーやバックドアはそのまま残る。先に怪しいファイルを削除してから更新し、更新後にも再検査する順番が重要だ。
FTPが使えない場合はどう調べればよいか
ホスティングのファイルマネージャーやSSHを使う。SSHが利用できるなら find コマンドで直近に変更された PHP を一覧化できる。レンタルサーバーによっては管理画面からファイルマネージャーが提供されるため、まずサーバー管理パネルを確認する。
パスワードを変更するだけでも大丈夫か
不十分だ。ファイルを削除して脆弱性を塞ぎ、バックドアを検索し、ログを確認するまでが一連の駆除になる。パスワード変更は侵入経路を断つ一部であり、単独では再侵入を防げない。
この記事のポイント
- mu-pluginsフォルダは管理画面のプラグイン停止の対象外なので必ず手動で確認する
- ppckやqtt-を含む不審なPHPファイルとテーマ内の偽.jsファイルを削除する
- ドロッパーや検証用txtファイルも含めてバックドアを全検索する
- Thrive ArchitectのCVE-2026-66694対策として最新版へ更新する
- WordPress管理画面とFTPやデータベースの全パスワードを変更して二要素認証を有効化する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Next.js 2026年5月セキュリティリリースの全容、13件の脆弱性を修正
Next.jsの開発元であるVercelは2026年5月7日、調整済みセキュリティリリースを公開した。React Server Componentsの上流脆弱性（CVE-2026-23870）への対応を含む、合計13件の脆弱性が修正されている。フレームワークを利用するすべての開発者にとって、即時のアップデートが強く推奨される内容だ。
今回のリリースで対処された問題は、サービス拒否（DoS）攻撃、ミドルウェアやプロキシのバイパス、サーバーサイドリクエストフォージェリ（SSRF）、キャッシュポイズニング、クロスサイトスクリプティング（XSS）と多岐にわたる。ただちにパッチを適用しなければ、本番環境が深刻な攻撃に晒されるリスクがある。
アップデートの概要と影響範囲
今回のセキュリティリリースはNext.js本体に加え、その根幹をなすReactの特定パッケージにも修正が及ぶ。Vercelの発表によれば、13件の脆弱性アドバイザリが一挙に解決された形だ。アドバイザリの内訳を見ると、攻撃の種類によって影響を受ける機能や設定が明確に分かれている。自社のプロジェクトがどのカテゴリに該当するかを把握することが、迅速な対応への第一歩となる。
● React Server Components の DoS
● キャッシュポイズニング
● SSRF の潜在的リスク
● DoS 攻撃から保護
● キャッシュへの不正注入を防止
● SSRF の脆弱性を遮断
13件の脆弱性が存在する「Before」の状態と、アップデートによってそれらがすべて解決された「After」の状態を比較したイメージだ。リリースによってセキュリティ上のリスクが一掃されることがわかる。
修正対象となったReactとNext.jsのバージョン
影響を受けるバージョンを把握し、修正済みの安全なバージョンへ移行する必要がある。今回のリリースで修正が提供されたバージョンは以下の通りだ。
まず、React本体については、19.0.6、19.1.7、19.2.6の3つのパッチがリリースされた。これらのバージョンでは、サーバーコンポーネントの通信用パッケージである react-server-dom-parcel、react-server-dom-webpack、react-server-dom-turbopack の各パッケージに修正が含まれている。
Next.jsをフレームワークとして利用している場合、これらのReactパッケージはNext.jsのバージョンにバンドルされている。そのため、開発者はNext.js本体を最新のパッチバージョンに更新することで、React側の修正も同時に適用できる。個別にReactパッケージを管理しているプロジェクトは、それらも忘れずにアップデートする必要がある。
各脆弱性の詳細とリスク評価
ここからは、発表されたアドバイザリを深刻度別に整理し、その技術的な背景をひも解いていく。影響を受けるコンポーネントと、攻撃が成立するシナリオを正しく理解することが、開発者としての適切なリスク評価に繋がる。
ミドルウェアとプロキシのバイパス
認証や認可のロジックを middleware.js や proxy.js に依存しているアプリケーションが、致命的な影響を受ける可能性がある。2件の「高」深刻度アドバイザリがこれに該当する。
1件目はApp Routerにおける segment-prefetch のバイパスで、過去の修正が不完全だったための再発フォローアップだ。2件目はPages Routerのi18n機能において、デフォルトロケールのパスがプロキシ認証を迂回してしまう問題である。多言語サイトをPages Routerで運用しており、middlewareでアクセス制御を行っている環境は特に注意が必要だ。
サービス拒否（DoS）攻撃
サーバーのリソースを枯渇させ、正規のユーザーがサイトにアクセスできなくなるDoS攻撃に関する脆弱性が3件報告されている。これらはすべて、Server Functions、Partial Prerendering（PPR）のCache Components、もしくは画像最適化APIの利用が条件となる。
最もクリティカルなものは、React Server Componentsの上流脆弱性（CVE-2026-23870）を突いた攻撃だ。Vercelの発表によると、この脆弱性によりリモートからのDoS攻撃が成立する。また、Cache Componentsを使用するアプリケーションにおける「接続数の枯渇」を引き起こす脆弱性も「高」深刻度と評価されている。画像最適化APIを経由したDoSは「中」深刻度だが、無視できるものではない。
この図は、悪意あるリクエストによってサーバーのリソースが消費され、本来のサービス提供が妨害されるDoS攻撃の基本的な流れを示している。Cache Componentsの脆弱性は、この「リソース枯渇」の段階を特に加速させる危険性がある。
サーバーサイドリクエストフォージェリ（SSRF）
SSRFは、攻撃者がサーバーを踏み台にして内部ネットワークへのリクエストを強制させる攻撃手法だ。今回の脆弱性は、WebSocketへのアップグレードリクエストを処理するアプリケーションが影響を受ける。
この種の攻撃が成功すると、攻撃者は本来アクセスできない内部のメタデータサービスやデータベースと通信できるようになる。クラウド環境（AWSやGCPなど）で稼働しているNext.jsアプリケーションは、特に深刻な被害に繋がる可能性があるため、迅速な対応が求められる。
キャッシュポイズニングとクロスサイトスクリプティング（XSS）
React Server Componentのレスポンスの前にキャッシュ層を配置しているアプリケーションは、キャッシュポイズニングのリスクに晒される。これは、攻撃者が悪意あるレスポンスをキャッシュサーバーに記憶させ、他のユーザーにその不正なコンテンツを配信させる攻撃だ。
XSSに関しては、App RouterでCSP（コンテンツセキュリティポリシー）のnonceを利用しているケース、そして外部からの信頼できない入力を消費する beforeInteractive スクリプトが影響を受ける。これらの設定は比較的高度なカスタマイズで使われるが、該当する場合はすぐに対処しなければ攻撃者によるスクリプト実行を許してしまう。
即時アップデートの必要性と対応手順
Vercelは今回のリリースに際し、新たなWAF（Web Application Firewall）ルールを展開していないと明言している。つまり、これらの脆弱性はWAFレベルで確実にブロックすることができず、パッチ適用が唯一の完全な緩和策となる。
アップデート手順の基本
まず、プロジェクトのNext.jsとReactのバージョンを確認する。package.jsonに記載されているバージョンが、今回の修正対象より古い場合は即座にアップデートを実行する。一般的な手順は以下の通りだ。
# Next.jsのアップデート
npm install next@latest
# 関連するReactパッケージも最新に
npm install react@latest react-dom@latestyarnやpnpmなど、他のパッケージマネージャーを利用している場合も、同等のコマンドで問題ない。パッケージを更新した後は、必ずビルドとテストを実行し、アプリケーションが正常に動作することを確認してほしい。
本番環境でのリスク管理
今回のセキュリティリリースには、破壊的な変更は含まれていない。そのため、動作検証は必要だが、適用を躊躇する技術的理由はほぼない。重要なのは「スピード」だ。
とりわけ、middlewareで認証を実装しているサイト、WebSocketを処理するリアルタイムアプリケーション、そしてPPRやCache Componentsを採用しているパフォーマンス重視のサイトは、緊急度が極めて高い。Vercelの発表でも「all affected users should upgrade immediately（影響を受けるすべてのユーザーは直ちにアップグレードすべき）」と強い表現で呼びかけている。
今回のリリースが示すNext.jsセキュリティの潮流
一見すると大規模な脆弱性の一括修正はネガティブな出来事に思える。しかし、セキュリティの観点からは、むしろフレームワークの成熟度を示すポジティブなシグナルと捉えるべきだ。
まず、対策が「調整済みセキュリティリリース」として計画的に実施されている点が重要だ。これは、VercelとMeta（React）のチームが発見された問題を共有し、エコシステム全体で同時に対処する体制が整っていることを意味する。大規模なOSSプロジェクトでは、このような「調整済み開示」のプロセスがセキュリティ品質の生命線となる。
次に、脆弱性の範囲が「Server Components」「ミドルウェア」「エッジキャッシュ」「画像最適化API」といった、Next.jsの比較的新しい機能や高度な機能に集中している事実に注目したい。これは、攻撃者の標的が、従来のシンプルなWebアプリケーションから、エッジとサーバーを高度に組み合わせたモダンなアーキテクチャへとシフトしている証左だ。
SSRやエッジファンクションの利用が一般化するにつれ、開発者は「新しい機能がもたらす利便性」と「新たな攻撃表面が生まれるリスク」のバランスを常に意識する必要がある。便利なAPIほど、その裏側で何が起きているのかを深く理解することが、これからのフロントエンド開発者には不可欠だ。
この記事のポイント
- Next.js 2026年5月セキュリティリリースは、ReactのCVE-2026-23870を含む13件の脆弱性を修正する
- 影響範囲はDoS、ミドルウェアバイパス、SSRF、キャッシュポイズニング、XSSと多岐にわたる
- WAFでは防げない脆弱性群のため、Next.jsとReact関連パッケージの即時アップデートが唯一の対策
- とくに認証機能やServer Components系の新機能を使うプロジェクトは緊急度が高い
- 調整済みリリースの実施は、Next.jsエコシステムのセキュリティ成熟度を示すポジティブな側面でもある
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WAFの「ログかブロックか」を卒業。Cloudflareが提唱するAttack Signature Detectionの革新性
WAF（Web Application Firewall / ウェブ・アプリケーション・ファイアウォール）の運用において、セキュリティ担当者を長年悩ませてきた「ログモードかブロックモードか」という二者択一に、終止符が打たれようとしている。
Cloudflareが発表した「Attack Signature Detection（アタック・シグネチャ・デテクション）」は、検知と遮断のアクションを分離することで、防御性能を維持しながらトラフィックの完全な可視化を実現する技術だ。
この新機能は、従来のWAFが抱えていた「遮断を優先すると、他の攻撃シグネチャがどう反応したかのデータが失われる」という構造的な欠陥を解消する。
WAFの課題「検知か遮断か」のジレンマを解消する新アプローチ
従来のWAF運用では、新しいアプリケーションを公開する際、まず「ログ専用モード」で数週間稼働させることが一般的だった。
これは、WAFが正規の通信を誤って攻撃と判断してしまう「誤検知（False Positive）」を防ぐための調整期間だ。
ログモードとブロックモードの壁
ログモードでは攻撃を防げず、ブロックモードでは誤検知によってビジネス機会を損失するリスクがある。
さらに深刻なのは、ブロックモードで特定のルールがリクエストを遮断した場合、その時点で処理が終了してしまう点だ。
これにより、他のシグネチャ（攻撃のパターンを定義した識別子）がそのリクエストをどう評価したかという貴重なインサイトが得られなくなる。
多角的な防御策を講じる上で、この「可視性の欠如」は防御の最適化を妨げる大きな要因となっていた。
検知とアクションを分離する「常時稼働」モデル
Attack Signature Detectionは、このトレードオフを「検知の常時稼働」という概念で解決する。
リクエストが届いた際、まず全ての検知シグネチャを走らせてリッチなメタデータを付与し、その後に実際の遮断アクションを行うかどうかを判定する仕組みだ。
これにより、たとえリクエストをブロックしたとしても、背後でどのシグネチャが反応していたかを全て記録に残すことが可能になる。
Attack Signature Detection：常時稼働する高精度な検知エンジン
Attack Signature Detectionは、Cloudflareのマネージドルールセットと同じ高度なヒューリスティック（経験則に基づいた分析手法）を利用している。
SQLインジェクション（SQLi）やクロスサイトスクリプティング（XSS）といった代表的な攻撃から、最新のCVE（Common Vulnerabilities and Exposures / 共通脆弱性識別子）まで、700以上のルールがリアルタイムで適用される。
信頼度（Confidence）による分類
各シグネチャには「カテゴリー」と「信頼度」というタグが付与されている。
信頼度は、そのシグネチャが正規の通信を誤検知する可能性の低さを示す指標だ。
- High（高信頼度）: 誤検知が極めて少なく、即座にブロックモードでの運用が推奨される。
- Medium（中信頼度）: トラフィックの特性によっては誤検知の可能性があるため、事前の分析が推奨される。
運用者はこれらの指標を基に、「信頼度が高いシグネチャに一致した時だけブロックする」といった柔軟なポリシーをノーコードで作成できる。
パフォーマンスへの影響を最小限に抑える設計
「全てのシグネチャを常時稼働させると、通信速度が低下するのではないか」という懸念が生じるのは自然なことだ。
しかし、このフレームワークは効率性を極限まで高めている。
特定の検知に基づいた遮断ルールが設定されていない場合、検知処理はリクエストがオリジンサーバー（Webサイトの本体が稼働しているサーバー）へ送信された「後」に実行される。
この非同期処理により、検知そのものがユーザーの体感速度に影響を与えることはない。
Full-Transaction Detection：レスポンスまで見通す次世代の防御
Attack Signature Detectionのさらに先を行く進化として開発されているのが、「Full-Transaction Detection（フル・トランザクション・デテクション）」だ。
従来のWAFは、ユーザーからの「リクエスト（問いかけ）」の内容だけを見て攻撃を判断していた。
しかし、Full-Transaction Detectionは、サーバーからの「レスポンス（回答）」も含めた一連のやり取り（トランザクション）を分析対象とする。
「攻撃の成否」を判断する重要性
例えば、URLの末尾にSQLインジェクションのコードが含まれていたとする。
リクエストだけを見れば攻撃だが、サーバーが「500 Internal Server Error」や「404 Not Found」を返していれば、その攻撃は失敗したと判断できる。
一方で、サーバーが「200 OK」を返し、かつレスポンスボディにユーザーのパスワード一覧のような機密データが含まれていた場合、それは「攻撃が成功した」ことを意味する。
このように、レスポンスを相関分析することで、誤検知を劇的に減らし、真に危険なイベントだけを抽出することが可能になる。
データ漏洩と設定ミスの検知
この技術は、外部からの攻撃だけでなく、内部の設定ミスや意図しないデータ露出の検知にも威力を発揮する。
例えば、管理者が誤って公開設定にしてしまったElasticsearch（検索エンジン）のインターフェースや、Apacheの機密エンドポイントへのアクセスを検知できる。
また、正規のAPIリクエストであっても、レスポンスに数千件のクレジットカード番号が含まれているような異常な事態（データエクスフィルトレーション / データ持ち出し）を即座に特定できる点は、従来のWAFにはない強みだ。
セキュリティ運用を劇的に変える分析とルールのカスタマイズ
Attack Signature Detectionがもたらす最大の価値は、セキュリティ運用の「データ駆動型」への転換だ。
Security Analytics（セキュリティ・アナリティクス）のダッシュボードを活用することで、専門家でなくても自社サイトがどのような攻撃にさらされているかを詳細に把握できる。
Security Analyticsによる可視化
ダッシュボードでは、どのCVEを狙った攻撃が多いか、どのエンドポイント（URL）が標的になっているかがグラフ化される。
例えば、特定のAPIパス（`/api/v1/`など）に対して執拗に攻撃を繰り返しているIPアドレスを特定し、その場で遮断ルールを作成するといったアクションがスムーズに行える。
また、過去のトラフィックデータに対して「もしこのルールを適用していたらどうなっていたか」というシミュレーションを行うことも可能だ。
柔軟なルールエンジンの活用
検知されたメタデータは、Cloudflareの「Edge Rules Engine」で自由に利用できる。
「信頼度がMediumのシグネチャに一致した場合は、即座にブロックせず、Managed Challenge（人間であることを確認する認証画面）を表示する」といった、ユーザー体験を損なわない防御策も容易に実装できる。
こうした「多層防御」の構築が、複雑なスクリプトを書くことなくGUI上で行える点は、リソースの限られた中小企業のWeb担当者にとっても大きなメリットとなるだろう。
独自の分析：Web制作現場におけるWAF運用のパラダイムシフト
これまでのWeb制作や保守運用の現場では、WAFは「導入して終わり」か、あるいは「誤検知が怖いからオフにする」という極端な運用に陥りがちだった。
しかし、Attack Signature Detectionの登場により、WAFは「静的な壁」から「動的なセンサー」へと進化したと捉えるべきだ。
筆者の分析では、この技術が普及することで、以下の3つの変化が起こると予測している。
第一に、WAF導入の心理的ハードルが下がる。
「とりあえず検知だけさせてデータを貯める」というスモールスタートが、パフォーマンスへの影響なしに可能になるからだ。
第二に、インシデント対応の迅速化だ。
リクエストとレスポンスの両面から攻撃の成否が可視化されるため、ログを数時間かけて解析しなくても、どの脆弱性が突かれたのかが瞬時に判明する。
第三に、開発とセキュリティの融合（DevSecOps）が加速する。
開発者はWAFの検知データをフィードバックとして受け取り、コードレベルでの修正が必要なのか、WAFでの対応で十分なのかをデータに基づいて判断できるようになる。
もはやセキュリティは、開発の足を引っ張る存在ではなく、安全なリリースを支える強力なインフラへと変貌を遂げている。
この記事のポイント
- WAFの課題だった「検知（ログ）か遮断（ブロック）か」の選択を、機能を分離することで解消した。
- Attack Signature Detectionは常時稼働し、リクエストに詳細なメタデータを付与して可視性を高める。
- Full-Transaction Detectionにより、レスポンスまで分析して攻撃の成功・失敗を正確に判別できる。
- 非同期処理の導入により、高度な検知を行いながらもユーザーの通信速度に影響を与えない設計を実現した。
- 専門知識がなくても、信頼度に基づいた柔軟なセキュリティポリシーの運用が可能になった。
出典
- Cloudflare Blog「Always-on detections: eliminating the WAF “log versus block” trade-off」（2026年3月4日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験