Attackers are actively targeting a critical vulnerability in Bricksforge, a WordPress extension for the Bricks site builder, to upload files that the server later executes as PHP. The issue, tracked as CVE-2026-85097, has a CVSS score of 10.0 and can be exploited without an authenticated account. That combination makes exposed sites attractive targets for automated scanning and rapid compromise.

Patchstack observed the first exploitation attempts on October 7, 2026. The vulnerable range includes Bricksforge through version 3.1.8.9, while version 3.1.8.10 contains the cited fix. The vendor has also pointed users to a Pro Forms upload security correction in version 4.0.1, released October 8. Administrators should move to the newest supported release rather than assuming that forms without visible upload fields are safe.

How an image upload becomes executable code

The attack exploits a mismatch between two stages of Bricksforge’s form workflow. During the initial upload, the plugin checks the file’s MIME type, which can make a submitted object appear to be an acceptable GIF or PNG. Later, when the form is completed, Bricksforge processes temporary upload metadata supplied by the visitor but does not adequately validate the destination URL.

An attacker can therefore provide a file that satisfies the image check while also containing PHP code. A crafted form submission associates its temporary server path with a destination whose name ends in an executable PHP extension. When the plugin copies the content to that location, the attacker only needs to request the new file to make the web server run the embedded code.

The publicly reachable bricksforge_regenerate_nonce AJAX action can also provide the request token needed by the attack flow. In practice, this means the protection normally associated with a nonce does not turn the vulnerable form endpoint into an authenticated-only surface.

Exploitation is broad and automated

Nearly all captured attempts targeted /wp-json/bricksforge/v1/form_submit, although activity also reached the corresponding WordPress AJAX action. Most requests used a temporary path ending in .gif or .png and paired it with a PHP destination. Attackers tested extensions such as .php5, .php8 and .phtml, plus mixed capitalization and encoded filenames designed to bypass simplistic filters.

Patchstack recorded activity from 63 source IP addresses. One burst involved 44 addresses sending identical requests within seconds, while another group tried numerous extension and encoding combinations. The distribution does not identify a particular threat actor, but it strongly suggests repeatable tooling rather than isolated manual research.

What a successful intrusion enables

Remote PHP execution gives an intruder a foothold inside the WordPress environment. Depending on hosting permissions and configuration, the attacker may be able to install a web shell, read database credentials, alter pages, create administrator accounts, steal customer information or use the site to redirect visitors. A planted script can also preserve access after the plugin itself has been updated.

That persistence risk is why patching alone is insufficient for systems that were exposed while exploitation was underway. A clean version closes the known entry point, but it does not automatically remove files or accounts created earlier.

Immediate response steps for site owners

• Upgrade Bricksforge to the latest vendor-supported release, with 3.1.8.10 identified as the minimum fixed version for the reported flaw.
• Search access logs for suspicious requests to the REST form submission route, the AJAX form action and the nonce-regeneration endpoint.
• Inspect /wp-content/uploads/bricksforge/tmp/ and other upload folders for PHP, PHTML or unusually named image files.
• Review recently created WordPress administrators, modified themes and plugins, scheduled tasks, database changes and outbound connections.
• If compromise is suspected, rotate WordPress salts, administrator passwords, database credentials and hosting control-panel secrets after containment.

Web application firewall rules may reduce immediate exposure when an update cannot be deployed at once, but they should be treated as a temporary safeguard. Because active exploitation has already been documented, vulnerable or recently patched sites deserve a focused incident review rather than a routine update-and-close response.