Moatline

Bricksforge vulnerability exploited: how to check your site and clean it

Attackers are using a critical flaw in the Bricksforge plugin to upload PHP backdoors to WordPress sites, with no login needed. Updating stops new attacks but does not remove a backdoor that is already there. Here is how to check, in about ten minutes.

By the Moatline team at Next Nova Technologies · Published 15 October 2026 · 6 min read

If your WordPress site uses Bricks Builder with the Bricksforge add-on, check it today. This guide explains the flaw in plain terms, then gives exact steps to find out whether your site was hit.

What happened

  • The flaw: CVE-2026-85097, in the Pro Forms file upload feature of Bricksforge. Anyone, without logging in, can upload a file and turn it into PHP code that runs on your server. Patchstack rates it 10.0 out of 10.
  • Affected versions: Bricksforge 3.1.8.9 and older. Fixed in 3.1.8.10.
  • Attacks started: Patchstack saw the first attempt on 7 October 2026 and published its warning on 8 October. Attacks came from at least 63 IP addresses and look automated, so sites are being hit in bulk rather than picked by hand.
  • How many sites: about 6,000 sites use Bricksforge, according to Patchstack.

Are you affected?

Bricksforge is sold on its own website, not on WordPress.org, so WordPress may not show it as needing an update. Go to Plugins in your dashboard and look at the Bricksforge version number.

  • 3.1.8.10 or later: you are protected from new attacks. If you updated on or after 7 October, still do the check below.
  • 3.1.8.9 or older: update now, then do the check below.

With SSH access, this shows the version:

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

How the attack works

  1. It asks for a form token. The attacker requests a fresh security token from a Bricksforge endpoint that anyone can call.
  2. It uploads a fake image. The file is a real GIF or PNG with PHP code hidden inside, so it passes the image check and lands in wp-content/uploads/bricksforge/tmp/.
  3. It renames the image to PHP. On form submission, Bricksforge trusts a file address sent by the browser. The attacker sets it to end in .php, and the hidden code is saved as a PHP file.
  4. It runs the backdoor. Visiting that file’s address runs the code, which gives the attacker full control: they can add admin users, plant more backdoors, redirect visitors or inject a fake CAPTCHA.

Patchstack saw attackers try many disguises for the file name: .phtml, .php5, .php7, .php8, .pht, .phtm, upper-case versions like .PHP, and encoded names. Some payloads also dropped files called login_admin_*.php into normal upload folders such as wp-content/uploads/2026/10/.

Check your site

1. Look for PHP files in uploads

WordPress itself never puts PHP code in the uploads folder (apart from tiny blank index.php files). With SSH, run this from your site’s main folder. It lists every file in uploads that a server could run as PHP, in any letter case:

find wp-content/uploads -type f -regextype posix-extended \
  -iregex '.*\.(php[0-9]?|pht|phtm|phtml|phar|phps)$' ! -name index.php

Without SSH, open your host’s File Manager and look inside wp-content/uploads/bricksforge/tmp/, then the folders for the current month, for anything that is not an image or document.

Some backup and security plugins keep PHP files in their own uploads folders (for example uploads/updraftplus/ or uploads/wordfence/). Anything else, and especially anything in bricksforge/tmp/, should be treated as a backdoor.

2. Look for new administrator accounts

Under Users, filter by Administrator and check every name you don’t recognise, including ones with a recent “registered” date. With SSH:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

3. Check your logs

Ask your host for the web access logs from 7 October onwards, or open them in cPanel under Raw Access. Search for requests to PHP files inside uploads:

grep -Ei "/wp-content/uploads/.*\.(php[0-9]?|pht|phtml?)" access.log

A request that returned status 200 means the backdoor probably ran. Note the IP address and time: they tell you when the attacker got in.

4. Run a full malware scan

The free Moatline Malware Scanner checks the uploads folder for PHP files, including those renamed to .phtml, .php8 and the other disguises above (from version 1.0.6). It also checks for fake plugins, must-use plugin backdoors, injected database entries and scripts on your live home page, which is where attackers go next.

If you find something

  1. Back up first. Take a full backup of files and database before you delete anything, so you have evidence and a way back.
  2. Update Bricksforge to 3.1.8.10 or later, so the attacker can’t simply upload a new backdoor.
  3. Delete the backdoor files from uploads, and any administrator accounts you don’t recognise.
  4. Look for what the backdoor added. Attackers rarely stop at one file. Check wp-content/mu-plugins, plugins you didn’t install, and recently changed PHP files. Our malware removal guide covers each step.
  5. Change every password (WordPress admins, hosting, database, FTP) and generate new security keys in wp-config.php, which signs everyone out.
  6. Scan again the next day and a few days later to make sure nothing comes back.

Stop it happening again

  • Block PHP in uploads. If PHP can’t run from the uploads folder, an uploaded backdoor is just a dead file. Moatline’s Hardening tab adds this rule for Apache and LiteSpeed servers in one click, and shows the rule to give your host on Nginx.
  • Watch premium plugins. Plugins bought outside WordPress.org often don’t show update notices the same way. Check their versions every month, and remove add-ons you no longer use.
  • Scan regularly, so a backdoor is found in days rather than months.

Indicators

For site owners, hosts and security teams searching logs and files. Source: Patchstack’s analysis of the attacks.

  • Unexpected PHP files in wp-content/uploads/bricksforge/tmp/, often named like img_*.php, or login_admin_*.php in other uploads folders.
  • POST requests to /wp-json/bricksforge/v1/form_submit or /wp-admin/admin-ajax.php with action=bricksforge_form_submit, carrying a temporaryFileUploads parameter whose file is an image but whose URL ends in a PHP extension.
  • Calls to the bricksforge_regenerate_nonce action followed by an upload and a form submission.
  • The most active source IPs: 177.75.57.20, 23.97.62.146, 84.247.60.125, 38.154.185.97, 150.109.16.166, 153.75.90.146.

Sources: Patchstack’s advisory and attack analysis and SecurityWeek’s report.

Frequently asked questions

Is updating Bricksforge enough?
Updating to 3.1.8.10 or later closes the hole, so new attacks fail. It does nothing about a backdoor uploaded before you updated. If your site ran 3.1.8.9 or older on or after 7 October 2026, check the uploads folder for PHP files as shown in this guide.
I don’t use the Bricksforge Pro Forms. Am I still at risk?
The flaw is in the Pro Forms file upload handling. Reports so far describe attacks against sites with the vulnerable plugin installed, so treat any site running 3.1.8.9 or older as at risk until it is updated and checked.
Can a security plugin firewall stop this?
A firewall rule for this specific attack can block it, and blocking PHP from running in the uploads folder stops an uploaded backdoor from working. Neither removes a backdoor that already exists, so a file check is still needed.
Why would a PHP file end in .phtml or .php8?
Many servers run those extensions as PHP too. Attackers rename their backdoors to them, and to upper-case versions like .PHP, because some security checks only look for files ending in lower-case .php.

Scan your site for free

Moatline checks files, the database and page-builder content. Nothing changes unless you click a button.

Get it free on WordPress.org

More guides

All guides →