If you run Bricksforge, update it now. A critical flaw in the plugin, CVE-2026-85097, lets anyone on the internet upload a PHP file to your server and run it. No login required. Attackers have been exploiting it since October 7, 2026.
At a glance
| CVE | CVE-2026-85097 |
|---|---|
| Plugin | Bricksforge, a commercial add-on for the Bricks site builder (about 6,000 sites) |
| Type | Unauthenticated arbitrary file upload, leading to remote code execution |
| Severity | CVSS 10.0 per Patchstack (some reports list 9.8) — critical either way |
| Affected | 3.1.8.9 and earlier |
| Fixed | 3.1.8.10 and 4.0.0. Latest is 4.0.2 (October 13, 2026), with further hardening |
| Status | Actively exploited since October 7, 2026, 21:47 UTC |
What’s wrong
The bug is in Bricksforge’s Pro Forms file upload. It’s a classic case of checking a file once and trusting it forever after.
When a visitor uploads a file through a form, Bricksforge checks its MIME type and parks it in a temporary folder. When the form is then submitted, the plugin moves the file to its final location. But it takes that final location from the request itself, from a url field inside a parameter called temporaryFileUploads, and never validates it. The browser says where the file goes, and the plugin believes it.
That turns into a four-step attack:
- Get a nonce. Bricksforge has an AJAX action,
bricksforge_regenerate_nonce, that hands a valid nonce to anyone who asks. The nonce that’s supposed to prove a request is legitimate is free for the taking. - Upload a polyglot. The attacker uploads a file that is a valid GIF and valid PHP at the same time. It passes the MIME check and lands in the temporary folder.
- Submit the form with a PHP destination. The submission points
fileat the GIF and setsurlto a name ending in.php. - Run it. The plugin writes the file to the PHP location. The attacker requests it, and the server executes it.
From there, it’s a web shell, persistent access and full control of the site.
What the attacks look like
Patchstack has published what its sensors caught. The traffic is automated and fast:
- Almost every request goes to
POST /wp-json/bricksforge/v1/form_submit, with a craftedtemporaryFileUploadsparameter. A few useadmin-ajax.phpwith the actionbricksforge_form_submit. - About 95% pair a
.gifor.pngsource with a PHP destination. - Dropped files are named like
login_admin_*.php, aimed at/wp-content/uploads/2026/10/. - Attackers cycle through extensions and encodings to get past filters:
.php5,.phtml,.PHP,.pHp,%2ephpand double-encoded variants. - In one burst, 44 IP addresses sent 56 identical requests within seconds. In another, 3 IPs tried 25 variations against the same file. That’s rotating proxies and scripts, not a person at a keyboard.
The six most active source IPs, about 46% of all requests out of 63 seen in total:
177.75.57.20
23.97.62.146
84.247.60.125
38.154.185.97
150.109.16.166
153.75.90.146Blocking these won’t protect you on its own. There are dozens more and they change constantly. They’re useful for checking your logs.
What to do
1. Update
Install the latest Bricksforge, 4.0.2 as of this writing. If you’re staying on the 3.x line, 3.1.8.10 is the minimum. Anything at 3.1.8.9 or below is wide open.
2. Check whether you were hit
Updating closes the hole. It doesn’t remove anything an attacker already planted. If your site ran a vulnerable version after October 7, check:
- Uploads for PHP files. There should be no
.phpfiles anywhere underwp-content/uploads/. Look especially inuploads/bricksforge/tmp/and for anything namedlogin_admin_*.php. - Access logs for requests to
/wp-json/bricksforge/v1/form_submitcontainingtemporaryFileUploads, calls tobricksforge_regenerate_noncefollowed by uploads, and bursts of form submissions cycling file extensions. - Users. Look for administrator accounts you didn’t create.
- Plugins and must-use plugins. Look for anything you didn’t install, including in
wp-content/mu-plugins/, which doesn’t show on the regular Plugins screen.
If you find a web shell, treat the whole site as compromised: restore from a clean backup taken before October 7, change every password and key, and replace the salts in wp-config.php.
3. Stop PHP from running in uploads
This attack only works because the server will execute a PHP file sitting in the uploads folder. Nothing legitimate in WordPress needs that. Telling the web server never to run PHP from wp-content/uploads/ turns this whole class of bug, in any plugin, from a site takeover into a harmless stray file. On Apache or LiteSpeed, an .htaccess file in the uploads folder does it:
<FilesMatch "\.(php|php[0-9]|phtml|phps|phar)$">
Require all denied
</FilesMatch>On Nginx, the equivalent is a location block in the server config that denies PHP under /wp-content/uploads/.
The bigger lesson
Two mistakes made this possible. The plugin trusted data from the browser about where to write a file, and it handed out nonces to anyone who asked, which turned a security check into a formality. Neither is exotic. Both show up again and again in WordPress plugin advisories.
It’s also a reminder of why every plugin should earn its place. Bricksforge is an add-on to a site builder, a second layer of third-party code on top of the first. Each layer is more forms, more endpoints and more upload handlers that someone else wrote and you have to trust. Fewer plugins means fewer of these emails.