Yaamlabs
Vulnerabilities

Bricksforge file upload flaw exploited, CVSS 10

CVE-2026-85097 lets anyone upload PHP to WordPress sites running Bricksforge 3.1.8.9 or older. Attacks began October 7. Fix, workaround and checks.

By Yaali. October 13, 2026, 5 min read, Vulnerabilities, Patching.

Cover on a plain navy gradient with the Yaamlabs logo and the text: Bricksforge file upload flaw exploited, 63 attacking IP addresses in the first report

Bricksforge, a WordPress plugin that adds forms and design features to the Bricks Builder theme, has a critical flaw that lets an unauthenticated visitor upload a PHP file and run it. It is tracked as CVE-2026-85097 and rated CVSS 10.0 by Patchstack (other scorers list 9.8). Every release up to and including 3.1.8.9 is affected, and the fix is 3.1.8.10.

This is already being exploited. Patchstack saw the first attack at 21:47 UTC on October 7 and counted 63 source IP addresses in its data. The attacks are automated and aimed at every site that has the plugin installed, so the question for a site owner is whether the plugin is present and what version it is, not whether the site is interesting.

Attack flow for CVE-2026-85097: the attacker requests a nonce, uploads a GIF that contains PHP, submits a form that points the file at a .php destination, then requests the PHP file to run it

How it works

Bricksforge forms can accept file uploads. The upload happens in two steps: the browser first sends the file, which the plugin checks and parks in a temporary folder, and then the form is submitted with metadata that tells the plugin which temporary file to attach and where to put it.

The check that matters runs only at the first step, when the plugin looks at the file's MIME type (the label that says whether it is an image or something else). At the second step the plugin trusts what the browser says. In the temporaryFileUploads parameter, the url field is not validated, so the submitter decides the destination filename, including its extension.

That is enough for an attack. A polyglot file is a valid image that also contains PHP code, for example a GIF whose comment block holds a script. It passes the MIME check at step one. At step two the attacker submits a form that points to that temporary GIF but names a destination ending in .php. The plugin copies the contents to that name inside the web root, and the web server runs it as PHP the next time anyone requests the file. The result is a web shell: remote code execution as the web server user.

The attacker also needs a nonce, a one-time token WordPress uses to tie a request to a session. Bricksforge exposes an AJAX action called bricksforge_regenerate_nonce that hands one out without a login, so the nonce does not block anything.

What attackers are doing

Patchstack describes automated activity from a mixed set of sources: cloud and hosting ranges, a Tencent address, a Brazilian ISP and a Microsoft Azure address that has more than 1,270 abuse reports. It does not tie the activity to one actor.

In its captured requests, 44 addresses sent 56 requests with identical payloads within seconds of each other, which looks like a shared scanning script. Three other addresses tried 25 variations of the destination extension and encoding against the same temporary file: .php5, .phtml, .pht, .phps, mixed case and URL-encoded forms. That is probing for servers that block plain .php in upload folders but not the alternatives. Patchstack reports that about 95% of captured requests paired an image path with a PHP destination. The six busiest addresses sent about 46% of all requests.

Patchstack lists files named login_admin_*.php, placed in the uploads folder, as a sign of a successful hit. As of October 13 the flaw is not in CISA's Known Exploited Vulnerabilities catalog, and scoring differs by source, so do not use the catalog as your trigger.

Indicators for CVE-2026-85097: request paths, payload pattern and file locations to check, with fixed version 3.1.8.10

What to do

Update Bricksforge to 3.1.8.10 or later. In the WordPress admin go to Plugins > Installed Plugins and read the version under Bricksforge, then update. The Bricksforge changelog is at bricksforge.io/version-changelog/. Auto-updates for plugins are off by default, so do not assume it has happened.

If you cannot update today, deactivate and delete the plugin until you can. Patchstack also offers a virtual patch (its RapidMitigate rule for this CVE) for customers that blocks these requests at the traffic layer. As a web server measure, block PHP execution in the uploads folder. On Apache, a .htaccess file in wp-content/uploads with php_flag engine off or a <FilesMatch "\.(php|php5|phtml|pht|phps)

quot;> deny rule works; on nginx, deny location ~* ^/wp-content/uploads/.*\.(php|php5|phtml|pht|phps)$. This does not fix the upload bug but stops the uploaded file from running.

Check whether you were hit. Sites that ran a vulnerable version since October 7 should be treated as suspect until checked.

  • Search your access logs for POST /wp-json/bricksforge/v1/form_submit and for POST /wp-admin/admin-ajax.php with the action bricksforge_form_submit, especially requests containing temporaryFileUploads. A call to bricksforge_regenerate_nonce followed by an upload and a form submit from the same address is the pattern.
  • Look for PHP files that should not exist: find wp-content/uploads -iname "*.php*" -o -iname "*.phtml" -o -iname "*.pht". No legitimate PHP file belongs in uploads. Check wp-content/uploads/bricksforge/tmp/ and any login_admin_*.php file in a year and month folder such as wp-content/uploads/2026/10/.
  • Search the webroot for PHP files modified since October 7 that are not part of your deployment, and compare core files against a clean copy with wp core verify-checksums.

If you find a dropped file, delete it, then assume the attacker had everything the web server user could read. Rotate the database password in wp-config.php, replace the WordPress keys and salts (which logs everyone out), reset all administrator passwords, and review the Users list for accounts you did not create. Look for a second backdoor in plugins, themes and mu-plugins, because a shell is often used to plant a quieter one before it is found. If the host stores other credentials or API keys in the site configuration, rotate those as well.

The wider lesson

Plugin flaws like this one bypass the checks WordPress core provides, so a core-version check is not enough. Keep an inventory of plugin names and versions across every site you run, and watch a plugin vulnerability feed for those names. The gap between first exploitation (October 7) and a fixed release is what you cannot see from the Plugins page, so blocking PHP execution in uploads on every site is worth doing regardless of this CVE.

Our web application penetration tests probe upload handling of this kind, and our attack surface management work keeps track of the plugin versions running across a fleet of sites. Open the chat and Yaali, our AI agent, will pass your question to an engineer.


Sources: Patchstack, critical unauthenticated arbitrary file upload exploited in Bricksforge, Patchstack vulnerability database, Bricksforge <= 3.1.8.9 arbitrary file upload, INCIBE-CERT, CVE-2026-85097, OpenCVE, CVE-2026-85097, dr.web.de report.

Read next

Back to the blog, or tell us about your system in the chat. Yaali, our AI agent, answers first and brings in an engineer.