Bricksforge Flaw CVE-2026-85097 Is Exploited: Update to 3.1.8.10

Attackers began probing the Bricksforge plugin for WordPress on 7 October 2026, about nine and a half hours before the flaw had a public CVE (Common Vulnerabilities and Exposures) record. The bug, CVE-2026-85097, lets an unauthenticated visitor upload a PHP file and run it. If a site you manage runs Bricksforge 3.1.8.9 or older, the job today is to update it and then check whether anything got in.

Affected and fixed versions

Item	Detail
Product	Bricksforge, an add-on for the Bricks Builder theme (Pro Forms module)
Flaw	Unauthenticated arbitrary file upload (CWE-434), leading to remote code execution
CVE	CVE-2026-85097
Score	CVSS (Common Vulnerability Scoring System) 10.0 per Patchstack; SecurityWeek reported 9.8
Affected	3.1.8.9 and earlier
Fixed	3.1.8.10 on the 3.x line; CybelAngel reports 4.0.1 on the 4.x line, released 8 October
First exploitation seen	7 October 2026, 21:47 UTC (Patchstack)
Advisory published	8 October 2026
Install base	About 6,000 sites (Patchstack plugin listing, unlabeled figure; CybelAngel gives the same number)

Is it on CISA's list? Not yet

As of 15 October 2026, CVE-2026-85097 is not in the Known Exploited Vulnerabilities (KEV) catalog run by CISA, the US Cybersecurity and Infrastructure Security Agency. The catalog file I checked was released 15 October at 17:00 UTC and held 1,746 entries. The EPSS (Exploit Prediction Scoring System) value from FIRST for the same date was 0.31%, in the 22nd percentile.

Those two numbers can mislead. Both lag real-world activity, and a niche plugin with a small install base rarely gets a high score even when automated scanners are hitting it. Patchstack's telemetry is the better signal here: 63 distinct source IP addresses were recorded, and one group of 44 sent 56 identical requests within seconds.

For contrast, WordPress core's own remote file inclusion bug, CVE-2026-87902, entered KEV on 25 September and has an EPSS of about 40% on the same date. If you are triaging a WordPress estate, core on 7.1.2 or later comes first, and Bricksforge second.

How the attack works

According to Patchstack's write-up, the plugin checks the file type when a file is first uploaded, then trusts client-supplied metadata when the form is submitted. The url value inside temporaryFileUploads is not validated. That gap lets an attacker steer the plugin into writing uploaded content to a path ending in .php.

The chain, as reported:

1. Ask the unauthenticated AJAX action bricksforge_regenerate_nonce for a valid nonce.
2. Upload a file that is both a valid GIF image and PHP code (a polyglot) to the plugin's temporary directory.
3. Submit a form whose file entry points at the GIF while url ends in a PHP extension.
4. Request the new PHP file over HTTP to run it.

Requests mostly hit /wp-json/bricksforge/v1/form_submit, with one seen on admin-ajax.php using the bricksforge_form_submit action. Attackers varied the extension (.php5, .phtml), the letter case and the URL encoding (%70hp) to get past simple filters. Patchstack and the outlets covering it describe the traffic as automated. None has published confirmed code execution on a victim site, which means exploitation attempts are documented but successful compromise is not.

What to do in the next 24 hours

1. Update. Move to 3.1.8.10 or later, or to the 4.x release if you are on that line. Then confirm the version in the plugins screen, since a queued update is not an applied one.
2. If you cannot update yet, Patchstack says its RapidMitigate virtual patch for this CVE blocks the requests at the traffic layer. Otherwise deactivate the plugin.
3. Hunt for files. Patchstack and SOCRadar both point to /wp-content/uploads/bricksforge/tmp/ and files named login_admin_*.php. These commands are my own constructions from the published indicators, so adjust paths and log locations to your host:

# PHP files that should not exist under uploads, newest first
find /var/www/html/wp-content/uploads -type f -iname "*.php" -printf "%T+ %p\n" | sort -r

# Image-named files left in the plugin's temporary directory
find /var/www/html/wp-content/uploads/bricksforge/tmp -type f \( -iname "*.gif" -o -iname "*.png" \) -ls

# Attack indicators in web server logs
grep -E "bricksforge_regenerate_nonce|bricksforge_form_submit|bricksforge/v1/form_submit|temporaryFileUploads" /var/log/nginx/access.log*

1. Stop PHP running from uploads. Deny PHP execution in wp-content/uploads at the web server. This is good practice regardless and blunts this class of bug.
2. If you find a PHP file, treat the site as compromised. Preserve evidence first, then rotate administrator passwords and database credentials, and check for unknown administrator accounts and scheduled tasks. Updating the plugin does not remove a shell that is already planted.

Your decision before the weekend

Check every WordPress site you build or host for Bricksforge today, including agency-built marketing sites that nobody monitors. If it is present and not updated, patch it now. If you cannot say when the plugin was last updated, run the file hunt above before assuming the site is clean, because the earliest attempts predate the advisory by hours.