CVE-2026-85097: Patch the Bricksforge RCE (2026)

CVE-2026-85097 is as bad as a WordPress plugin flaw gets: an unauthenticated arbitrary file upload in Bricksforge that lets anyone on the internet drop and execute PHP on your server. No login, no user interaction, full site takeover. Patchstack rates it CVSS 10.0, Wordfence rates it 9.8 — the difference is academic. What matters is the date on it: Patchstack caught active exploitation on 7 October 2026 at 21:47 UTC, a full day before the public disclosure. If your site ran a vulnerable version during that window, the attacker may have had a head start of days, not hours. This guide shows you how to check whether you are affected, patch to 4.0.2, and — because the patch only closes the hole — how to check whether someone already walked through it. All facts verified on 19 October 2026.

CVE-2026-85097 at a Glance

Detail	Fact
CVE ID	CVE-2026-85097
Plugin	Bricksforge (add-on for the Bricks visual builder; ~6,000 sites per Patchstack)
Affected	Versions 0 through 3.1.8.9 (everything ≤ 3.1.8.9)
Fixed	3.1.8.10 (first fix); current release is 4.0.2 (13 Oct 2026)
CVSS 3.1	10.0 Critical (Patchstack) / 9.8 Critical (Wordfence, assigning CNA), vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Weakness	CWE-434 — Unrestricted Upload of File with Dangerous Type
Attack requirements	None — unauthenticated, remote, no user interaction
Disclosed	8 October 2026 (NVD published same day)
Exploited in the wild	Yes — since 7 Oct 2026 21:47:17 UTC (63 unique source IPs); not in CISA KEV as of 19 Oct 2026

Credit for the find goes to researcher d.v4n_s3c; Patchstack coordinated the disclosure and Wordfence assigned the CVE.

How the Attack Works (The Published Chain)

You do not need the exploit code to understand this — Patchstack and The Hacker News already published the full chain, and the shape of the bug is what makes it dangerous. It is a classic trust-the-client mistake, split across two stages:

The nonce grab. Bricksforge exposes an unauthenticated AJAX action, bricksforge_regenerate_nonce, that hands any visitor a valid nonce. That nonce is supposed to prove the requester means well; it proves nothing about who they are.
The clean upload. The attacker uploads a GIF/PHP polyglot — a file that is genuinely a valid image but also contains PHP code. Bricksforge correctly checks the MIME type at this stage, and the file passes. It lands in the plugin’s temporary upload directory.
The form submission. When the form is later submitted, Bricksforge accepts the file metadata the client’s browser sends — without re-validating it. Specifically, it does not validate the url field inside the temporaryFileUploads parameter.
The switch. The attacker submits a form where the server-side file path points to the validated image, but the attacker-controlled url ends in a PHP extension. The content gets written to a PHP-executable path — and the server runs it. That is remote code execution.

Attackers tried to dodge extension filters with alternate PHP extensions (.php5, .php7, .phtml), mixed case (.PHP, .pHp), and encoded variants (.%70hp, %2ephp, .%2570%2568%2570). Patchstack saw one cluster try 25 of those variations against a single temp file. The request paths to look for are /wp-json/bricksforge/v1/form_submit and admin-ajax.php with the bricksforge_form_submit action.

Are You Affected? Check Your Version First

Bricksforge is a commercial plugin — updates arrive through your license, not wordpress.org. Checking takes two minutes:

Go to Plugins → Installed Plugins in wp-admin and look at the Bricksforge row. Any version 3.1.8.9 or lower is vulnerable.
On SSH, you can check the same way:
```
wp plugin list | grep -i bricksforge
```
Do not assume you are safe because your forms have no upload fields. Bricksforge’s own 4.0.1 changelog warns that the issue in this area affects every site with Pro Forms active, including sites whose forms use no upload fields.

One honest wrinkle: the vendor changelog has no dated 3.1.8.10 entry at all — the only vendor evidence of it is the 4.0.1 note saying the flaw “was fixed earlier in 3.1.8.10”. If your Plugins screen shows 3.1.8.10 and offers no update, you are patched for this flaw — but updating to 4.0.2 gets you the hardening below, so do it anyway.

Step 1: Patch to 4.0.2 Right Now

The current release, verified on the vendor changelog today, is 4.0.2 (13 Oct 2026). Do not stop at 3.1.8.10 — 4.0.2 contains meaningful extra hardening for this exact attack surface:

4.0.1 fixed the Pro Forms file-upload flaw and a related arbitrary file upload in the same area (CVE-2026-85097).
4.0.2 hardened the REST endpoints (form submissions now require editor-level accounts; clearing the submissions table is admin-only, both adjustable by filter), added per-temp-folder protection so nothing inside the Pro Forms temp folder can be executed, kept an hourly cleanup of that temp folder, filtered stored API keys out of the front end, and fixed 4.0.1 wrongly rejecting roughly 1 in 60 legitimate image uploads.

How to update: your Bricksforge license key must be active. Go to Plugins → Installed Plugins → Bricksforge → Update now, or download the latest zip from your Bricksforge account and upload it manually. If your license lapsed and you cannot update immediately, deactivate Bricksforge until you can — a vulnerable Pro Forms endpoint sitting exposed while you sort out billing is how sites get owned.

