Bricksforge Vulnerability CVE-2026-85097: What Agencies Should Check on Every Client Site

The Bricksforge vulnerability tracked as CVE-2026-85097 lets anyone on the internet upload a PHP file to a WordPress site and run it. It carries a CVSS score of 10.0, the maximum. Patchstack saw attacks start on October 7, 2026, and they are automated.

Bricksforge is a paid add-on for Bricks, the visual site builder theme for WordPress. Every version up to and including 3.1.8.9 is affected. No login is needed. If an agency built client sites on Bricks, some of them likely run Bricksforge, and the attack traffic is already scanning for them.

The short version: update Bricksforge to 4.0.2, the latest release as of October 19, 2026, or at minimum 4.0.1. Then check each site for PHP files in the Bricksforge upload folders and for odd form submissions in the logs. An update closes the hole. It does not remove anything an attacker already left behind.

This post walks through what the flaw is, the version confusion in the coverage, how to find Bricksforge across a client list, and what to check on sites that ran a vulnerable version after October 7. It does not cover how the attack works step by step.

What the Bricksforge vulnerability is

Bricksforge adds features to Bricks: forms, page transitions, an email designer, admin styling and more. Its form feature is called Pro Forms. That is where the problem sits.

According to Patchstack’s write-up, Bricksforge checks a file’s type when it is first uploaded. It does not check it again later, when the form is submitted. An attacker can use that gap to save a file with a .php ending on the server. Once a PHP file sits in a web-reachable folder, the attacker can run it.

Running code on the server is the worst outcome for a website. It can mean a backdoor, a new admin account, spam pages, a card skimmer, or a launch point into other sites on the same hosting account.

The flaw was added to Patchstack’s Bricksforge vulnerability list on October 7, 2026, with affected versions listed as 3.1.8.9 and below. The Hacker News reported it on October 12 and quoted Wordfence’s description of the same flaw.

The attacks seen so far

Patchstack says it first saw exploitation on October 7, 2026, at 21:47 UTC. Its article went up the next day. Here is what it reports:

• 63 source IP addresses. Six of them sent about 46% of the requests.
• Bursts of identical requests. One group of 44 IPs sent 56 requests with the same payload within seconds.
• Testing for filters. Another group tried 25 variations of PHP file endings and encodings against one file.
• No single attacker named. Patchstack says the pattern looks automated, possibly through rotating proxies.

Automated means the attackers exploiting the Bricksforge vulnerability do not pick targets by hand. They scan for any site that answers on the Bricksforge form endpoint. A small nonprofit site gets the same traffic as a large one.

Patchstack does not give a total request count or an estimate of how many sites run Bricksforge. The vendor does not publish an install count either.

Which version fixes the Bricksforge vulnerability

Coverage disagrees here. Patchstack and The Hacker News name 3.1.8.10 as the fix. The Hacker News also tells readers to update to 4.0.1. Both are right, for different reasons.

The vendor’s Bricksforge changelog settles it. Its 4.0.1 entry, dated October 8, 2026, says CVE-2026-85097 "was fixed earlier in 3.1.8.10 and in 4.0.0." The same entry fixes a second, related security issue in the Pro Forms file upload. That one has no CVE number on the changelog. The vendor says it "affects every site with Pro Forms active, including sites whose forms use no upload fields."

So 3.1.8.10 closes the exploited Bricksforge vulnerability. But 4.0.1 is the lowest version that closes both upload problems the vendor has disclosed. Version 4.0.2 adds more fixes, including "Security hardening across the REST endpoints" and "Temporary upload files are cleaned up reliably."

Our advice for agencies: treat 4.0.2 as the target. Treat anything below 4.0.1 as unfinished.

This is also the third Bricksforge security entry in Patchstack’s list since September 2. A privilege escalation flaw and an unauthenticated password reset flaw came first, both in the 3.1.8.x line. Sites that sat on old 3.x versions all autumn carry all three.

How to tell if a client site runs Bricksforge

Start with the sites built on Bricks. Bricksforge is an add-on for Bricks, so the Bricksforge vulnerability can only be on those sites. If your agency tracks themes per site, that list is your first cut.

Then check each site. Any of these works:

