CRITICAL: Bricksforge Plugin Flaw Exploited for Unauthenticated RCE

If you run WordPress sites for a living, you already know the drill. Somebody installs a plugin to make the contact form prettier, nobody touches it for six months, and then one morning that plugin turns out to be an unlocked side door into the entire server. This week's version of that story is Bricksforge, and attackers showed up at the door almost as soon as the advisory hit the wire.

Bricksforge is a premium add-on for the Bricks Builder page builder, and it is a favorite among agencies and freelancers who use it to bolt advanced forms, animations, and dynamic content onto Bricks sites. The flaw, tracked as CVE-2026-85097, is an unauthenticated arbitrary file upload that leads straight to remote code execution. Patchstack scores it a perfect CVSS 10.0, while the CNA record maintained by Wordfence lists 9.8 as the base score. Honestly, that distinction is academic. Either number translates to "a stranger on the internet can run code on your web server without logging in," and that is exactly what is happening right now.

Every version of Bricksforge up to and including 3.1.8.9 is vulnerable. The fix shipped in version 3.1.8.10, and the newer 4.x releases carry it as well. Patchstack observed the first exploitation attempts on October 7, 2026, and published its advisory the following day. Wordfence reserved the CVE and published its own advisory, crediting the researcher known as d.v4n_s3c with the discovery. Bricks Builder by itself is not affected. The problem lives entirely in the Bricksforge add-on.

What Went Wrong

At its core, this is a file upload validation failure in the plugin's form handling. Bricksforge forms let site visitors attach files, which is a perfectly normal feature. The trouble is that the plugin did not adequately validate where submitted files would ultimately land or what they would be named, which means an attacker with no account at all could get executable PHP onto the server and then simply request it. Once that happens, the attacker is running code with the same privileges as the web server, and on a typical WordPress host that means access to the database credentials in wp-config.php, every file in the site, and frequently every other site sharing the same account.

Patchstack noted one detail that should worry anyone managing a large WordPress fleet. Exposure depends only on the installed version. A site does not need to have a public form with a file upload field for the attack to work. If the vulnerable plugin is installed and active, the site is in scope. That rules out the comforting assumption that a site is safe because "we never actually used the upload feature."

Exploitation in the Wild

This is not theoretical. Patchstack's telemetry recorded attack traffic from 63 unique source IP addresses in the opening days of the campaign. One cluster of 44 addresses fired off 56 requests carrying identical payloads within seconds of each other, which is the fingerprint of an automated scanner sweeping the internet for anything running the plugin. A second, smaller cluster of three addresses behaved more like a human operator, repeatedly probing the same target with variations to find what would slip past filters. Six addresses accounted for roughly 46 percent of the observed requests, namely 177.75.57[.]20, 23.97.62[.]146, 84.247.60[.]125, 38.154.185[.]97, 150.109.16[.]166, and 153.75.90[.]146.

Patchstack also lists files matching the pattern login_admin_*.php as an indicator of compromise. That naming is no accident. A file that looks vaguely like part of the login process is far less likely to get a second glance from a busy administrator scrolling through a directory listing.

The broader context makes this worse. Wordfence's Q2 2026 report counted 2,073 WordPress vulnerabilities disclosed in a single quarter and roughly 573,000 compromised WordPress sites. The same reporting cycle flagged a separate campaign abusing cross-site scripting bugs in WPC Product Bundles for WooCommerce (CVE-2026-93836, fixed in 8.6.7) and Ninja Forms (CVE-2026-94504, fixed in 3.15.4) to plant hidden administrator accounts and backdoor plugins. Attackers are clearly working the WordPress plugin ecosystem from several angles at once, and a CVSS 10 unauthenticated upload bug is about as close to a gift as they ever get.

What You Should Do Right Now

The first move is the obvious one. Update Bricksforge to 3.1.8.10 or later on every site you manage, then reload the plugins screen and confirm the version number actually changed. Because Bricksforge is a premium plugin, it does not always update through the same channels as free plugins from the WordPress.org repository. Expired licenses quietly block updates, which is how a lot of agency sites end up running two-year-old builds of paid plugins. If a client's license lapsed, now is the time to renew it or pull the plugin entirely.

If you cannot patch immediately, deactivate Bricksforge until you can. Broken forms for an afternoon are a much better conversation than a full incident response engagement. A web application firewall with virtual patching from Patchstack, Wordfence, or your host can buy some time, but treat it as a stopgap rather than a fix.

Here is the part people skip. Updating closes the door, but it does not evict anyone who already came through it. Any file planted before the patch is still sitting on the server after the patch. Every site that ran a vulnerable version after October 7 deserves a compromise check, not just an update.

Start with the filesystem. Look for PHP files anywhere under wp-content/uploads, paying particular attention to wp-content/uploads/bricksforge/tmp/ and to anything matching login_admin_*.php. Legitimate uploads directories should almost never contain executable PHP, so any hit there deserves a close look. Many hosts also let you block PHP execution in the uploads directory entirely through server configuration, which is a hardening step worth applying across the board regardless of this particular bug.

Then move to the logs. Review web server access logs for POST requests to /wp-json/bricksforge/v1/form_submit and to admin-ajax.php with the bricksforge_form_submit action, especially bursts of rapid repeated submissions or requests originating from the IP addresses listed above. Keep in mind that legitimate visitors use those same endpoints, so a match alone proves nothing. What you are hunting for is a suspicious submission followed shortly afterward by a request for a brand new PHP file that has never existed on the site before.

Finally, check the WordPress side. Review the administrator account list for users nobody recognizes, look in the must-use plugins directory for anything you did not install, and compare installed plugins against what the site should be running.

If you do find something, resist the urge to immediately delete it. Copy the suspicious files and relevant logs first so you have evidence to work with. Then rotate every credential that lived on that server, including WordPress administrator passwords, database credentials, hosting control panel and SFTP passwords, and the security keys and salts in wp-config.php. Be careful about restoring from backup as a shortcut, since an older backup may contain both the planted files and the vulnerable plugin version. If you restore, scan the restored copy and reapply the update immediately.

The Bigger Lesson

Bricksforge is just the latest reminder that the real attack surface of a WordPress site is almost never WordPress core. It is the long tail of add-ons, premium extensions, and abandoned plugins that someone installed once and forgot about. Premium plugins in particular tend to fall outside automated update workflows, which means they are often the oldest code running on the site. Asset inventory for WordPress has to include plugin names and exact versions, tracked continuously, because the window between disclosure and exploitation for a bug like this is now measured in hours.

Drop everything and patch this one. Then go check whether you were visited before you did.

MSP Angle

Every agency client running Bricks Builder is a candidate for this conversation, and most of them have no idea which premium add-ons are installed on their sites or whether those licenses are still current. Package a WordPress plugin inventory and compromise assessment as a fixed-fee offering now, then convert it into a recurring managed WordPress security service that includes license tracking, virtual patching, and monthly integrity scanning.