If your WordPress site uses Bricksforge, update it today

If your website is built with Bricks Builder and you've added the Bricksforge plugin, update Bricksforge today. A flaw in it lets a stranger upload code to your site and run it, without logging in, and attackers are already trying it on live sites.

If you don't use Bricksforge, this one doesn't affect you. The checks at the end of this post are still worth doing on any WordPress site, though.

What happened

Bricksforge is an add-on for Bricks Builder, a tool for building WordPress sites. It adds forms, animations and other extras. The security firm Patchstack published details of the flaw on 8 October. It's tracked as CVE-2026-85097, and Patchstack rates it 10 out of 10. That's as bad as the scale goes.

In plain English, the problem is in the file upload on Bricksforge's forms. The plugin checks a file properly when it's uploaded, but when the form is sent, Patchstack says "it trusts the file metadata the client sends". So an attacker uploads something that looks like an image but has code hidden inside it, then tells the form to save it as a PHP file. Your server then runs that code whenever someone visits the file.

That's the worst kind of website flaw. Whoever does it can usually do anything your website can do.

Is it actually being used?

Yes. Patchstack first saw attacks on 7 October and recorded them coming from 63 different internet addresses. It describes the traffic as automated, which is what you'd expect. Nobody is choosing your site by hand. Scripts work through the internet looking for any site running the plugin.

Patchstack's advisory says versions 3.1.8.9 and earlier are affected, and 3.1.8.10 fixes it. Bricksforge's own changelog says the flaw is also fixed in 4.0.0. Since then they've put out two more releases with extra security fixes for the forms upload: 4.0.1 on 8 October and 4.0.2 on 13 October. The changelog says the 4.0.1 fix applies to every site with Pro Forms switched on, even if your forms have no upload field.

Does it affect you?

You're affected if all of these are true:

• Your site runs WordPress with Bricks Builder.
• The Bricksforge plugin is installed and active.
• It's on a version older than the fixes above.

If someone else built your site, you might not know what's in it. Log in to WordPress, go to Plugins, and look for Bricksforge in the list. If you have shell access, wp plugin list (WP-CLI) shows every plugin and its version in one go.

What to do this week

1. Update Bricksforge to the latest version. At the time of writing that's 4.0.2. If you're stuck on the 3.x line for some reason, 3.1.8.10 is the minimum. 2. If you can't update straight away, Patchstack offers a firewall rule that blocks this attack before it reaches the plugin. Failing that, switch Bricksforge off until you can update. Your forms will stop working for a day or two, but nobody can get in through them.

3. Check whether anyone got in before you updated. Updating closes the hole, but it doesn't remove anything an attacker has already left behind. Patchstack lists what to look for:

• Anything in wp-content/uploads/bricksforge/tmp/.
• PHP files named login_admin_ followed by something, in your uploads folder.
• Any PHP file in your uploads folder at all, including odd endings like .phtml, .php5 or .pht. Your uploads folder should hold images and documents, not code.

On the server, something like this lists them:

find wp-content/uploads -iname "*.ph*"

Patchstack says most attack attempts went to /wp-json/bricksforge/v1/form_submit, so check your web server logs for lots of requests there.

4. Renew any API keys stored in Bricksforge. The 4.0.2 changelog recommends renewing any API keys you've saved in the plugin's settings as a precaution. If you've connected it to a mailing list, a CRM or anything else, generate new keys and paste them back in.

5. Stop PHP running in your uploads folder. This is good practice on any WordPress site, whatever plugins it has. If code can't run from the uploads folder, a lot of upload flaws like this one do no harm. On Apache it's a few lines in an .htaccess file, and on nginx it's a short rule in the site's settings. If your site is on shared hosting, ask your host whether it's already in place.

If you find something

Don't just delete the file and move on. One planted file is often a sign of others: an extra admin user, a changed theme file, a scheduled task that puts things back. Take a backup of the site as it is (for evidence), change your WordPress, hosting and database passwords, and get someone to go through it properly.

The bigger point

Plenty of WordPress sites end up with more plugins than anyone remembers installing. Ten minutes a month on the Plugins page would catch most of this. If that's ten minutes nobody in your business is going to find, that's what a support retainer is for. I keep your servers and sites updated, watch for problems, and tell you about them in plain English.