Bricksforge WordPress Plugin Vulnerability Exploited in the Wild

A critical arbitrary file upload and remote code execution flaw in the commercial Bricksforge WordPress plugin is actively facing attacks on the public internet, as detailed in SecurityWeek's report based on telemetry from WordPress security provider Patchstack. Tracked under identifier CVE-2026-85097, the weakness carries a near-maximum CVSS severity rating of 9.8. Unauthenticated remote adversaries can abuse the security flaw to transmit malicious scripts directly to underlying web servers, granting them full operational control over exposed websites without presenting administrative credentials.

This report examines the technical mechanics of the bug, the specific software builds affected, and immediate remediation steps for site owners, sysadmins, and web agencies maintaining WordPress properties. Bricksforge operates as a paid add-on for the popular Bricks visual site builder, supplying capabilities like custom forms, interface animations, email template generation, and bespoke administrative screens. Because the exploit pathway allows code execution without an existing user account, any production installation running an unpatched version remains at imminent risk of total compromise.

What broke in Bricksforge WordPress Plugin Vulnerability

The breakdown inside Bricksforge stems from inadequate validation routines that enable unauthenticated remote attackers to send unauthorized files directly into the site environment. Designated as CVE-2026-85097, the vulnerability received a CVSS severity score of 9.8 out of 10, categorizing it as an emergency-level security flaw. Because attackers do not need to authenticate, acquire a subscriber profile, or bypass front-end forms, automated tools can contact the plugin endpoints directly to store arbitrary data files across target servers.

Once an unauthenticated adversary transmits an arbitrary payload, the host can be forced to execute the uploaded script as native application code. Because WordPress plugins operate with the permissions of the web server worker process, executing arbitrary PHP code hands attackers administrative privileges over the database, media assets, configuration keys, and user tables. This capability allows malicious actors to alter website content, install persistent secondary backdoors, export customer records, or redirect regular visitors to external scam destinations.

Who is exposed by Bricksforge WordPress Plugin Vulnerability

The population exposed to CVE-2026-85097 comprises administrators and website owners deploying Bricksforge version 3.1.8.9 or any earlier release. The commercial plugin functions as an extension layer on top of the Bricks visual website builder, equipping designers with administrative tools, custom form handlers, visual animation engines, and email layout modules. Telemetry compiled by Patchstack indicates that roughly 6,000 active websites run the Bricksforge add-on, making every one of those deployments a target unless upgraded.

Patchstack observed real-world exploitation attempts commencing on October 7, revealing that adversaries mobilized automated scans shortly after technical patch details surfaced. The active targeting affects any site with the plugin activated, regardless of whether the site owner uses all built-in features or merely a single form element. Given that the Bricks site builder is frequently chosen by freelancers, boutique agencies, and custom development teams, many unmonitored client installations remain susceptible to automated background probes.

What to do now about Bricksforge WordPress Plugin Vulnerability

Site operators running the Bricksforge extension must immediately update their installations to version 3.1.8.10, which contains the official vendor patch that eliminates the file handling flaw. All earlier versions, culminating in build 3.1.8.9, lack the required checks and must not remain exposed to web traffic. Administrators should access their WordPress management consoles or deploy updates across staging pipelines to ensure the 3.1.8.10 package is active across all managed domains.

In addition to deploying the update, security teams should inspect server access logs, temporary file paths, and upload directories for anomalies dating back to October 7. Because threat actors actively circulated exploits prior to widespread awareness, teams must verify that no unauthorized PHP scripts or unusual encoded files were placed within storage paths. Verifying database users, inspecting recent administrative account additions, and enforcing Web Application Firewall rules to block arbitrary upload interactions provide essential defense depth.

How the Bricksforge WordPress Plugin Vulnerability issue works

The operational profile of the attacks demonstrates systematic scanning driven by distributed infrastructure. Patchstack documented two distinct exploitation clusters in its threat telemetry. In the initial cluster, 44 unique IP addresses transmitted 56 requests featuring identical payloads within seconds of each other. This rapid, synchronized barrage demonstrates coordinated scanning designed to blanket large volumes of potential target addresses before hosting firewalls or site administrators can intervene.

In the second observed cluster, three separate IP addresses tested 25 variations of PHP file extensions and character encodings targeted at the same temporary storage file. Both operational patterns highlight automated exploitation frameworks routing traffic through rotating proxy networks and distributed nodes. Attackers probe how the underlying server processes alternative extensions and temporary storage mechanisms, attempting to identify combinations that bypass local web server execution blocks.

What is still unknown about Bricksforge WordPress Plugin Vulnerability

Telemetry collected during the initial wave does not conclusively identify the individual threat actor or hacking collective responsible for launching the automated campaigns. While the traffic signatures confirm the use of rotating proxies and coordinated infrastructure, Patchstack noted that these technical indicators do not provide enough distinct forensic evidence to establish attribution. It remains undetermined whether multiple unrelated groups began exploiting the vulnerability simultaneously or if a single automated broker conducted the campaign.

Furthermore, public disclosures have not revealed the total count of WordPress properties compromised prior to applying version 3.1.8.10. While automated requests were cataloged across 44 IP addresses in the primary cluster, the exact volume of successful remote code execution payloads across the 6,000 deployed sites has not been released. Security practitioners will need to await future incident response reviews to determine how many unpatched environments suffered secondary backdoor installations.