Patchstack's monitoring systems picked up exploitation attempts against the Bricksforge WordPress plugin starting Oct. 7 at 21:47 UTC, roughly nine and a half hours before the CVE record was published.
The vulnerability, tracked as CVE-2026-85097, lets unauthenticated attackers upload and execute PHP code on vulnerable WordPress websites. No login or user interaction is required. Patchstack rates it 10.0, while Wordfence assigns a critical CVSS score of 9.8.
The flaw affects Bricksforge versions through 3.1.8.9. Administrators should update immediately and investigate suspicious activity, particularly if their sites were exposed before patching.
What is CVE-2026-85097 in the Bricksforge plugin?
Bricksforge is a commercial add-on for the Bricks Builder WordPress theme, adding forms, animations, and dynamic data features on top of the base builder.
The disclosure timeline moved fast. The researcher credited as d.v4n_s3c reported the vulnerability, with the CVE record published Oct. 8.
According to Patchstack's technical analysis, the flaw stems from insufficient validation of user-controlled file metadata during form submission.
The vulnerability is classified as CWE-434, unrestricted upload of a file with a dangerous type. It affects Bricksforge versions up to and including 3.1.8.9.
A successful attack can allow an intruder to execute arbitrary PHP code, modify website content, access sensitive information, or establish persistent access through a web shell.
The vulnerability is separate from previously reported WordPress Core remote code execution flaws, which involve different affected components and exploitation conditions.
How the Bricksforge vulnerability enables code execution
The root cause is a mismatch between where Bricksforge checks a file's safety and where it later trusts user input.
The plugin validates a file's MIME type when it is initially uploaded but trusts client-supplied metadata when a form is submitted later, including an unvalidated url field inside the temporaryFileUploads parameter.
An attacker can exploit this weakness by first obtaining a valid nonce through an unauthenticated endpoint, then submitting a specially crafted image file containing PHP code.
During a subsequent form submission, the attacker can manipulate the associated metadata so that Bricksforge writes the uploaded content to a location with a PHP filename.
When the resulting file is requested, the server may execute the embedded code.
The vulnerable functionality resides in Bricksforge's Pro Forms component, including code associated with pro-forms/actions/init.php and actions/base.php.
The risk is particularly serious because an attacker does not need administrator credentials or an existing WordPress account.
The attack also resembles other WordPress plugin vulnerabilities that have allowed attackers to place malicious PHP files on servers through insufficient upload validation.
Is CVE-2026-85097 being actively exploited?
Yes. Patchstack documented exploitation attempts beginning Oct. 7, before the CVE record was publicly available.
Its telemetry recorded activity from 63 unique source IP addresses.
One cluster of 44 IPs sent 56 identical requests within seconds. Another cluster used three IPs to test 25 different filename extensions and encoding variations against the same uploaded file.
Nearly all observed attempts targeted the Bricksforge REST API form submission endpoint:
POST /wp-json/bricksforge/v1/form_submit
Attackers tested alternative PHP extensions, mixed-case variations, and encoded filenames, apparently looking for combinations that would bypass file-extension filtering.
Some payloads used filenames matching login_admin_*.php and attempted to place PHP files directly in standard WordPress uploads directories rather than Bricksforge's temporary folder.
The repeated requests and variations indicate automated exploitation attempts. They do not establish whether the activity came from a single threat actor or multiple unrelated attackers.
It's important to distinguish attempted exploitation from a confirmed intrusion. Patchstack's findings document malicious requests and payload structures, but the report does not establish a verified count of successfully compromised websites.
Indicators site administrators should check
Patchstack identified several indicators that may help administrators investigate suspicious activity:
- Requests to
/wp-json/bricksforge/v1/form_submitcontaining atemporaryFileUploadsparameter. - Upload metadata pairing an image file path, such as
.gifor.png, with a PHP-related destination URL. - Repeated form submissions cycling through filename extensions, capitalization, or encoded characters.
- Unexpected PHP files inside
/wp-content/uploads/bricksforge/tmp/or other WordPress uploads directories. - Files named
login_admin_*.phpor requests attempting to execute newly created PHP files.
Administrators should review relevant web server logs, WordPress activity, and filesystem changes dating back to at least Oct. 7.
Patching prevents further exploitation through the vulnerable code, but it does not automatically remove files or accounts created during an earlier compromise.
Organizations investigating suspicious activity can also review established WordPress web shell attack patterns when assessing whether malicious files have already been deployed.
How to patch CVE-2026-85097
The immediate recommendation is to update Bricksforge to the latest supported release.
Patchstack identifies 3.1.8.10 or later as the fix for affected 3.x installations. Bricksforge's official changelog confirms that CVE-2026-85097 was also fixed in version 4.0.0.
The vendor subsequently released 4.0.1 on Oct. 8 to address a related Pro Forms file-upload security issue. That issue affected sites with Pro Forms active, including sites whose forms did not contain upload fields.
Bricksforge 4.0.2, released Oct. 13, is the latest documented release. It introduces additional security hardening across REST endpoints, strengthens protections around temporary uploads, and corrects an image-upload problem introduced in 4.0.1.
Administrators should install the latest supported release through Bricksforge's official distribution or update mechanism and verify the installed version.
Do not assume that an older installation is protected simply because its WordPress dashboard does not display a pending update.
Because Bricksforge is distributed commercially rather than through the WordPress.org plugin directory, administrators should check the plugin's own update mechanism and licensing status.
For sites running Pro Forms, verifying the installed version is particularly important. The vendor confirms that the related issue addressed in 4.0.1 affects Pro Forms installations even when forms have no visible file-upload fields.
If an immediate update is not possible, Patchstack provides a RapidMitigate rule for CVE-2026-85097 that can block known exploitation attempts at the traffic layer.
That mitigation offers temporary protection but does not replace applying the software fix.
Site owners should also inspect upload directories for unexpected PHP files, review administrator accounts for unauthorized changes, and investigate suspicious requests recorded before the patch was installed.
If compromise is suspected, administrators should follow their incident response procedures before returning the affected website to production.
What site owners should do next
The most urgent tasks are identifying affected Bricksforge installations, applying the latest security-fixed release, and checking for evidence of malicious activity.
Patchstack has documented automated exploitation attempts, but those observations do not establish how many websites have been compromised.
Administrators should treat the reported activity as a reason to investigate vulnerable sites rather than wait for a confirmed compromise report.
Bricksforge has clarified its patch history. The vendor confirms that CVE-2026-85097 was fixed in versions 3.1.8.10 and 4.0.0, with additional Pro Forms protections introduced in subsequent releases.
For WordPress sites running Bricksforge, installing the latest supported release and reviewing logs dating back to Oct. 7 should take priority.
Also read: An earlier WordPress privilege-escalation vulnerability also exposed websites to unauthenticated attacks, reinforcing the need to keep third-party plugins updated.