A critical Bricksforge WordPress vulnerability, tracked as CVE-2026-85097, is being actively exploited right now. It carries the maximum CVSS severity score of 10.0 because it lets an attacker upload and run PHP code on your server without logging in at all. If you or your agency run Bricksforge alongside the Bricks Builder page builder, the short version is: update to version 3.1.8.10 or later today, then check your site for signs it was already hit.
What Is the Bricksforge Vulnerability (CVE-2026-85097)?
Bricksforge is a commercial add-on for the Bricks Builder page builder, giving designers extra form fields, dynamic content options, animation controls, and file upload widgets inside the Bricks editor. It’s popular with agencies that build client sites on Bricks because it fills in gaps the core builder leaves out.
On October 8, 2026, security firm Patchstack published details of an unauthenticated arbitrary file upload vulnerability in Bricksforge, now tracked as CVE-2026-85097. The flaw sits in how the plugin handles a form submission parameter called temporaryFileUploads. Because the plugin didn’t properly validate that input, an attacker could submit a crafted request and get a PHP file written directly into a folder the web server would then execute.
Why the severity score is the maximum possible
CVSS 10.0 is the highest rating the scoring system can give. It means the attack requires no authentication, no user interaction, no special privileges, and no social engineering. An attacker only needs your site’s URL and a scriptable request. Once the malicious file lands and executes, they have the same level of control over the site as someone with direct server access, which is why researchers describe this as a path to full remote code execution (RCE) rather than just a file upload bug.
The vulnerability affects Bricksforge versions 3.1.8.9 and earlier. The vendor patched it in 3.1.8.10. Some coverage of the issue also references a later 4.0.1 release; if you’re unsure which build you’re on, the safest move is simply to update to whatever the current release is in your WordPress admin or your Bricksforge account dashboard, since any version after 3.1.8.9 closes this specific hole.
Is Your Site Affected by the Bricksforge Flaw?
You’re potentially exposed if all of the following are true:
- You run Bricks Builder as your theme or page builder. Bricksforge only works as an extension to Bricks, so sites that don’t use Bricks at all aren’t affected by this particular flaw.
- Bricksforge is installed and active. Check Plugins → Installed Plugins in your WordPress admin, or ask whoever built the site if you didn’t set it up yourself.
- Your installed version is 3.1.8.9 or older. You can see the active version number right under the plugin name on the Plugins screen.
If you manage multiple client sites built on Bricks, it’s worth running through this checklist for each one rather than assuming an agency-wide update already happened. Patchstack’s telemetry shows this is being probed broadly and automatically, not targeted at specific high-profile sites, which means obscure or low-traffic Bricks sites are just as likely to get hit as busy ones.
How the Exploit Actually Works
Understanding the mechanics helps you judge how urgent this is and what to look for afterward. Here’s the attack in plain terms:
- The attacker sends a form submission request. Bricksforge exposes a REST endpoint (reported as
/wp-json/bricksforge/v1/form_submit) that handles file uploads attached to forms built in the Bricks editor. - The request includes a crafted “url” value inside the temporaryFileUploads parameter. Instead of pointing to a legitimate file, the attacker points it at content they control, including a PHP payload disguised as an upload.
- The plugin writes the file to a predictable upload directory — commonly reported as
/wp-content/uploads/bricksforge/tmp/— without properly checking what kind of file it actually is. - The attacker requests that file directly. Because it’s a real PHP file sitting in a web-accessible folder, the server executes it just like any other script, handing the attacker a foothold with no login required.
Patchstack says it first observed exploitation attempts on October 7, 2026 at 21:47:17 UTC, roughly a day before the public writeup went out. Their telemetry recorded 63 unique source IPs probing for the flaw, with the six most active addresses responsible for about 46% of the traffic. That pattern, rotating across many addresses rather than hammering from one or two, points to automated scanning infrastructure rather than a single manual attacker working through a target list.
How to Fix the Bricksforge Vulnerability Right Now
If you’ve confirmed you’re running an affected version, work through these steps in order.
- Update Bricksforge immediately. Go to Plugins → Installed Plugins and update to 3.1.8.10 or the latest available release. This closes the file upload validation gap and should be your very first move, before anything else on this list.
- Don’t stop at “updated” confirm it. After updating, revisit the Plugins screen and double-check that the version number shown actually changed. A failed or partial update can leave the vulnerable code in place while looking current.
- Apply a virtual patch if you can’t update right away. If you’re on a staging freeze or need sign-off before touching a live client site, Patchstack’s RapidMitigate rule for this CVE blocks exploitation attempts at the web application firewall layer as a stopgap. This buys time; it is not a substitute for the real update.
- Review your server and application logs. Search for requests to the form submission endpoint that include a
temporaryFileUploadsparameter, and for repeated or unusual form submissions around and after October 7, 2026. - Check the upload directory for files that don’t belong. Look inside
/wp-content/uploads/bricksforge/tmp/(and nearby upload folders) for any.phpfile, since legitimate uploads through this feature shouldn’t be executable scripts.
How to Check If You Were Already Compromised
Patching the hole stops new exploitation, but it doesn’t undo anything an attacker already did if they got in before you updated. If your site was running a vulnerable version any time after early October, go a step further.
Signs worth investigating
- Unfamiliar PHP files in uploads folders. Legitimate media uploads are images, PDFs, and similar files — not executable scripts. Any
.phpfile inside an uploads directory deserves a closer look. - New administrator accounts you don’t recognize. A common next step after a successful file upload RCE is creating a rogue admin account, sometimes hidden from the normal Users list view.
- Unexpected files in the must-use plugins directory. The
wp-content/mu-pluginsfolder loads automatically and isn’t listed on the normal Plugins screen, which makes it a favorite hiding spot for persistence code. - Unusual outbound requests or scheduled tasks. Check WP-Cron entries and any monitoring you have for traffic to domains you don’t recognize.
If you find any of this, don’t just delete the suspicious file and move on. Rotate all admin passwords, regenerate secret keys and saltswp-config.php, and consider restoring from a clean backup taken before the exploitation window if one exists. When in doubt, bring in a WordPress security specialist rather than guessing — a partial cleanup that misses a backdoor is worse than knowing you need professional help.
Why This Keeps Happening to WordPress Builder Plugins
Bricksforge is the latest in a steady run of 2026 disclosures involving add-ons for popular page builders and form plugins. File upload and form-handling features are a recurring weak point because they’re built specifically to accept untrusted input from site visitors, which makes a single missed validation check far more dangerous than in code that only runs for logged-in admins.
We’ve covered a related pattern recently in our breakdown of a WordPress hidden admin account campaign that chained stored XSS bugs in two unrelated plugins into the same backdoor toolkit, and in our explainer on the CVE-2026-87902 core vulnerability that was being probed within hours of disclosure. The common thread across all three is speed: once a CVE and its technical details are public, automated scanning against unpatched sites starts almost immediately, often within a day.
The scale backs this up. Wordfence’s own Q2 2026 research, cited alongside the Bricksforge reporting, counted more than 2,073 WordPress-related vulnerabilities published in that quarter alone, with 182 of them rated high-threat — a 15.2% jump from the previous quarter. The same research tied roughly 573,000 WordPress sites to confirmed compromises over the period. A single critical flaw like CVE-2026-85097 doesn’t need a sophisticated attacker behind it to do damage; it just needs to sit unpatched long enough for the existing scanning infrastructure to find it.
If you’re responsible for more than one Bricks-based site, treat this as a fleet problem rather than a one-off fix. Build a simple list of every client site running Bricks Builder, note the Bricksforge version on each, and work through them in order of public traffic and business risk. An agency that patches its biggest client first and forgets a small, rarely-touched site is still exposed — attackers scanning at random don’t care which site matters more to you.
That’s also the strongest argument for staying current on the WordPress core update cycle in general, not just plugin patches. If you haven’t already gone through our WordPress 7.2 update preparation steps, it’s a good companion task to run alongside clearing any Bricksforge exposure, since both come down to the same habit: patch promptly and verify the patch actually took.
What this means if you don’t use Bricksforge
Even if you’ve never heard of Bricks Builder, the practical lesson holds. Any plugin that accepts file uploads from unauthenticated visitors contact forms, image upload fields, resume submission forms, booking systems deserves periodic scrutiny of exactly this kind. When you’re auditing your own plugin list, ask specifically which ones handle uploads from logged-out users, since that’s the category where a single validation mistake has the highest ceiling for damage.
Conclusion
The Bricksforge WordPress vulnerability is about as serious as plugin flaws get: no login required, a maximum severity score, and confirmed active exploitation within hours of disclosure. The fix itself is a simple update to 3.1.8.10 or later, but the real risk is treating the update as the end of the task when attackers had roughly a day’s head start before most site owners even heard about it.
Your next action: Open your WordPress admin right now, check whether Bricksforge is installed and which version is active, update it if you’re on 3.1.8.9 or earlier, and then spend five minutes checking your uploads folder and admin user list for anything that doesn’t belong before you consider the job done.
FAQ
What is CVE-2026-85097?
It’s the vulnerability identifier for a critical unauthenticated arbitrary file upload flaw in the Bricksforge plugin, a commercial add-on for the Bricks Builder page builder. It’s rated CVSS 10.0, the maximum possible severity, because it can lead to full remote code execution without any login.
Which Bricksforge versions are vulnerable?
Version 3.1.8.9 and all earlier releases are affected. The vendor’s patch shipped in 3.1.8.10. If you’re not sure which build is active, update to the current release shown in your WordPress admin or Bricksforge account to be safe.
Is this vulnerability actually being exploited, or just theoretical?
It’s being actively exploited. Patchstack recorded its first exploitation attempt on October 7, 2026, and has since logged dozens of unique source IPs probing for the flaw, consistent with automated mass scanning rather than a one-off test.
I don’t use Bricks Builder — do I need to do anything?
No, this specific vulnerability only affects sites running Bricksforge as an extension to Bricks Builder. If you’re on a different page builder, this CVE doesn’t apply to you directly, though it’s still a good prompt to check whether any of your own plugins handle file uploads from logged-out visitors.
How do I know if my site was already compromised before I updated?
Check your uploads directories (especially /wp-content/uploads/bricksforge/tmp/) for unexpected PHP files, review your admin user list for accounts you don’t recognize, and check wp-content/mu-plugins for files that shouldn’t be there. If you find anything suspicious, rotate credentials and consider restoring from a clean backup rather than attempting a partial manual cleanup.
Leave a response