Heads-up for headless/API setups: the 4.0.2 change that restricts form submissions to editor-level accounts could affect forms submitted by automation or third-party services. Test your forms after updating.

Step 2: Assume You’ve Been Breached — The 10 Checks

Updating stops new attacks. It does not remove a shell that is already there. Patchstack saw exploitation attempts from 63 unique IPs using mixed infrastructure — datacenters, cloud hosts, VPNs, and one residential outlier — and the attack predates disclosure. If your site ran ≤ 3.1.8.9 any time since early October, work through these checks. They are adapted from Patchstack’s published indicators of compromise and Stefan Pejcic’s post-compromise guide:

1. Hunt PHP where it doesn’t belong

Images, temp folders, and uploads should never contain executable PHP. Search the whole uploads tree:

find wp-content/uploads -type f -iregex '.*\.\(php[0-9]\?\|phtml\|phar\|pht\)$' -ls

2. Inspect the Bricksforge temp folder

ls -la wp-content/uploads/bricksforge/tmp/

Look for anything unexpected — especially files with PHP extensions or odd timestamps. After patching to 4.0.2 this folder has its own anti-execution protection and hourly cleanup, but that protects the future, not the past.

3. Search “images” for PHP code

The polyglot trick hides PHP inside valid images. Sweep the uploads folder:

grep -rlI --include='*.gif' --include='*.jpg' --include='*.png' -e '<?php' -e '<?=' wp-content/uploads

4. Grep the access logs

Look for hits on the exploited endpoints and requests touching PHP files under the temp folder:

grep -E "bricksforge/v1/form_submit|uploads/bricksforge/tmp/.*\.ph" /var/log/nginx/access.log*
grep -E "bricksforge/v1/form_submit|uploads/bricksforge/tmp/.*\.ph" /var/log/apache2/access.log*

5. Grep for the six known attack IPs

Patchstack published the six most active source addresses (about 46% of observed requests). Grep your logs for them — but note they rotate, so a clean result here is not a clean bill of health:

177.75.57.20
23.97.62.146
84.247.60.125
38.154.185.97
150.109.16.166
153.75.90.146

6. Check for rogue administrator accounts

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Any account you don’t recognize — especially ones registered in October — is a red flag. Check when each one was created, not just that it exists.

7. Look for must-use plugins

ls -la wp-content/mu-plugins/

Backdoors love mu-plugins because they load on every request with no Plugins-screen entry. Anything you didn’t put there is suspicious.

8. Find recently modified PHP files

find . -name '*.php' -mtime -14 -not -path './wp-content/cache/*' -ls

9. Verify file integrity

wp core verify-checksums
wp plugin verify-checksums --all

Modified core or plugin files are a classic sign of tampering.

10. If you find anything — restore from a clean backup

Patchstack’s IoC list mentions dropped files with destination names like login_admin_*.php in the regular uploads directory (e.g. /wp-content/uploads/2026/10/). If any of the checks above turn up something: take the site offline if you can, restore from a backup made before early October, force-log-out every user, rotate salts, and rotate every credential that lived on that server. A plugin update is a patch, not a cleanup.

Step 3: Harden wp-content/uploads So This Class of Bug Dies Here

This flaw family — “upload a safe file, get the server to execute it” — dies permanently if your uploads directory cannot execute PHP. This rule neutralizes not just CVE-2026-85097 but the next arbitrary-file-upload bug too:

Apache / LiteSpeed

Create or edit wp-content/uploads/.htaccess:

# Block PHP execution in uploads (CVE-2026-85097 hardening)
<FilesMatch "\.(php[0-9]?|phtml|phar|pht)$">
  Require all denied
</FilesMatch>

Nginx

Add this to your server block (it must sit where it applies to /wp-content/uploads/):

location ~* ^/wp-content/uploads/.*\.(php[0-9]?|phtml|phar|pht)$ {
    deny all;
}

Then request https://yoursite.com/wp-content/uploads/test.php — if you get a 403, it works. (On 4.0.2 the Pro Forms temp folder gets this protection built in; this rule extends the same idea to your whole uploads tree.)

The 60-Second Lesson: Never Trust Client Metadata

The bug pattern behind CVE-2026-85097 is one of the oldest in web security: validate the file on upload, then believe the client about what the file is when it is submitted. Two pieces of state described the same file — the server-side path (checked) and the client-sent URL (unchecked) — and the code trusted the wrong one.

When you review any file-upload code, yours or a plugin’s, ask one question: is anything about the final destination derived from client input? If the answer is yes, the upload check is decoration. Patchstack’s fix story confirms the priority order too — the vendor fixed the flaw, then in 4.0.2 hardened the endpoints and locked down the temp folder itself. Fixes stop the exploit; hardening stops the class.

And a reminder from the timeline: the attack started before disclosure. Patching fast is good. Assuming the patch arrived in time is optimism. For a CVSS 10.0 unauthenticated RCE on ~6,000 sites, check 10 above is the honest default.

CVE-2026-85097: Patch the Bricksforge RCE and Check for a Breach (2026)