When a WordPress Form Becomes a Remote Code Execution Path

Overview

A critical vulnerability in the Bricksforge WordPress plugin is being actively exploited, allowing unauthenticated attackers to upload and execute malicious PHP code on vulnerable websites. Tracked as CVE-2026-85097, the flaw carries a maximum CVSS score of 10.0 and affects Bricksforge versions up to and including 3.1.8.9. The incident highlights a recurring weakness in web application security: validating data at the point of entry is not enough when subsequent processing trusts information supplied by the client.

The Problem Is More Than File Upload Validation

Bricksforge extends the functionality of the Bricks visual website builder, including its form-handling capabilities. The vulnerability lies in how temporary file uploads are processed during form submission. Although the plugin initially validates the uploaded file’s MIME type, it subsequently trusts client-supplied metadata, including a URL that is not adequately validated. Attackers can exploit this inconsistency to manipulate where file contents are placed, ultimately enabling PHP execution on the server. This is the critical architectural failure. A file that passes an initial validation check is effectively trusted during a later operation, even though the metadata controlling that operation can be manipulated. Validation at one stage does not establish trust across the entire processing lifecycle.

From Unauthenticated Request to Website Compromise

Patchstack observed exploitation attempts beginning on 7 October 2026. Attackers targeted the Bricksforge form-submission endpoints, using crafted upload metadata to attempt to place executable PHP files on vulnerable websites. Successful exploitation can provide remote code execution without requiring an authenticated account. From that position, an attacker could deploy web shells, modify website content, access sensitive information or establish persistent access. The observed activity also showed signs of automation. Researchers identified clusters of requests using repeated payloads, rotating source infrastructure and variations in PHP file extensions. This matters because automated exploitation does not distinguish between a high-traffic commercial website and a smaller business site. Any exposed installation running a vulnerable version may become a target.

The Wider WordPress Persistence Problem

The Bricksforge vulnerability is not occurring in isolation. Separate campaigns have also exploited cross-site scripting flaws in WPC Product Bundles for WooCommerce and Ninja Forms to deliver malicious JavaScript capable of installing backdoor plugins and creating hidden administrator accounts. These are distinct attack paths, but they demonstrate a shared pattern: exploiting an application weakness is often only the first stage. Attackers then attempt to establish access that survives after the original vulnerability is patched. Consequently, updating a plugin does not prove that a website is clean. An attacker who has already installed a web shell, modified files or created unauthorised accounts may retain access after the vulnerable component is upgraded.

Patching Must Be Followed by Verification

Bricksforge users should deploy the latest supported version and verify that the security fix is present. Where immediate updating is not possible, a suitable web-application security mitigation can help reduce exposure while remediation is arranged. Security reviews should examine historical requests to the Bricksforge form-submission endpoints, unexpected PHP files in upload directories, suspicious administrator accounts and unexplained changes to plugins or website files. Where exploitation is suspected, the response should extend beyond updating the plugin. The integrity of the website, its database, administrative accounts and filesystem must be assessed, with a clean rebuild considered if the extent of compromise cannot be established.

Expert in the Cloud Insight

The Bricksforge incident illustrates why application security must be designed around trust boundaries rather than individual validation checks. Uploaded files, client-supplied metadata, temporary storage and server-side execution are separate stages, and each requires its own controls. A successful security check at the front door means little if the application later allows untrusted input to determine what the server executes.