1. The Plugins screen. In the WordPress dashboard, go to Plugins and look for Bricksforge. The version shows under the plugin name.
2. The file system. Look for a folder at wp-content/plugins/bricksforge/. If it is there, the plugin is installed, even if it is inactive.
3. WP-CLI. Run wp plugin get bricksforge --field=version. An error means it is not installed under that folder name.
4. Your management tool. Dashboards such as MainWP, ManageWP or a host’s control panel can list plugin versions across sites. Search for Bricksforge.

Do not skip inactive copies. An inactive plugin does not run, but old plugin files left on a server are a common cleanup gap. Delete Bricksforge from any site that no longer uses it.

Updating Bricksforge across many client sites

Bricksforge is a commercial plugin. It is sold through bricksforge.io, not the free WordPress.org directory, so updates depend on each site’s license.

1. Back up first. Take a full backup of files and database. If the site turns out to be compromised, the backup is also evidence. Our guide to [WordPress backup security](/security/wordpress-backup-security-2026/) covers keeping those files safe.
2. Update to 4.0.2. Use the Plugins screen, WP-CLI or your management tool. If no update shows, check the site’s Bricksforge license and the vendor’s customer dashboard.
3. Test the forms. Submit each Pro Forms form once, including any with upload fields. The vendor says forms with upload fields “keep working exactly as before.” Confirm it.
4. Record the version. Log the site, the old version, the new version and the date. You will need it for client reports.

For a large client list, sort the sites first. Put sites with public Pro Forms forms at the top: contact, membership, event and donation forms. Then sites with Pro Forms active but no public forms. Then the rest.

If a site cannot be updated today, Patchstack says its own firewall rule for CVE-2026-85097 blocks the attack. Other web application firewalls may or may not have a rule. Ask your host or firewall vendor directly rather than assuming. Taking the forms offline, or deactivating Bricksforge until the update is in, are blunt but reliable stopgaps.

What to check for compromise after the Bricksforge vulnerability

Any site that ran 3.1.8.9 or older and was reachable after October 7 should be checked. Updating closes the Bricksforge vulnerability. It does not undo a successful attack.

Start with the places Patchstack names:

• The Bricksforge temp folder. Look in wp-content/uploads/bricksforge/tmp/ for any file ending in .php or a variant such as .phtml or .php5.
• This month’s uploads folder. Patchstack lists wp-content/uploads/2026/10/ as a target. It reports PHP files named like login_admin_ followed by more characters.
• Any PHP file in uploads. WordPress media folders should hold images and documents. A PHP file there is a red flag almost every time.

Then check the logs. Ask your host for web server access logs back to at least October 7. Look for:

• POST requests to /wp-json/bricksforge/v1/form_submit, especially bursts from many addresses.
• Requests to /wp-admin/admin-ajax.php with the action bricksforge_form_submit.
• Any request for a PHP file inside wp-content/uploads/. On a clean site there should be none.

Patchstack’s article lists the most active source IP addresses. They are worth a search in your logs, but attacks of this kind rotate addresses, so a clean result on those IPs proves little.

Finally, look beyond the plugin. Check the user list for admin accounts nobody recognizes. Check for plugins nobody installed, including in wp-content/mu-plugins/. Compare core and plugin files against clean copies if your tools allow it.

If you find something

A PHP file in an uploads folder means you should treat the site as compromised. Deleting the one file is not enough. The attacker may have used it to plant others.

A reasonable order: take the site offline or put it in maintenance mode, change all admin, database, hosting and SFTP passwords, and restore from a backup taken before October 7 if you have one. Then apply the update before the site goes back online. Our data breach response plan post covers the client side: who to tell and what to record.

If several client sites share one hosting account, check all of them. Code running on one site can often read files on the others.

Where this fits

This is the third WordPress plugin upload flaw under active attack that we have covered in two months. In September it was Elementor Pro, Super Forms and Wholesale Lead Capture, and before that Gravity Forms. The pattern repeats: a form plugin accepts a file, and a weak check lets a PHP file through.

Two server settings blunt the whole class. First, block PHP from running inside wp-content/uploads/. Most hosts can do this with one rule. Second, keep an inventory of every plugin and version on every client site, so the next advisory takes minutes to triage. Our post on how a PDF upload reaches your CMS server covers a related risk from the same upload forms.

Frequently Asked Questions