A critical, unauthenticated file upload vulnerability in Bricksforge, the widely used add-on for Bricks Builder, is being actively exploited on WordPress sites right now. Patchstack disclosed the flaw, tracked as CVE-2026-85097 with a CVSS score of 10.0, on October 8, 2026, after its telemetry caught exploitation attempts the night before. Every Bricksforge version up to and including 3.1.8.9 is affected, and the bug lets an attacker upload and run a PHP file on your server without ever logging in. A fix landed in version 3.1.8.10.
What the Bricksforge Vulnerability Actually Does
The flaw sits in Bricksforge’s Pro Forms module, and it’s a good example of a bug that only shows up once you follow a file through its whole lifecycle instead of just checking it once. The plugin verifies a file’s MIME type the moment it’s uploaded, which looks fine on paper. The problem is what happens after: when the form is submitted, the plugin trusts the file path and URL the client sends it, rather than re-checking what actually got stored.
According to Patchstack’s advisory, an attacker first grabs a valid nonce from the plugin’s own bricksforge_regenerate_nonce AJAX endpoint, no login required. Next they upload a GIF/PHP polyglot file, which sails through the MIME check and lands in the temporary upload folder. Then they submit the form with a mismatched pair of fields: the file path points at the harmless-looking image, but the URL field ends in .php. Bricksforge writes the content to that PHP location, and from there the embedded code runs whenever it’s requested. The attack hits /wp-json/bricksforge/v1/form_submit and the matching admin-ajax action, and Patchstack says attackers have also tried case changes and double-encoded extensions to slip past filters.
Attackers Were Already in Before the Patch Shipped
What makes this one worth paying attention to is the timing. Patchstack’s monitoring first caught exploitation at 21:47 UTC on October 7, nearly a full day before the public advisory went out on October 8. We’ve seen this same pattern before this month: Ninja Forms and WooCommerce plugins got hit the same way earlier in October. Someone out there is clearly watching commit logs and changelogs for exactly this kind of upload bug.
Patchstack logged attack traffic from 63 unique IP addresses, with six accounts responsible for nearly half of all requests, suggesting a handful of operators running this at scale rather than one lone attacker. One indicator worth searching your logs for specifically: files named login_admin_*.php dropped into upload directories, which is the pattern Patchstack saw attackers planting.
What to Do If You’re Running Bricksforge
- Update Bricksforge to version 3.1.8.10 or later immediately, this isn’t a “get to it this week” patch.
- If you can’t update right away, Patchstack has a RapidMitigate rule for CVE-2026-85097 that blocks the exploit at the traffic layer without touching plugin code.
- Check your uploads directory and server logs for unexpected
.phpfiles, especially anything matchinglogin_admin_*.php, and for requests involvingtemporaryFileUploads. - If you find anything suspicious, treat the whole site as compromised: rotate admin passwords, check for new admin users, and review your file integrity, not just the plugin folder.
This is also a decent reminder that a page builder’s ecosystem of add-ons carries its own risk separate from the builder itself. Bricks Builder core wasn’t touched here, Bricksforge was. If you’re running a stack of third-party extensions on a client site and nobody’s tracking which ones have had a security advisory this year, that’s worth fixing before the next one lands. A WordPress Development audit from ConicPlex is the kind of thing that catches an outdated, high-risk add-on like this before it turns into an incident report.
Compare it to the unauthenticated upload flaw we covered in Ghostscript’s PDF handling earlier this week. Different plugin, different root cause, same lesson: anything that writes a file to disk based on data the visitor controls needs a second, server-side check, not just a client-side MIME sniff.
