Patchstack disclosed a maximum-severity flaw in Bricksforge, a widely used add-on for the Bricks WordPress page builder, on 8 October 2026. Attackers didn’t wait to see if anyone would patch it: exploitation attempts started within hours, at 21:47 UTC that same day. The bug, CVE-2026-85097, rates a perfect CVSS 10.0 and needs no login at all — an unauthenticated visitor to a vulnerable site can upload a file disguised as a GIF, trick the plugin into treating it as a PHP script, and have the server execute whatever code it contains.
A mismatch between what gets checked and what gets trusted
Bricksforge’s Pro Forms module lets site owners build forms with file upload fields, and it validates uploads the way most developers would expect: check the file’s MIME type before accepting it. That check works — a file has to pass as an image to get through the initial upload step. The vulnerability isn’t in that check. It’s in what happens after.
The exploit runs in three steps. First, the attacker requests a nonce — a
one-time security token WordPress uses to confirm a request is legitimate —
from an endpoint that, per Patchstack’s analysis, hands one out without
requiring authentication: bricksforge_regenerate_nonce. Second, they
upload a polyglot file: something that’s a technically valid GIF image but
also contains embedded PHP code, which passes the MIME check and lands in
the plugin’s temporary upload directory with a .gif extension. Third,
when the form is actually submitted, it sends a temporaryFileUploads
parameter containing two separate pieces of information: a server-side file
path pointing at the already-validated GIF, and a separate URL field that
the attacker sets to end in .php. Bricksforge trusts that second,
attacker-supplied field completely, and writes the first file’s contents —
the embedded PHP — to the location the URL field specifies. The server
then executes it as code, because by that point it’s just a .php file
sitting in a web-accessible directory, with no record of ever having been
treated with suspicion.
The root cause is a validation gap between two different pieces of data that describe the same file: the plugin checked the upload once, at the image stage, and then trusted a later, user-controlled field to redefine what that file actually was. That’s the same category of mistake behind the file-write flaw in Atlassian’s Confluence and Jira products earlier this year — a system that validates an input at one point in a request chain and then implicitly trusts a later, differently-sourced value to still describe the same thing.
A flaw that doesn’t care if the form even has an upload field
The detail that makes this bug worse than a typical file-upload vulnerability is scope. Patchstack’s assessment states the flaw “affects every site with Pro Forms active, including sites whose forms use no upload fields.” Because the vulnerable code path lives in how Bricksforge processes form submissions generally, not specifically in the upload widget a site owner chose to add, simply having the Pro Forms feature turned on is enough exposure — regardless of whether the site’s actual forms were built to accept files from visitors at all. A site owner who never intended to let the public upload anything was still running vulnerable code.
Mass, automated exploitation from the first hours
Patchstack recorded exploitation attempts from 63 unique source IP addresses, in two distinct patterns that point to tooling rather than a single attacker working by hand: one cluster fired 56 nearly identical requests within seconds of each other, while another systematically tried 25 variations of file extensions and encodings against the same upload, consistent with automated scanning across rotating proxies or distributed infrastructure. That’s the pattern this class of bug reliably produces once details are public — not a targeted intrusion against one site, but a sweep that treats every Bricksforge installation on the internet as the same target, the same way the Kestra path-check bypass and other recent automation-platform flaws were scanned and hit at scale within hours of disclosure rather than days.
Successful exploitation hands an attacker arbitrary PHP execution on the underlying server — enough, per standard post-exploitation practice for this bug class, to plant a web shell, modify site content, read database credentials and other sensitive files, and establish access that survives long after the original upload is cleaned up.
The fix shipped the same day it mattered
Bricksforge’s vendor response was fast by plugin-ecosystem standards: version 3.1.8.10, containing the fix, and the newer 4.0.1 release were both available by 8 October, the same day Patchstack’s disclosure and the first exploitation attempts landed. That timing works out well only for site owners who update automatically or were watching closely enough to act within hours — for everyone else, the vulnerable window wasn’t “days until a patch existed,” it was “minutes to hours between disclosure and the first automated scan,” which is a gap no manual patch-management process is built to close.
The lessons that generalise
Validating a file once, early, is not the same as validating it at the point where it gets executed. Bricksforge’s MIME check on upload was real and functional — it just validated the wrong moment in the request. Any system that checks an input once and then trusts a later field to still accurately describe that same input has built the same gap this bug exploited, regardless of what the specific fields are called.
A feature flag can expose a site even when the feature is used exactly as intended. Site owners who enabled Pro Forms for ordinary, upload-free contact forms were still vulnerable, because the flaw lived in form processing generally. “We don’t use the risky part of this feature” is not a safe assumption when the vulnerable code path isn’t scoped to the risky part.
Once a critical, unauthenticated bug in a popular plugin is public, the clock to mass exploitation is measured in hours, not days. Sixty-three source IPs probing within the same day as disclosure is now the normal case for this bug class, not the exception — which means “we’ll patch in our next maintenance window” is a policy that assumes a grace period that, for bugs like this one, no longer exists.
Tech-Bee is an independent technology publication. This piece is drawn from Patchstack’s technical disclosure of CVE-2026-85097, Rapid7’s vulnerability database entry, and SOCRadar’s reporting on the Bricksforge plugin’s exploitation.