WordPressのページビルダー「Bricks Builder」に機能を足す拡張プラグイン、Bricksforgeで深刻な脆弱性が見つかり、すでに実際の攻撃が始まっています。WordPressのセキュリティ企業Patchstackが10月8日に公開した解説によると、ログインしていない第三者がサーバーにPHPファイルを置き、そのまま実行できてしまう問題で、CVE-2026-85097として登録されています。影響を受けるのは3.1.8.9以前で、3.1.8.10で修正済みです。利用サイトはおよそ6,000件とされ、規模こそ大きくありませんが、Bricks Builderでフォームや動きのある画面を作り込んだ案件ではよく組み合わされるプラグインです。

入口では画像として正しく検査されていた

興味深いのは、アップロードの入口ではファイルの種類がきちんと確認されていた点です。Patchstackの説明では、プラグインは最初のアップロード時にMIMEタイプを検査しているものの、その後フォームを送信する段階では、ブラウザ側から送られてくるファイル情報を信じてしまっていました。攻撃者はまず画像としても成立し、中にPHPのコードも含む「ポリグロット」と呼ばれるファイルを用意し、正規の画像として一時フォルダに置かせます。次にフォーム送信時の情報で、保存先のURLだけを拡張子.phpに書き換えると、画像の中身がPHPファイルとして配置され、アクセスするとコードが動く、という流れです。必要な認証用の値(nonce)も、ログイン不要の窓口から取得できる状態でした。

攻撃の観測は10月7日の夜(協定世界時)から始まっています。63件の異なる送信元が確認され、44件の送信元が数秒のうちに同じ内容を一斉に送るなど、自動化された動きが目立つそうです。.php以外の拡張子(.phtmlや.php7など)、大文字小文字の混在、URLエンコードした拡張子など、制限をすり抜ける書き方も次々に試されているとのことです。

Bricksforgeを入れているサイトでは、まず3.1.8.10以降への更新が最優先です。そのうえで、更新前の期間に狙われていないかを確認しておくと安心です。Patchstackは、/wp-content/uploads/bricksforge/tmp/ をはじめとするアップロード用フォルダに見覚えのないPHPファイルがないか、特に login_admin_ で始まる名前のファイルがないかを確かめるよう勧めています。アクセスログでは、/wp-json/bricksforge/v1/form_submit への送信で、画像のパスとPHPの保存先が組み合わされているものが目印になります。

今回の件は「アップロード時に検査しているから大丈夫」という前提が、処理の後段で崩れた例といえます。私たち制作側としては、納品したサイトにどの拡張プラグインが入っているかを一覧で把握しておくこと、そしてアップロード用フォルダではPHPを実行させないサーバー設定を標準にしておくことが、こうした問題の被害を小さくする地道な備えになりそうです。