Bricksforge WordPress Plugin Flaw CVE-2026-85097 Is Under Active Attack — CVSS 10.0 Bug Lets Unauthenticated Attackers Turn Form Uploads Into Remote Code Execution
Bricksforge WordPress Plugin Flaw CVE-2026-85097 Is Under Active Attack — CVSS 10.0 Bug Lets Unauthenticated Attackers Turn Form Uploads Into Remote Code Execution
A maximum-severity flaw in the Bricksforge plugin for WordPress — a "Swiss Army knife" companion to the Bricks visual builder — has come under active exploitation, according to Patchstack. The vulnerability, tracked as CVE-2026-85097 with a CVSS score of 10.0, lets unauthenticated attackers upload and execute arbitrary PHP code on vulnerable sites. It affects Bricksforge versions up to and including 3.1.8.9, and fixes are available in 3.1.8.10 and later. Patchstack, which counts roughly 6,000 active installations of the plugin, first observed exploitation attempts on October 7, 2026 at 21:47 UTC.
The bug is a trust gap between two steps of the same file upload. Bricksforge validates a file's MIME type when it is first uploaded, but when the form is later submitted it trusts the file metadata the client sends. That gives attackers a four-step path to code execution: request a valid nonce from the unauthenticated bricksforge_regenerate_nonce AJAX endpoint; upload a GIF/PHP polyglot that passes the MIME check and lands in the temporary upload directory; submit a form with a crafted temporaryFileUploads parameter whose server-side path points to the validated GIF while the attacker-controlled URL ends in .php; then request the file and the embedded code runs. Wordfence, which published its own advisory, describes the same mechanism.
In the attacks Patchstack observed, nearly all attempts targeted the Bricksforge REST API form endpoint (/wp-json/bricksforge/v1/form_submit) or /wp-admin/admin-ajax.php with the bricksforge_form_submit action. To get around extension filtering, the payloads use alternate PHP extensions (.php5, .php7, .phtml), case manipulation (.PHP, .pHp), and encoded extensions such as .%70hp, %2ephp, and .%2570%2568%2570. The activity came from 63 unique source IPs in two distinct bursts — one where 44 IPs sent 56 requests with identical payloads within seconds, another where three IPs tested 25 extension and encoding variations against the same temporary file — a pattern Patchstack reads as automated exploitation over rotating proxies rather than a single actor. Six IPs account for roughly 46% of all requests, including 177.75.57[.]20, 23.97.62[.]146, and 84.247.60[.]125.
Patchstack has deployed a virtual-patch mitigation rule for its customers. The disclosure comes as threat actors are also exploiting flaws in WPC Product Bundles for WooCommerce and Ninja Forms — a reminder that the WordPress plugin ecosystem's upload paths are under continuous automated assault.
What Should You Do?
- Update immediately — move to Bricksforge 3.1.8.10 or later (the current line is 4.0.1). If you can't, apply a virtual patch or take the forms offline until you can.
- Hunt for compromise — audit logs for requests to the form_submit endpoints carrying a
temporaryFileUploadsparameter, repeated form submissions, and unexpected PHP files under/wp-content/uploads/bricksforge/tmp/. - Re-validate uploads server-side — never trust client-supplied metadata for the file name, path, or type of an already-uploaded object; the validation must apply to the exact bytes and exact final path that get written.
- Block the evasion shapes at the edge — reject alternate and encoded PHP extensions in upload URLs and form parameters after normalization, not before.
The WAF Angle
This flaw is a WAF story in two ways. First, the evasion list is a normalization test: a request path ending in .%70hp or .%2570%2568%2570 only reveals itself as .php after the WAF decodes — single and sometimes double — before matching. A WAF that pattern-matches on raw URLs will wave these uploads through, which is the same encoded-character bypass family we have covered attackers using against production rules. Second, the metadata-trust design flaw — validate a GIF here, write a .php there — is exactly the kind of request asymmetry a good WAF or API gateway can flag: a form submission whose file path and url field disagree on extension deserves to be blocked on sight. Combined with server-side upload validation, that closes the loop the plugin left open — and it's the same WordPress code-execution-by-media theme we saw with the libheif chain.
