Bricksforge vulnerability CVE-2026-85097: fix and IoC check

CVE-2026-85097 is a CVSS 10.0 flaw in Bricksforge, the Bricks Builder add-on for WordPress. In versions up to and including 3.1.8.9, Patchstack reports that anyone can upload and run PHP, and that attacks began on 7 October 2026. Update to 3.1.8.10 or later, then check your upload folders for PHP files.

Who is affected by the Bricksforge vulnerability?

Any WordPress site running Bricksforge 3.1.8.9 or older, per Patchstack. Bricksforge is a commercial add-on for the Bricks theme. The vendor's changelog (bricksforge.io) shows a 4.0 branch released on 17 September 2026 and a 4.0.1 release on 8 October and a 4.0.2 release on 13 October. Sites on the 3.x branch are the ones the advisory names.

No login is needed to attack it, so a site with no visitors, a staging copy that is reachable, or a client site you forgot about is in scope. Agencies should list every client site built on Bricks, since the add-on is easy to lose track of; replacing one scanner across 30 client sites is covered on its own page.

Which version should I be on?

This is where the coverage disagrees. Patchstack names 3.1.8.10 as the fixed version. The Hacker News cites 3.1.8.10 in one place and 4.0.1 in another. The vendor's 4.0.1 entry, dated 8 October, says CVE-2026-85097 was fixed earlier in 3.1.8.10 and 4.0.0, and separately announces a security fix to the Pro Forms file upload.

A version number is a claim from the plugin. It is not proof that the files on disk match it. If your host or a manual copy restored an old folder, the dashboard and the code can disagree.

How do I fix it?

How do I fix it if I manage the WordPress site myself?

• Open Plugins and read the Bricksforge version. If it is 3.1.8.9 or older, update now.
• If you cannot update today, Patchstack says its RapidMitigate rule for CVE-2026-85097 blocks the traffic without changing plugin code. That applies only if you are a Patchstack customer. Otherwise, deactivate the plugin until you can update.
• After updating, look in wp-content/uploads/bricksforge/tmp/ and the month folders under wp-content/uploads/ for .php files, and for filenames starting login_admin_. Patchstack lists these as seen in the attacks.
• Search your web server logs from 7 October onward for POST requests to /wp-json/bricksforge/v1/form_submit, the path Patchstack saw most often.
• Check Users for administrators you did not create (how to find a hidden one), and Plugins and mu-plugins for files you did not install.
• If you find a PHP file you cannot explain, treat the site as compromised. Patchstack advises reviewing historical logs and the host for unexpected PHP files, unusual application activity and unauthorized changes on sites that ran a vulnerable version.

What do I do if a host or agency manages the site?

Send them this and keep the reply:

For [your domain], which Bricksforge version is installed on the live site and on any staging copy? Was it 3.1.8.9 or older at any time after 7 October 2026? Please check wp-content/uploads/ for PHP files and the web logs for requests to /wp-json/bricksforge/v1/form_submit, and send me the results with dates.

Am I affected? A three-state self-test

Was Bricksforge exploited, and what should I look for?

Patchstack says it saw exploitation attempts from 7 October 2026 at 21:47 UTC, and counted requests from 63 source addresses. It describes the activity as automated and did not attribute it to one actor. The Hacker News repeated the report on 12 October. At our check on 24 October 2026, we found no primary source naming a confirmed compromise of a specific site.

The absence of a public victim list says nothing about your site. The flaw writes a file to the server. Updating the plugin does not remove that file, and malware that keeps coming back is usually a file like this one left behind. If a PHP file sat in an upload folder, it can still run after the fix.

Look for:

• PHP files, or files with odd extensions such as .phtml, in wp-content/uploads/.
• Files named login_admin_*.php.
• New administrator accounts and new plugins you did not install.
• Requests to the form endpoint with unusual file parameters in your logs.

A PHP file in your uploads folder is a different issue from the PHP core bug behind PHP2Shell, which is a bug in the PHP engine. Patching PHP does not remove a file already planted through a plugin, and updating the plugin does not patch PHP.

What is the bug, without the exploit?

Patchstack says the plugin checks a file's type when it is first uploaded, then trusts details the browser sends back when the form is submitted. A file that passed the first check can end up saved with a PHP name. We do not reproduce the request sequence, and you do not need it to fix a site.

Upload-field bugs are not unique to this plugin: Elementor Pro's upload-field flaw, the form plugin tracker and the other WordPress guides cover the rest. For wider context on why a plugin flaw that runs PHP matters, see why PHP bugs matter and the small business summary.

What could we not confirm?

• The Wordfence advisory page and the NVD record were not readable at our check, so the severity here is Patchstack's score only.
• The vendor changelog has no entries for 3.1.8.9 or 3.1.8.10. The fixed-version statement for those comes from Patchstack and from the 4.0.1 entry.
• Whether Pro Forms must be enabled for a site to be reachable. The sources place the bug in the Pro Forms code but do not say so in plain terms.

Re-check the linked pages before you act. Advisories get updated.