Summary
On October 8, 2026, WordPress security firm Patchstack disclosed CVE-2026-85097, a maximum-severity CVSS 10.0 flaw in Bricksforge — a popular add-on for the Bricks visual site builder used by roughly 6,000 websites. An unauthenticated attacker can upload and execute arbitrary PHP code on any vulnerable WordPress site: no login, no account, full site takeover. The vulnerability is a textbook trust-the-client mistake: the plugin validates a file's MIME type when it is first uploaded, but later trusts the file metadata the client's browser sends without re-validating it. And this is not theoretical — Patchstack detected active exploitation starting October 7, 2026 at 21:47 UTC, the day before public disclosure, from 63 unique IP addresses. If your site runs Bricksforge 3.1.8.9 or older, you were in the blast zone before you ever heard the CVE number.
Severity
CVE ID: CVE-2026-85097
Title: Bricksforge for WordPress — unauthenticated arbitrary file upload (CWE-434)
CVSS 3.1: 10.0 (Critical) — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (Wordfence CNA)
Weakness: CWE-434 — unrestricted upload of file with dangerous type
Attack requirements: None — unauthenticated, remote, no user interaction
Exploited in the wild: Yes — Patchstack observed exploitation attempts beginning October 7, 2026, before disclosure
Discoverer/discloser: Patchstack (Wordfence as assigning CNA)
The vector is the maximum a 3.1 score can express: network, low complexity, no privileges, no user interaction, full confidentiality, integrity, and availability impact. There is nothing to debate about the rating — an unauthenticated arbitrary file upload that lands executable PHP on the server is remote code execution by definition, and remote code execution on a CMS is total compromise of the site and everything on the same hosting account.
Affected Versions
The vulnerability affects the Bricksforge plugin for WordPress — the "Swiss Army knife" add-on for the Bricks visual builder, providing advanced forms, animations, scrolling video sequences, dynamic data, and an email designer:
Bricksforge 3.1.8.9 and all earlier versions — vulnerable
Fixed in 3.1.8.10 — the vendor also recommends updating to the latest release (4.0.1)
Patchstack estimates roughly 6,000 websites use Bricksforge. The NVD record (published October 8, 2026) confirms the affected range. Because the exploit chain begins at an unauthenticated AJAX endpoint, every site with the plugin active and reachable on the internet was a target — not just sites using the forms feature.
Technical Analysis
The exploit chain, step by step. Patchstack's writeup reconstructs a clean four-stage attack, and each stage is instructive. Step 1: the attacker requests a valid nonce from the unauthenticated bricksforge_regenerate_nonce AJAX endpoint — the plugin hands out anti-CSRF tokens to strangers, which defeats the purpose of the nonce entirely. Step 2: the attacker uploads a GIF/PHP polyglot — a file that is simultaneously a valid image and valid PHP code. This passes the MIME-type check on first upload, so it lands legitimately in the plugin's temporary upload directory. Step 3: the attacker submits a form where the file path points to that validated image, but the url field inside the temporaryFileUploads parameter ends in a .php extension. The server trusts the client-supplied URL, writes the payload to a .php path — and step 4 is simply requesting that URL, at which point the embedded PHP executes on the server. Game over: web shell, database access, defacement, malware distribution, persistence.
The root cause is the oldest client-trust mistake in web security. Bricksforge validates the file's MIME type at upload time — and then, during form submission, trusts the file metadata the client sends without validating the url field again. Security people have a mantra for this: never trust the client. The browser is the attacker's computer; anything it sends can be forged. A secure design validates at every trust boundary — at upload and at submission, and crucially, it derives the destination filename server-side instead of accepting the client's suggestion. The polyglot trick exists precisely because file-type checks are one layer of a defense that needs several: MIME sniffing catches naive uploads, but a polyglot is a valid image by every check the server runs — the check that mattered was the one on the url field, and it was absent.
Exploitation began before disclosure — and it is automated. Patchstack's telemetry is the most interesting part of this story. Exploitation attempts started October 7 at 21:47:17 UTC, hours before the public advisory. Two clusters stand out: in the first, 44 IPs fired 56 identical-payload requests within seconds; in the second, three IPs tested 25 variations of PHP extensions and encodings (.php5, .php7, .phtml, case changes, URL-encoding) against the same temporary file. Patchstack reads this correctly: automated exploitation over rotating proxies or distributed infrastructure, not a single actor. The extension-variant probing in the second cluster is the signature of an exploit kit testing which payload shapes the target's server will execute — and it means weaponized, mass-scanning exploitation was already underway while most site owners were asleep.
WordPress plugin RCE is a mass-compromise event, not a single-site incident. There is a reason attackers automate WordPress plugin exploits within hours of disclosure: the economics are irresistible. One scanner, thousands of targets, each compromise yielding a web shell that can host phishing pages, mine cryptocurrency, distribute malware, or serve as a pivot into the victim's corporate network. Patchstack notes it is "not uncommon for threat actors to target WordPress vulnerabilities shortly after patches are released" — understatement of the year. The patch release itself is the starting gun: diffing 3.1.8.9 against 3.1.8.10 reveals exactly which parameter the vendor started validating, which is precisely how the pre-disclosure attackers likely found it too. The lesson for site owners is uncomfortable but simple: patching fast is the defense, and anything slower than the exploit kits is a gamble.
Detection: what to look for right now. If Bricksforge was active on your site before you patched, do not just update and move on — patching does not evict an attacker who already got in. Audit requests to /wp-json/bricksforge/v1/form_submit and admin-ajax.php (action bricksforge_form_submit) carrying a temporaryFileUploads parameter — that is the fingerprint of this exploit chain. Inspect /wp-content/uploads/bricksforge/tmp/ for unexpected PHP files or files with PHP-like extensions. Look for newly created administrator accounts, unfamiliar files in the uploads directory, unexpected outbound connections, and modified core files. Treat any site that was exposed before the update as a possible compromise and investigate it — the polyglot upload leaves a trail, but a competent attacker deletes it.
Why This Matters
Unauthenticated RCE in a WordPress plugin is the closest thing the web has to a wormable vulnerability: anyone on the internet can run code on your server, and the scanning starts before the disclosure ends. Bricksforge's 6,000 sites are a small population, which is exactly why this matters — the exploit kits do not care about popularity. They scan the whole internet for the plugin's footprint and compromise whatever they find. If you run WordPress, your plugin inventory is your attack surface, and every plugin with unauthenticated endpoints is a loaded gun pointed at your hosting account.
This also fits this month's recurring theme on this blog — remotely exploitable validation failures in widely deployed web software, alongside the Super Forms WordPress plugin flaw covered earlier this month. Different plugins, same root story: client-supplied input trusted where it should have been verified. WordPress site owners should read these two posts as one lesson with two examples.
Mitigation
Update immediately. Upgrade Bricksforge to 3.1.8.10 or later — the vendor recommends the latest release (4.0.1). This is the only real fix.
Assume compromise if you were exposed. If the plugin was active and reachable before you patched — especially between October 7 and your update — investigate, do not just update. Check /wp-content/uploads/bricksforge/tmp/ for unexpected PHP files, review form-submission and admin-ajax logs for temporaryFileUploads payloads, and look for new admin accounts or unknown files.
Clean thoroughly if compromised. Remove web shells and malicious files, restore from a known-clean backup if you cannot account for every change, rotate all WordPress credentials, salts, database passwords, and hosting credentials — then re-scan.
Harden the WordPress attack surface. Disable direct PHP execution in the uploads directory at the server level (this one control would have neutered this entire exploit chain), keep plugins and themes updated automatically where possible, and remove plugins you do not actively use.
Monitor going forward. A WAF with virtual patching (Patchstack, Wordfence) buys time between disclosure and your update window — but it is a seatbelt, not a substitute for patching. Subscribe to Patchstack or Wordfence intelligence for the plugins you run.
References
Patchstack disclosure — CVE-2026-85097 Bricksforge unauthenticated arbitrary file upload (published October 8, 2026)
The Hacker News — "Attackers Exploit CVSS 10.0 Bricksforge WordPress Flaw" (October 12, 2026)
Bricksforge version changelog — fix in 3.1.8.10
NVD entry for CVE-2026-85097 (CWE-434, Wordfence CNA)
Report by Faizan Akhtar — The Cyber Security Researcher
Top comments (0)