Bricksforge WordPress Plugin Upload Flaw CVE-2026-85097 Drew 63 Attacking IPs in a Day

An unauthenticated visitor to a WordPress site running Bricksforge 3.1.8.9 or earlier can upload a PHP file and have the server run it, and Patchstack says attackers began doing so at 21:47 UTC on Oct. 7. The flaw, CVE-2026-85097, is fixed in Bricksforge 3.1.8.10.

Patchstack recorded 63 unique source IP addresses in its write-up published Oct. 8. Patchstack sells a virtual-patching product, so its telemetry describes its own customer base, not every site running the plugin.

How the upload gets through

The plugin checks a file's MIME type when it is first uploaded, then trusts client-supplied file metadata when a form is submitted, without validating the destination URL, according to Patchstack. An attacker can place a PHP file in a web-accessible location, where the server executes it.

The Spanish national cybersecurity institute INCIBE describes the same chain in its CVE record: fetch a valid nonce from an AJAX endpoint, upload a GIF and PHP polyglot file that passes MIME validation, then submit a form that makes the server treat it as PHP. INCIBE files it under CWE-434, unrestricted upload of a file with a dangerous type.

No account and no user interaction is required. That is the precondition that matters: any site with the plugin active and the form module reachable is in scope.

What Patchstack saw

Most requests hit the REST endpoint /wp-json/bricksforge/v1/form_submit, and one hit admin-ajax.php. About 95 percent of captured requests paired a .gif or .png image path with a PHP-related destination URL. The six most active IPs accounted for about 46 percent of requests.

Two patterns stand out. One cluster of 44 IPs sent 56 identical requests within seconds. A second group of three IPs tested 25 variations of file extension and encoding, a pattern consistent with probing for a filter bypass.

1. Patchstack10 points
2. INCIBE (CVSS 3.1)9.8 points

Source: Patchstack write-up and INCIBE CVE record, accessed 2026-10-13

The score is close to what the preconditions justify. INCIBE's CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) gives 9.8, and Patchstack rates the flaw 10.0. Both reflect the same facts: network reach, no privileges, full compromise of the site.

What is not known

Neither source gives a disclosure date, a vendor notification date or a patch release date. Patchstack's article reports the fixed version number but not when it shipped, so the gap between patch and first attack cannot be measured. It also does not state how many sites run the plugin.

Patchstack says its RapidMitigate rule, which blocks these requests at the traffic layer, was live before the first attack. That is the vendor's claim about its own product.

What to check on your site

Update to Bricksforge 3.1.8.10 or later. Sites that ran 3.1.8.9 or earlier without protection after Oct. 7 should look for requests to the form_submit endpoint containing temporaryFileUploads, for unexpected PHP files in Bricksforge temporary or uploads directories, and for new PHP files receiving HTTP requests.

Indicator	Where to look
Request bodies containing temporaryFileUploads	Web server logs, form_submit endpoint
Unexpected .php files	Bricksforge temp and uploads directories
New PHP files receiving requests	Access logs

The same lesson applies outside WordPress. A Google DevSite researcher earned a $90,000 bounty for code execution through a forged cookie, and the Palo Alto GlobalProtect case shows how long an unpatched hole keeps drawing attackers. A site that finds a stray PHP file should assume the host was fully compromised and restore from a backup that predates Oct. 7.