A WordPress plugin called Bricksforge has a flaw that lets anyone on the internet run their own code on your server, with no login, no password, and no social engineering required. Tracked as CVE-2026-85097 and rated the maximum possible CVSS 10.0, the bug has been under active exploitation since October 7, 2026, at 21:47 UTC, according to Patchstack’s own telemetry. If your site uses Bricksforge, the question isn’t whether this is serious. It’s whether you’ve already been hit.
Table of Contents
What Bricksforge Is and Why This Bug Is So Severe
Bricksforge extends Bricks Builder, a visual page-building tool for WordPress, adding advanced forms, animations, custom interactions, and backend customization. The vulnerable code sits in its form-handling logic. Bricksforge checks a file’s MIME type when it’s first uploaded, which sounds like reasonable validation, but when a form is submitted later, the plugin trusts whatever file metadata the client sends with it, including a url field inside a parameter called temporaryFileUploads that it never re-validates.
That gap is the entire vulnerability. An unauthenticated attacker, meaning someone with no account on your site at all, can walk through four steps: request a nonce from an endpoint that doesn’t require login, upload an image file that’s secretly also valid PHP code (a “polyglot” file that passes the MIME check because it genuinely is a valid GIF), submit a form claiming that same file should be saved with a .php extension instead, and let Bricksforge write the attacker’s code into a location the web server will execute on request. From there, an attacker can plant a web shell, modify content, read sensitive data, or set up a backdoor that survives even after the immediate vulnerability is patched.
How Attackers Are Actually Exploiting It Right Now
This isn’t a theoretical flaw sitting in a lab. Patchstack recorded real exploitation attempts from 63 distinct source IP addresses, with the first activity observed on October 7. In 95% of the captured requests, the uploaded file’s path ended in .gif or .png, and most of those paired it with a PHP-related destination URL, exactly the mismatch the vulnerability depends on. Most attempts targeted Bricksforge’s own temporary upload folder, but some went further, aiming for filenames like login_admin_*.php placed directly in the standard WordPress uploads directory, an attempt to blend a malicious file in among legitimate media.
The traffic patterns point to automation, not a single determined hacker. One cluster involved 44 different IP addresses sending 56 nearly identical requests within seconds of each other, the signature of a botnet or distributed scanning tool rather than manual probing. A second cluster showed three IPs systematically trying 25 variations of file extensions and character encodings (.php5, .phtml, mixed-case .PHP, URL-encoded forms) against the same target, the kind of exhaustive bypass testing that happens when an exploit gets automated and shared.
The six most active IPs accounted for roughly 46% of all recorded requests, and they traced to a mix of cloud providers (including Microsoft Azure), hosting companies, and one fixed-line Brazilian ISP connection with almost no history of prior abuse. Patchstack reads the pattern as automated exploitation over rotating proxies or distributed infrastructure, and says it does not by itself point to a single threat actor.
Checking Whether Your Site Was Already Hit
If you run Bricksforge (version 3.1.8.9 or earlier is vulnerable; 3.1.8.10 fixes it), patching stops new attacks, but it doesn’t undo anything that already happened before you updated. A few concrete things to check in your server logs and file system:
- Search access logs for requests to
/wp-json/bricksforge/v1/form_submitthat include atemporaryFileUploadsparameter, particularly any where an image-style path (.gif,.png) appears alongside a PHP-style destination URL in the same request. - Look for calls to the
bricksforge_regenerate_nonceAJAX action immediately followed by an upload and a form submission from the same visitor, the exact sequence the exploit requires. - Scan your uploads directories, including
/wp-content/uploads/bricksforge/tmp/and the standard monthly uploads folders, for PHP files that shouldn’t be there. Files named with alogin_admin_prefix are a specific pattern attackers used in observed attacks, but don’t stop at that pattern alone. - If you find anything suspicious, don’t just delete the file and move on. A web shell that already executed may have created additional backdoors, modified other files, or exfiltrated data before you found it. That calls for a fuller malware scan and, depending on what you find, a password reset across admin accounts and database credentials.
How to Confirm the Patch Actually Took Effect
Updating a plugin from the WordPress admin screen usually works without incident, but after active exploitation it is worth confirming the result rather than assuming it. A few habits close that gap:
- Confirm the installed version. On the Plugins screen, Bricksforge should show version 3.1.8.10 or later; version 3.1.8.9 and earlier are the vulnerable ones.
- If you run multiple sites with the same plugin stack (common for agencies managing several client sites, or a business running separate stores on different domains), don’t assume one successful update covers the rest. Check each site independently; a shared plugin license doesn’t mean a shared update schedule.
- Keep a dated record of when you patched, even something as simple as a note in a password manager or project tracker. If a scan turns up a suspicious file later, knowing precisely when you closed the hole narrows down which log entries are worth examining.
None of this requires special tooling. It’s the kind of five-minute verification that’s easy to skip when you’re confident an update “just worked,” which is exactly when a webshell planted in the narrow window before you patched goes unnoticed the longest.
Why a Form Plugin Became an RCE Vector
The deeper lesson here isn’t really about Bricksforge specifically; it’s about how form-handling and file-upload code tends to accumulate trust it shouldn’t have. Bricksforge did validate the file’s MIME type once, at the moment of upload. The mistake was trusting a separate piece of client-supplied metadata, the destination url, at a later step without re-checking it against anything the server itself had verified. Once an attacker controls what the client sends and the server never cross-checks it against its own earlier validation, the validation step becomes decorative rather than protective.
This pattern shows up repeatedly in WordPress plugin vulnerabilities, particularly in plugins built around forms, file uploads, or dynamic content, because those features inherently need to accept and act on data the visitor provides. A managed WordPress hosting environment with a web application firewall and server-level malware scanning can add a layer of defense against this kind of exploitation attempt, which matters because the gap between a vulnerability existing and a patch landing is where real damage happens, as this campaign demonstrates.
What to Do If You Use Bricks Builder Plugins at All
Even if Bricksforge isn’t installed on your site, this is a useful moment to audit every plugin that handles file uploads or form submissions on your Bricks Builder (or any page builder) site. A few habits make the next version of this problem less likely to catch you by surprise:
- Keep an actual inventory of installed plugins and their versions, not just a vague sense of “everything’s probably updated.” You can’t check an advisory against a version number you don’t know.
- Subscribe to a vulnerability feed for the specific plugins you run, whether that’s Patchstack, Wordfence, or WPScan’s database, rather than relying on hearing about critical flaws secondhand.
- Set uploads directories to not execute PHP, a server-level hardening step (via
.htaccessor equivalent web server configuration) that would have blunted the attempts Patchstack observed, because they relied on the web server executing PHP files placed inside the uploads directory. - Enable automatic updates for plugins where the vendor has a track record of fast, reliable patches, reserving manual review for plugins with a history of updates that break things. A CVSS 10.0 flaw under active exploitation is exactly the scenario automatic updates exist for.
Patchstack says it had a mitigation rule live before the first attack arrived, closing the window between disclosure and exploitation before attackers could use it. That’s the model worth aiming for on your own site too: find out what’s protecting you before the next critical flaw in some plugin you’ve never heard of starts trending.