Bricksforge RCE (CVE-2026-85097) exploited: patch and check your site

If you build sites with Bricks Builder and use the Bricksforge add-on, stop what you’re doing and check your version. A critical flaw (CVE-2026-85097) lets anyone on the internet, without logging in, upload a PHP file and run it on your server. Patchstack has seen it exploited in the wild since October 7, 2026, 21:47 UTC.

• Affected: Bricksforge 3.1.8.9 and older
• Fixed in: 3.1.8.10 (as of October 19, 2026 the current release is in the 4.0 branch)
• Severity: critical, CVSS 10.0 per Patchstack, 9.8 per Wordfence
• Sites exposed: about 6,000 according to Patchstack

Updating closes the hole, but it does not remove anything an attacker already uploaded. So this post covers both: patch, then check whether someone got in before you did.

How the attack works

The bug is in how Bricksforge Pro Forms handles file uploads. Based on the published analysis:

1. The attacker grabs a valid nonce from the public bricksforge_regenerate_nonce AJAX action. No login is needed.
2. They upload a file that is both a valid GIF and PHP code (a “polyglot”). The MIME check sees an image and lets it through into the temporary upload folder.
3. They submit the form with a crafted temporaryFileUploads parameter whose url ends in .php. The plugin trusts that value and writes the GIF’s contents to a .php file.
4. They request that file, and their code runs with your site’s permissions.

Requests go to /wp-json/bricksforge/v1/form_submit or to admin-ajax.php with the action bricksforge_form_submit. Attackers also try .php5, .php7, .phtml, mixed case like .pHp, and URL-encoded extensions like %2ephp. It’s a classic arbitrary code execution bug, and it is being hit by automated scanners from dozens of IPs.

Step 1: Are you running a vulnerable version?

Check in Plugins → Installed Plugins, or with WP-CLI:

wp plugin list --fields=name,status,version | grep -i bricksforge

Anything at 3.1.8.9 or lower is vulnerable. Managing many sites? Run it over all of them with a vulnerability scan or a WP-CLI alias group.

Step 2: Update (or switch it off until you can)

Bricksforge is a commercial plugin, so updates arrive through your license. Update from the Plugins screen, or download the latest zip from your Bricksforge account and upload it. If the license is connected, WP-CLI works too:

wp plugin update bricksforge

Can’t update right now (expired license, client approval, staging first)? Deactivate it. Your Bricksforge forms stop working, but that beats a backdoor:

wp plugin deactivate bricksforge

Step 3: Never let PHP run from uploads

The payload ends up under wp-content/uploads/. WordPress never needs to execute PHP from that folder, so block it. This one rule would have neutralized this attack and plenty of past upload bugs.

Apache / LiteSpeed: create wp-content/uploads/.htaccess:

<FilesMatch "(?i).(phpd?|phtml|phar|pht)$">
    Require all denied
</FilesMatch>

Nginx: add this to the server block, above your main location ~ .php$:

location ~* ^/wp-content/uploads/.*.(phpd?|phtml|phar|pht)$ {
    deny all;
}

Test it by putting a file like test.php in uploads and opening it in the browser. You should get a 403. Then delete the test file.

---

Step 4: Check whether you were already hit

Exploitation started on October 7, so if you were on 3.1.8.9 or older after that date, assume someone tried. Take a full backup (files + database) before you change anything, because you may need it as evidence. Then, from the WordPress root:

1. Any PHP files in uploads? There should be none:

find wp-content/uploads -type f -iregex '.*.(php[0-9]?|phtml|phar|pht)$' -ls

2. The Bricksforge temp folder, where the polyglot files land:

ls -la wp-content/uploads/bricksforge/tmp/

3. “Images” that contain PHP code:

grep -rlI --include='*.gif' --include='*.jpg' --include='*.png' -e '<?php' -e '<?=' wp-content/uploads

4. Exploit requests in your access logs. The REST route is easy to spot. The AJAX variant only shows up as a POST /wp-admin/admin-ajax.php, because the action name is in the request body.

grep -E "bricksforge/v1/form_submit|uploads/bricksforge/tmp/.*.ph" /var/log/nginx/access.log*

Patchstack also published the IPs that sent the most attack traffic. Check your logs for them and block them, keeping in mind that they rotate:

grep -E "177.75.57.20|23.97.62.146|84.247.60.125|38.154.185.97|150.109.16.166|153.75.90.146" /var/log/nginx/access.log*

5. What attackers usually do next: add an admin, drop a must-use plugin, edit core files.

# admins, newest last: anyone you don't know?
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# must-use plugins load automatically and don't show in the normal plugin list
ls -la wp-content/mu-plugins/

# PHP files changed in the last 14 days
find . -name '*.php' -mtime -14 -not -path './wp-content/cache/*' -ls

# core and wordpress.org plugin files compared against the official checksums
wp core verify-checksums
wp plugin verify-checksums --all

If any of this turns up something you can’t explain, the site is compromised. Updating the plugin is not enough at that point. Follow the full hacked WordPress cleanup guide:

• Remove the backdoors.
• Reinstall core and plugins from clean sources.
• Change every password.
• Rotate the salts in wp-config.php, which logs everyone out.

Not sure what to look for? See how to tell if a WordPress site is hacked.

Server-side protection: OpenPanel vs cPanel

Bugs like this are why I want protection below WordPress, not just in a security plugin. If the attacker’s file runs before your plugin loads, the plugin can’t help.

• OpenPanel: every domain sits behind the Coraza WAF with the OWASP Core Rule Set. You can set it to Protect or Monitor per domain. Users can also scan their own files with the built-in ClamAV malware scanner, straight from their panel. Each account runs in its own container, so one hacked site can’t wander into the neighbors’ files.
• cPanel: you get ModSecurity too, but malware scanning usually means a separate product like ImunifyAV, or whatever your host adds.

Either way, a generic WAF rule set won’t necessarily catch a brand-new plugin bug. The “no PHP in uploads” rule from Step 3 is the one that saves you.

TL;DR: Bricksforge 3.1.8.9 and older has an unauthenticated RCE (CVE-2026-85097) that has been exploited since October 7. Update to 3.1.8.10 or newer, or deactivate the plugin. Block PHP execution in wp-content/uploads. Then check uploads, mu-plugins, your admin users and your access logs for signs it was used against you.