On this page (7 sections)
A critical flaw in the Bricksforge plugin for WordPress lets an unauthenticated visitor upload a file and run PHP code on the server. It is tracked as CVE-2026-85097 and affects Bricksforge versions up to and including 3.1.8.9. Patchstack reports that the issue is being targeted in the wild, with exploitation attempts first seen on October 7, 2026.
If you run Bricksforge, with or without Bricks Builder, update to 3.1.8.10 now and then check your uploads directory for PHP files that should not be there.
What happened
Bricksforge extends Bricks Builder with features such as advanced forms, animations and dynamic data. The vulnerable code sits in its form handling. According to the GitHub advisory, the plugin does not sufficiently validate the attacker-controlled url field inside the temporaryFileUploads parameter when a form is submitted.
Patchstack published its analysis on October 8, 2026 and says its telemetry shows active exploitation attempts against Bricksforge installations. The fix is listed in the vendor's changelog as version 3.1.8.10.
How the weakness works
This is an unrestricted file upload bug. The plugin checks the type of an uploaded file correctly at the first step, but when the form is later submitted it trusts file details sent back by the browser. In plain terms: the file that was checked and the name it ends up saved under can be made to disagree.
Based on the advisory and Patchstack's write-up, the chain has these stages, described here at a defensive level:
- An unauthenticated AJAX endpoint (bricksforge_regenerate_nonce) hands out a valid nonce, so no login is needed.
- A file that is both a valid image and contains PHP code (a polyglot) passes the MIME check and lands in a temporary upload directory.
- A later form submission supplies a destination URL ending in a PHP extension while the server-side path still points at the checked image.
- Because the plugin trusts that metadata, the content ends up at a PHP location. Requesting it makes the server execute the code.
The result is remote code execution. Patchstack notes that attackers can use this to deploy web shells, change site content, read sensitive data and keep persistent access.
Who is affected
Any WordPress site with Bricksforge 3.1.8.9 or older installed and active is in scope. No account on the site is required, and no user interaction is needed. Agencies that manage many Bricks-based sites should check each one, since the plugin is easy to forget on older client builds.
The research does not state whether a form must be configured with a file upload field for a site to be reachable, so do not assume a site without file fields is safe. Update regardless.
What to do now
0 of 6 done
This WP-CLI command lists the installed version of Bricksforge and whether an update is available. Run it from the WordPress root; look for a version below 3.1.8.10.
wp plugin list --name=bricksforge --fields=name,status,version,update_versionIf the plugin shows an update, this command updates it. It changes plugin files on the live site, so take a backup first.
wp plugin update bricksforgeHow to check for signs of compromise
Patchstack reports that most observed payloads targeted the temporary directory /wp-content/uploads/bricksforge/tmp/, and that some attempts used destination filenames matching login_admin_*.php to place PHP files in the regular uploads directory, for example /wp-content/uploads/2026/10/. PHP files do not belong in uploads, so any hit there deserves attention.
This read-only command lists PHP-type files under the uploads directory. Run it from the WordPress root on the server; a clean site should return nothing, or only files you can explain.
find wp-content/uploads -type f \( -name "*.php" -o -name "*.php5" -o -name "*.php7" -o -name "*.php8" -o -name "*.phtml" \)Patchstack saw attackers trying alternative PHP extensions, which is why the command covers more than .php. This grep searches web server access logs for requests to the form endpoints named in the Patchstack report. Adjust the log path for your server; matches show who called the endpoints and when, not necessarily that an attack succeeded.
grep -E "wp-json/bricksforge/v1/form_submit|bricksforge_form_submit" /var/log/nginx/access.logDetection and hardening afterwards
- Block PHP execution in wp-content/uploads at the web server level. This is a widely used hardening step that limits damage from many upload bugs, but test it first, since a few plugins expect otherwise.
- Monitor file changes in uploads and plugin directories so new PHP files raise an alert.
- Subscribe to vulnerability feeds for the plugins you run, and see known plugin vulnerabilities and our guide on checking whether a plugin is vulnerable.
- A web application firewall can add a layer of protection for known attack patterns, but it does not replace patching. See what a WAF is.
- Run an outside-in check with the free malware scanner, and read what outside-in detection can and cannot see, since it cannot inspect files on your server.
If the site was exposed, follow website hacked: what to do and use the WordPress security checklist to tighten the rebuild.
Timeline
| Date | Event |
|---|---|
| October 7, 2026, 21:47 UTC | First exploitation attempt observed by Patchstack telemetry |
| October 8, 2026 | CVE-2026-85097 published by NVD and added to the GitHub Advisory Database |
| October 8, 2026 | Patchstack publishes its analysis and reports active exploitation; fix listed as 3.1.8.10 |
The GitHub advisory page lists patched versions as unknown and has no package mapped, so rely on the vendor changelog and Patchstack for the fixed version. We have not seen a vendor statement describing the exploitation.
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.