How the Bricksforge vulnerability works
Bricksforge adds extra features to Bricks Builder, including forms that accept file uploads. Patchstack's advisory describes a problem that unfolds in two stages. When a visitor first uploads a file, Bricksforge checks the file type. A genuine image with PHP code hidden inside passes that check, because it really is an image.
The second stage comes when the form is submitted. At that point the plugin trusts the file details sent by the visitor's browser, including the address where the file should be saved. An attacker can change that destination to a PHP filename, and Bricksforge writes the image's contents there. The hidden code then sits in a file the server is willing to run.
PHP is the programming language WordPress runs on, so a PHP file planted this way hands control to whoever placed it. Patchstack lists the possible consequences as web shells (hidden control panels that let an attacker run commands on the server), changed site content, reading sensitive data and persistent access to the site.
No login is required to attempt the attack. Patchstack tracks the flaw as CVE-2026-85097 and gives it a CVSS score of 10.0. CVSS is the common scale for rating how severe a vulnerability is, and 10.0 sits at the very top of it.
Which sites are affected and what Patchstack has seen
The exposure covers WordPress sites running the Bricksforge plugin at version 3.1.8.9 or earlier. Bricksforge is a separate add-on for Bricks Builder, so a site built with Bricks alone falls outside this advisory. Patchstack states no extra condition for exposure, such as a published form or a file upload field, so the installed version alone decides whether you need to update.
Patchstack first saw exploitation attempts in its own telemetry at 21:47 UTC on 7th October 2026 and published the advisory on 8th October 2026. That time marks the earliest activity Patchstack observed, not a confirmed start date for attacks everywhere. The attempts show attackers are actively trying the flaw, yet they do not mean any particular site, including yours, has been broken into.
According to Patchstack, version 3.1.8.10 contains the fix. The vendor's changelog, referenced in Patchstack's advisory, is the place to confirm the security fix for the copy you install.
Upload flaws have featured in our recent coverage of Elementor Pro and the Gravity Forms issue, and the same lesson applies here: patching is only half the job when attackers can leave files behind. Bricksforge still needs its own response, with a different CVE, a different fixed version and its own folders and log entries to check.
Check whether Bricksforge is installed on your site
The quickest check is in the WordPress dashboard. Go to Plugins > Installed Plugins and look for Bricksforge in the list. The version number appears under the plugin's description, and that number decides what you do next.
Inherited sites deserve extra care. When a freelancer or former agency built the site, you may not know every plugin they added, and an add-on can be installed to power a single form or layout feature. Check the plugin list on every site they handed over, not only the one you think uses forms.
Locked out of wp-admin? Ask your host, or open the hosting file manager and look inside wp-content/plugins for a folder named after Bricksforge. Our guide to website file management explains where those folders sit and how to approach file changes safely.
For a quick outside view, our free plugin detector looks for plugin clues in public page assets. A match is a useful hint. An empty result proves nothing, because a plugin does not always leave traces in public pages, so the dashboard or file check remains the real answer.
How to update Bricksforge to 3.1.8.10
With active attempts under way, the update comes first. A careful update routine includes a backup and a staging test, and a recent backup is still worth having, but holding the patch back for a full staging cycle leaves the upload hole open in the meantime. Work through these steps in order.
Bear in mind that any backup, recent or older, can contain files an attacker has already uploaded. Patchstack's 7th October date marks only the earliest activity it observed, so no backup is clean simply because of its date.
- Take or confirm a recent backup of your files and database so you have a recovery point if the update causes a problem.
- Open Plugins > Installed Plugins and note the current Bricksforge version.
- Update Bricksforge to 3.1.8.10 or later using the vendor's own update route.
- Reload the plugins screen and confirm the version now reads 3.1.8.10 or higher.
- Check the vendor's changelog to confirm the release you installed includes the security fix.
- Submit a test entry on each Bricksforge form, including one with a file upload, and check the entry arrives as expected.
If you cannot update straight away
Patchstack states that its RapidMitigate rule blocks these exploitation attempts for the sites it protects. That protection applies only to sites covered by Patchstack, and it does not repair the plugin.
The rule is not a substitute for updating. The vulnerable code stays on the server until Bricksforge is updated, so plan the update for the same day if you can, and run the file and log checks below whether or not a rule was in place.
Updating closes the hole but leaves planted files behind
The update stops new uploads through the flaw. Any file an attacker managed to place before you patched remains on the server, ready to run, which is why the checks after the update matter as much as the update itself.
Start in the folder Patchstack highlights: wp-content/uploads/bricksforge/tmp/. Any PHP file there is a red flag, and files following the pattern login_admin_*.php (login_admin_ followed by other characters) match the indicators Patchstack lists. Patchstack also gives /wp-content/uploads/2026/10/ as an example of where login_admin files were aimed, so widen the search to the rest of wp-content/uploads, which normally holds images, documents and other media rather than PHP code.
Your hosting file manager or an SFTP client will show these folders. Sorting by modification date helps you spot recent changes, but treat dates with caution. Patchstack's 7th October date is only the earliest activity it saw, so an earlier date does not clear a file, and file dates can be altered.
Found something suspicious? Resist deleting it on the spot. Note the file name, location and date, download a copy for the record, and then follow a structured clean-up. Our guide to fixing a hacked site covers documenting symptoms and closing the entry point, while the manual malware removal guide walks through containment and replacing affected files.
Check your server logs for Bricksforge attack requests
Your host's access logs record the requests made to your site, and Patchstack lists several indicators worth searching for. A POST request, mentioned below, is the kind a browser sends when someone submits a form.
Treat a match on the form address with care. Genuine visitors submitting your Bricksforge forms use the same /wp-json/bricksforge/v1/form_submit address, so a bare match proves nothing. The stronger signs are submissions containing temporaryFileUploads and follow-up requests to PHP files that have newly appeared in your uploads folders.
Standard access logs record the address requested rather than the contents of the form, so the temporaryFileUploads detail will only show in more detailed logs from your host, a firewall or a security plugin. Ask your host what they keep if you cannot see it yourself.
Hosts keep logs for different lengths of time, so check how far back yours go. An empty search covers only the period your logs retain, and it cannot rule out activity before then.
- POST requests to /wp-json/bricksforge/v1/form_submit, especially where the submitted data includes temporaryFileUploads.
- Requests to admin-ajax.php using the bricksforge_form_submit action.
- Calls to the bricksforge_regenerate_nonce action.
- Requests to newly created PHP files in uploads folders, such as a login_admin file under /wp-content/uploads/2026/10/.
What your results do and do not prove
A clean set of checks is good news with limits. No suspicious files and no matching log entries mean you found no evidence of abuse. Proof that the site was never targeted is a different matter, because logs can be incomplete, attackers can rename or move files, and a planted file can create further access elsewhere before anyone notices.
Version numbers carry the same caveat. Seeing 3.1.8.10 on the plugins screen confirms the patched release is installed, yet the number says nothing about what happened before the patch went on.
Any suspicious file or matching request changes the picture. Treat the site as potentially compromised and investigate beyond the update: review administrator accounts under Users > All Users, change passwords for WordPress, hosting and database access, and replace the security keys in wp-config.php so existing logins are signed out.
Restoring a backup brings its own catches. An older copy can already contain planted files, and restoring it also brings back the vulnerable Bricksforge version, so the update must be applied again straight afterwards.
Getting help with a Bricksforge update or clean-up
When the update goes through smoothly and your checks come back clear, keep a short note of what you did and when, including how far back your logs reached. If you would rather not touch the plugin yourself, BugShield can carry out the Bricksforge update as a one-off fix at a confirmed price. Where suspicious files, unknown requests or other signs of compromise have turned up, our hacked site clean-up is the better route, because the work goes beyond the update to closing the entry point.
For sites you look after over the long term, the free plugin vulnerability lookup lets you check a plugin slug and installed version against known records. A brand-new CVE such as this one may not be listed yet, and a missing record is never a clean bill of health, so treat the advisory itself as the authority for now.
Sources
Bricksforge vulnerability FAQs
Is every Bricks Builder site affected by the Bricksforge vulnerability?
No. Only sites with the Bricksforge add-on installed at version 3.1.8.9 or earlier are affected. A site built with Bricks Builder alone falls outside this advisory. Patchstack states no further condition, so if Bricksforge 3.1.8.9 or earlier appears under Plugins > Installed Plugins, update it.
Which Bricksforge version should I install?
Install 3.1.8.10 or later, which Patchstack reports contains the fix for CVE-2026-85097. After updating, reload the plugins screen to confirm the version number and check the vendor's changelog for the security fix.
Does updating Bricksforge remove files an attacker already uploaded?
No. The update stops new uploads through the flaw, but any PHP file planted beforehand stays on the server. Check wp-content/uploads/bricksforge/tmp/ and the wider uploads folders, including dated folders such as /wp-content/uploads/2026/10/, for unexpected PHP files, especially ones named like login_admin_*.php.
What should I search for in my server logs?
Look for POST requests to /wp-json/bricksforge/v1/form_submit containing temporaryFileUploads, admin-ajax.php requests using the bricksforge_form_submit action, calls to bricksforge_regenerate_nonce and requests to new PHP files in uploads folders. Genuine form submissions use the same form_submit address, so a match on that address alone proves nothing.
My files and logs look clean. Does that prove my site is safe?
No. A clean result means you found no evidence of abuse, not that the site was never targeted. Your logs only cover the period your host retains, Patchstack's 7th October date is just the earliest activity it observed, and files can be renamed or moved. Keep the plugin updated and treat any later sign of trouble seriously.