Bricks Builder と、その拡張プラグイン Bricksforge で WordPress サイトを制作・運用している Web 担当者、制作会社の保守担当者向けの記事です。
Bricksforge の 3.1.8.9 以前に、ログインなしでサーバーへ PHP ファイルを書き込まれる脆弱性 CVE-2026-85097 が見つかり、2026年10月7日から実際の攻撃が観測されています。
この記事では「自分のサイトが対象か」「どこまで更新すればよいか」「すでに PHP を置かれていないか」を、コピペで確認できるコマンド付きでまとめます。
何が起きたのか
| 項目 | 内容 |
|---|---|
| CVE | CVE-2026-85097(CVE レコード) |
| 対象 | Bricksforge(Bricks Builder 用の有償拡張プラグイン)の Pro Forms(フォーム機能) |
| 種別 | 危険な種類のファイルのアップロード制限不備(CWE-434)→ リモートからの PHP 実行(RCE) |
| 認証 | 不要 |
| 影響バージョン | 3.1.8.9 以前 |
| 修正版 | 3.1.8.10(3.x 系)/ 4.0.0 以降(最新は 4.0.1、2026-10-08) |
| 深刻度 | CVSS v3.1 9.8〜10.0(Critical)(評価元により異なる) |
| 利用サイト数 | 約 6,000(Patchstack の推定) |
| 悪用状況 | 2026-10-07 21:47(UTC)から悪用の試行を観測(Patchstack) |
Patchstack の解説によると、原因は Pro Forms のファイルアップロード処理の検証漏れです。アップロード時にはファイルの種類(MIME タイプ)を確認していたものの、フォーム送信時にはブラウザ側から送られてくるファイル情報(保存先の指定を含む)をそのまま信用していました。その結果、「画像として検査を通ったファイル」を PHP ファイルとして書き出させることができてしまいます。書き出された PHP は URL へのアクセスだけで実行され、サイト乗っ取り(Web シェル設置・改ざん)に直結します。
押さえておくべき点は3つです。
- フォームにアップロード欄が無くても対象。 公式の更新履歴では、Pro Forms が有効なサイトはすべて影響を受けると明記されています。
- 攻撃は自動化されている。 44 の IP アドレスから数秒の間に同一内容のリクエストが届いた例が報告されています。小規模サイトでも順番が回ってきます。
- 更新しても、置かれたファイルは消えない。 未修正の期間があったサイトは、更新とあわせて痕跡確認が必要です。
攻撃の再現手順は扱いません。以下は「同じ被害を防ぐ」ための確認と対処です。
1. まずバージョンを確認する(1分)
WP-CLI が使える環境なら、これで確認できます。
# Bricksforge のバージョンと有効/無効
wp plugin list --fields=name,status,version | grep -i bricksforge
# 親テーマが Bricks か(子テーマ運用が多いので親を見る)
wp option get template
WP-CLI が無い環境では、管理画面の「プラグイン」一覧でバージョンを確認します。判定は次のとおりです。
| 現在のバージョン | 判定 | 対応 |
|---|---|---|
| 3.1.8.9 以前 | 脆弱 | 3.1.8.10 以上へ更新(4.x へ上げられるなら 4.0.1) |
| 3.1.8.10 以降の 3.x | 修正済み | 痕跡確認(5.)のみ |
| 4.0.0 / 4.0.1 | 修正済み | 4.0.1 推奨。痕跡確認(5.)のみ |
2. 対処:更新する
更新前にバックアップを取ります。
# DB とファイルのバックアップ(保存先は公開ディレクトリの外へ)
wp db export ~/backup-db-$(date +%Y%m%d).sql
tar czf ~/backup-files-$(date +%Y%m%d).tar.gz wp-content wp-config.php
# プラグインを更新して、反映を確認
wp plugin update bricksforge
wp plugin list --fields=name,status,version | grep -i bricksforge
Bricksforge は wordpress.org で配布されている無料プラグインではなく、有償の製品です。ライセンスの期限切れや未登録の状態では、管理画面やWP-CLIに更新が出ないことがあります。その場合は公式サイトのアカウントから最新版を取得して入れ替えてください。「更新通知が出ていない=最新」ではありません。 必ずバージョン番号で確認します。
4.0 系はメジャー更新です。すぐ移行できない場合も、最低限 3.1.8.10 へは今すぐ上げ、4.0 系はステージングで確認してから移行してください。
3. uploads 配下で PHP を実行させない(恒久対策)
今回の攻撃は「アップロード用のディレクトリに PHP ファイルを書き出し、そこへアクセスして実行する」形です。WordPress の wp-content/uploads/ に PHP を実行する正当な理由は通常ありません。uploads で PHP が動かない設定にしておけば、この種の脆弱性で書き込まれても実行には至りにくくなります。
報告では、攻撃者が .php 以外の拡張子(.phtml .pht .php5 など)や大文字小文字の違いも試しています。拡張子は広めに、大文字小文字を区別せずに拒否します。
nginx の場合(server ブロック内。PHP-FPM へ渡す location ~ \.php$ より前に書く):
# uploads 配下の PHP 系ファイルは実行させず 403
location ~* ^/wp-content/uploads/.*\.(php[0-9]?|phtml|pht|phar)$ {
deny all;
}
# 設定を検査してから反映
sudo nginx -t && sudo systemctl reload nginx
# 効いているか確認(存在しないファイルでも 403 が返れば OK。404 なら PHP 側へ回っている)
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/wp-content/uploads/test.php
Apache の場合(wp-content/uploads/.htaccess を作成。AllowOverride で .htaccess が有効な環境):
# uploads 配下の PHP 系ファイルへのアクセスを拒否(大文字小文字を区別しない)
<FilesMatch "(?i)\.(php[0-9]?|phtml|pht|phar)$">
Require all denied
</FilesMatch>
4. すぐに更新できないときの一時的な緩和
ライセンス更新待ちなどで即時更新できない場合の選択肢です。いずれも制限を強める方向の設定で、更新の代わりにはなりません。
-
Pro Forms を止める。 Pro Forms を使っていないなら、Bricksforge の設定で無効にします。サイトの表示に Bricksforge が必須でなければ、プラグイン自体を停止するのが確実です(
wp plugin deactivate bricksforge)。 - フォーム送信の受け口を閉じる。 Bricksforge のフォームを使っていないサイトに限り、攻撃の大半が向かっている REST API の送信口を Web サーバーで拒否できます。
# Bricksforge のフォーム送信 REST ルートを拒否(フォーム未使用サイトのみ)
location ^~ /wp-json/bricksforge/ {
return 403;
}
# パーマリンク未設定時の ?rest_route= 経由も拒否
if ($arg_rest_route ~* "^/?bricksforge/") {
return 403;
}
ただし admin-ajax.php 経由の送信もあり、こちらはリクエスト本文の中身で判定する必要があるため、Web サーバーの設定だけでは塞ぎ切れません。3. の uploads での PHP 実行禁止とあわせて、あくまで更新までのつなぎとして使ってください。
5. すでに PHP を置かれていないかを確認する
未修正のまま 10月7日以降を過ごしたサイトは、次を確認します。
uploads 配下の PHP ファイル
# uploads 配下の PHP 系ファイル(本来ほぼ存在しない。大文字小文字を区別しない)
find wp-content/uploads -type f -iregex '.*\.\(php[0-9]?\|phtml\|pht\|phar\)' \
-printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
# Bricksforge の一時アップロード用ディレクトリの中身
ls -la wp-content/uploads/bricksforge/tmp/ 2>/dev/null
# 報告されているファイル名パターン
find wp-content -type f -iname 'login_admin_*' 2>/dev/null
# 10/7 以降に作成・変更された PHP ファイル(uploads 以外も)
find . -type f -iname '*.php*' -newermt '2026-10-07' -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
アクセスログ
POST の本文は通常アクセスログに残らないため、ログで見るのは「送信口へのアクセス量」と「置かれたファイルへのアクセス」です。
# フォーム送信口へのアクセスを IP 別に集計(正規の問い合わせより突出して多い IP に注意)
zgrep -E "bricksforge/v1/form_submit|bricksforge_regenerate_nonce|bricksforge_form_submit" \
/var/log/nginx/access.log* | awk '{print $1}' | sort | uniq -c | sort -rn | head -20
# uploads 配下の PHP 系ファイルへのアクセス(ステータスコード付き)
zgrep -iE '"(GET|POST) /wp-content/uploads/[^ ]*\.(php[0-9]?|phtml|pht|phar)' \
/var/log/nginx/access.log* | awk '{print $1, $4, $7, $9}' | head -50
Apache の場合はログのパスを /var/log/apache2/access.log*(RHEL 系は /var/log/httpd/access_log*)に読み替えてください。2つ目の集計で 200 を返しているものがあれば、置かれたファイルが実行された可能性があり、要精査です。
アカウント・改ざん・常駐
# 身に覚えのない管理者アカウントが増えていないか
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
# コアと wordpress.org 配布プラグインの改ざん検査(有償プラグインは対象外)
wp core verify-checksums
wp plugin verify-checksums --all
# 不審な常駐(mu-plugins / スケジュール実行)
ls -la wp-content/mu-plugins/
wp cron event list
痕跡が見つかった場合は、ファイルを消して終わりにせず、侵害前のバックアップからの復元と、管理者パスワード・DB パスワード・wp-config.php の認証用キー(salt)の変更までをセットで行ってください。
まとめ
- CVE-2026-85097 は Bricksforge 3.1.8.9 以前の Pro Forms にある未認証のファイルアップロード脆弱性で、PHP の実行(RCE)につながる。CVSS は 9.8〜10.0、10月7日から自動化された攻撃を観測
- フォームにアップロード欄が無くても、Pro Forms が有効なら対象
- 3.1.8.10 以上(推奨は 4.0.1)へ更新する。有償プラグインなので、更新通知の有無ではなくバージョン番号で確認する
- 恒久対策として、uploads 配下で PHP を実行させない設定を nginx / Apache に入れる
- 10/7 以降に未修正の期間があったサイトは、uploads 配下の PHP ファイル・
login_admin_*・アクセスログ・管理者アカウントを確認する
関連記事
本記事のような更新漏れ・設定の抜けは、Web サイトを 9 つの守りでまるごと守るサイトドックでまとめて対策できます → https://sitedock.jp