Bricksforge WordPress Plugin Targeted in Critical Remote Code Execution Attacks

Security researchers identified active exploitation attempts targeting a critical vulnerability in the Bricksforge WordPress plugin. Tracked as CVE-2026-85097, the flaw allows unauthenticated attackers to upload malicious PHP files and potentially execute code on vulnerable servers. Patchstack observed coordinated attacks beginning on 7 October 2026. Affected websites should update Bricksforge and investigate possible backdoor infections.

PUBLISHED: 11 NOV 2026
SEVERITY: CRITICAL
INCIDENT CLASS: EXPLOITATION OBSERVED / UNAUTHENTICATED FILE UPLOAD / REMOTE CODE EXECUTION
STATUS: PUBLISHED

01 / OVERVIEW

Overview

ENVIRONMENT: WordPress websites running Bricksforge plugin versions up to and including 3.1.8.9, particularly installations exposing vulnerable Pro Forms functionality.
INCIDENT CLASS: EXPLOITATION OBSERVED / UNAUTHENTICATED FILE UPLOAD / REMOTE CODE EXECUTION
PROVENANCE: PUBLIC-SOURCE TECHNICAL ANALYSIS

02 / SITUATION

Situation

On 7 October 2026, security researchers observed exploitation attempts targeting a critical arbitrary file upload vulnerability in Bricksforge, a commercial WordPress plugin that extends the functionality of the Bricks visual website builder.

The vulnerability, identified as CVE-2026-85097, affects Bricksforge versions up to and including 3.1.8.9.

It allows unauthenticated attackers to abuse the plugin's Pro Forms file-handling functionality to upload malicious PHP files to vulnerable WordPress installations.

Under suitable server conditions, the uploaded files can be executed remotely, potentially allowing an attacker to gain control of the affected website.

The vulnerability originates from insufficient validation of attacker-controlled file metadata during the form submission process.

Although Bricksforge performs file-type validation during initial uploads, vulnerable versions subsequently trust certain client-supplied values when processing the uploaded files.

An attacker can manipulate these values to cause content initially accepted as an image to be written to a location with a PHP-compatible extension.

Successful exploitation can enable remote code execution with the privileges assigned to the web server process.

ACTIVE EXPLOITATION

On 8 October 2026, Patchstack published research confirming that attackers were targeting the vulnerability.

The company reported that exploitation attempts began on 7 October 2026 at 21:47 UTC.

Its investigation identified 63 unique source IP addresses and several patterns consistent with coordinated automated exploitation.

Some attackers submitted nearly identical payloads from numerous addresses within seconds, while others experimented with different PHP file extensions and encoding techniques.

The observed behaviour indicated attempts to bypass file-upload restrictions and place executable files within WordPress upload directories.

The vulnerability was assessed as Critical, receiving a CVSS v3.1 score of 9.8 from Wordfence and a score of 10.0 from Patchstack.

A security fix was made available in Bricksforge version 3.1.8.10. The vendor subsequently published additional Pro Forms security fixes and hardening improvements.

SECUREMYWP ASSESSMENT

This incident presents a significant threat because successful exploitation does not require an authenticated WordPress account.

An affected installation may be exposed to malicious file uploads that provide attackers with persistent access even after the vulnerable plugin is updated.

However, observed exploitation attempts do not establish that all targeted websites were successfully compromised.

The reviewed public evidence does not establish a confirmed victim count or demonstrate that the same campaign remains active as of 11 November 2026.

This report is a public-source technical analysis based on published vulnerability intelligence, vendor release information and independent security reporting.

It does not represent a SecureMyWP customer incident, direct forensic investigation or independently reproduced exploitation.

03 / WHAT WE FOUND

Findings

1. VULNERABILITY IDENTIFICATION

Affected product: Bricksforge

Software category: WordPress plugin

CVE identifier: CVE-2026-85097

Vulnerability type: Unauthenticated Arbitrary File Upload

Potential consequence: Remote Code Execution

CWE classification: CWE-434 — Unrestricted Upload of File with Dangerous Type

Wordfence CVSS v3.1: 9.8 — Critical

Patchstack CVSS: 10.0 — Critical

Affected versions: Bricksforge 3.1.8.9 and earlier

Initial patched version: 3.1.8.10

First observed exploitation: 7 October 2026, 21:47:17 UTC

Exploitation classification: EXPLOITATION OBSERVED

Technical evidence confidence: HIGH

2. TECHNICAL ROOT CAUSE

The vulnerability exists in the file-handling mechanisms used by Bricksforge Pro Forms.

During the initial upload process, Bricksforge validates the uploaded file's MIME type.

However, affected versions subsequently process client-controlled file metadata without adequately validating the destination URL supplied in the temporaryFileUploads parameter.

This creates an opportunity for attackers to manipulate the relationship between the previously validated file and its eventual destination.

Security researchers documented a technique involving a file that appears to be a valid image but also contains executable PHP code.

A malicious form submission can cause the plugin to write that file's contents to a PHP-compatible destination.

If the hosting environment permits PHP execution at that destination, the attacker may execute arbitrary code.

The vulnerability therefore crosses an important security boundary: information supplied by an unauthenticated visitor is trusted when determining where uploaded content is written.

3. EXPLOITATION PREREQUISITES

Successful exploitation requires a vulnerable Bricksforge installation with the relevant file-handling functionality accessible.

No authenticated WordPress account is required.

An attacker must successfully interact with the affected upload and form-submission functionality.

The hosting environment must also permit execution of the malicious file after it is written to disk for the documented PHP remote code execution consequence to occur.

Environments that prohibit PHP execution inside upload directories may limit the immediate impact.

However, preventing PHP execution is a defence-in-depth measure and should not replace installation of the vendor's security fix.

4. CONFIRMED ATTACK ACTIVITY

Patchstack's research published on 8 October 2026 documented active exploitation attempts.

The first attempts were observed on 7 October 2026.

Researchers identified 63 unique source IP addresses associated with suspicious requests.

One observed cluster involved 44 IP addresses sending 56 similar requests within seconds.

Another involved three IP addresses testing 25 variations of PHP extensions and encoding techniques.

These patterns are consistent with automated exploitation activity.

However, the available evidence does not establish that all the observed addresses were controlled by a single threat actor.

The telemetry also does not establish the number of successful compromises.

5. OBSERVED ATTACK ENDPOINTS

Patchstack identified the following WordPress REST API endpoint as the primary target:

/wp-json/bricksforge/v1/form_submit

Researchers also observed activity involving:

/wp-admin/admin-ajax.php

Relevant WordPress AJAX actions included:

bricksforge_form_submit

bricksforge_regenerate_nonce

A particularly important request parameter was:

temporaryFileUploads

Investigators should pay attention to suspicious combinations of image upload paths and PHP-compatible destination filenames.

Not every request to these endpoints is malicious. Legitimate Pro Forms activity may use the same routes.

6. FILE-SYSTEM INDICATORS

Potentially suspicious file locations include:

/wp-content/uploads/bricksforge/tmp/

/wp-content/uploads/YYYY/MM/

Other publicly accessible WordPress upload directories.

Investigators should examine these locations for unexpected executable files.

Relevant filename extensions include:

.php
.php5
.php7
.php8
.phtml
.pht
.phtm
.phps

Security researchers also observed attempts involving uppercase, mixed-case and encoded extension variations.

One filename pattern identified in the observed attack activity was:

login_admin_*.php

The presence of such a filename deserves investigation, particularly when associated with suspicious form submissions or unexpected PHP execution.

However, a filename alone cannot conclusively establish malicious activity.

7. NETWORK INDICATORS

Patchstack identified the following IP addresses among the most active sources of suspicious requests:

177.75.57.20
23.97.62.146
84.247.60.125
38.154.185.97
150.109.16.166
153.75.90.146

These addresses are historical indicators associated with the October 2026 observations.

They should be used for investigation and correlation rather than treated as permanent or comprehensive indicators of malicious infrastructure.

Attackers may use different addresses, compromised servers, residential connections, proxies or cloud infrastructure.

The absence of traffic from these addresses does not establish that a website was not targeted.

8. POSSIBLE INDICATORS OF SUCCESSFUL COMPROMISE

Website administrators should investigate:

- Unexpected PHP files in upload directories.
- HTTP requests to recently created executable files.
- Unauthorised WordPress administrator accounts.
- Unknown plugins or themes.
- Unexpected modifications to application files.
- Suspicious scheduled tasks.
- Unexplained outbound network connections.
- Newly introduced PHP backdoors.
- Website content changes made without authorisation.
- Unexpected redirects or malicious content injections.

These are potential consequences and general compromise indicators, not confirmation that every behaviour was observed in the documented Bricksforge campaign.

9. POTENTIAL SECURITY IMPACT

Successful remote code execution can allow an attacker to perform actions available to the compromised web server process.

Potential consequences include:

Website file modification.

Installation of persistent PHP backdoors.

Theft of accessible WordPress configuration secrets.

Exposure of database credentials.

Unauthorised modification of website content.

Malicious redirects.

SEO spam injection.

Creation of unauthorised administrator accounts.

Access to sensitive information available within the hosting environment.

Further malicious activity against connected services.

The actual impact depends on server permissions, available application secrets and other environmental security controls.

10. PATCH STATUS

Wordfence and Patchstack identify Bricksforge 3.1.8.10 as the first version addressing CVE-2026-85097.

The vendor's changelog also states that the vulnerability was addressed in the 4.0.0 release line.

On 8 October 2026, Bricksforge released version 4.0.1 with an additional security fix affecting Pro Forms file uploads.

The vendor described that issue as affecting installations with Pro Forms active, including those whose forms did not contain upload fields.

This additional issue should not be confused with the specifically identified CVE-2026-85097 vulnerability.

On 13 October 2026, Bricksforge released version 4.0.2.

That release introduced additional security hardening, improved REST endpoint access controls and protections against PHP execution in the Pro Forms temporary upload directory.

Although 3.1.8.10 addresses CVE-2026-85097, SecureMyWP recommends moving to version 4.0.2 or a newer vendor-supported release where compatible, to receive the additional documented protections.

11. EXPLOITATION CONFIDENCE

Vulnerability existence: CONFIRMED

Unauthenticated exploitation mechanism: CONFIRMED

Remote code execution capability: CONFIRMED UNDER APPLICABLE SERVER CONDITIONS

Real-world exploitation attempts: CONFIRMED

Coordinated automated attack patterns: OBSERVED

Patch availability: CONFIRMED

Verified number of compromised websites: NOT ESTABLISHED

Campaign activity continuing on 11 November 2026: NOT ESTABLISHED

Overall assessment: HIGH-CONFIDENCE, CRITICAL VULNERABILITY WITH OBSERVED EXPLOITATION ATTEMPTS.

04 / WHAT WE DID

Actions taken

This section distinguishes documented vendor and security-researcher responses from recommended website investigation and recovery procedures.

SecureMyWP has not performed customer remediation or independently reproduced exploitation as part of this public-source report.

CONFIRMED SECURITY RESPONSE

1. Vulnerability Disclosure

The vulnerability was publicly documented in October 2026.

Wordfence registered CVE-2026-85097 and classified the issue as a critical unauthenticated arbitrary file upload vulnerability.

2. Active Threat Investigation

Patchstack investigated suspicious requests targeting Bricksforge installations.

The company identified coordinated exploitation attempts beginning on 7 October 2026 and published technical findings on 8 October.

Its investigation documented affected endpoints, malicious request characteristics, suspicious file patterns and associated source addresses.

3. Protective Security Measures

Patchstack reported deploying a mitigation rule designed to block exploitation attempts targeting the vulnerability.

Such protections may reduce exposure but should not be considered a substitute for updating the affected software.

4. Vendor Security Fixes

The Bricksforge vendor made a fix available in version 3.1.8.10.

The vendor also documented the fix in its 4.0.0 release line.

Further Pro Forms security improvements were released in versions 4.0.1 and 4.0.2.

RECOMMENDED WEBSITE INVESTIGATION AND RECOVERY

1. Identify Affected Installations

Determine whether the website uses Bricksforge.

Check its installed version and review available update records.

Establish whether version 3.1.8.9 or earlier was installed during or after the observed exploitation period beginning on 7 October 2026.

2. Preserve Relevant Evidence

Before removing potentially malicious files, preserve available web server logs, suspicious files, file metadata and relevant application records.

Record the dates and times of unusual file uploads or administrator activity.

3. Update the Plugin

Install Bricksforge 4.0.2 or a newer vendor-supported release where compatible.

Confirm that the updated plugin files originate from the official vendor.

Verify that the installation completed successfully.

4. Investigate Upload Directories

Inspect the Bricksforge temporary upload directory and other WordPress upload locations.

Look for unexpected PHP files, suspicious file extensions and recently created executable files.

Investigate filenames matching patterns identified in the published research.

Do not delete unfamiliar files solely because of their names or extensions without examining their purpose and preserving evidence where necessary.

5. Review Web Server Logs

Inspect historical requests targeting the Bricksforge form submission endpoints.

Look for unusual temporaryFileUploads values.

Correlate suspicious requests with newly created files and subsequent HTTP requests attempting to execute them.

Review activity from the source addresses identified in the security research while recognising that other attacker infrastructure may have been used.

6. Investigate WordPress Administrative Access

Review administrator accounts.

Remove accounts confirmed to have been created without authorisation.

Inspect recently installed plugins and themes.

Review unexpected changes to WordPress configuration and application files.

7. Examine Potential Persistence

Look for malicious PHP backdoors, unauthorised scheduled tasks, altered configuration files and unexpected code modifications.

Investigate suspicious processes or files outside the WordPress installation where hosting access permits.

8. Rotate Potentially Exposed Credentials

Where compromise is confirmed or reasonably suspected, rotate relevant WordPress administrator passwords and potentially exposed application credentials.

Review database credentials, hosting access, API keys and other secrets accessible to the compromised process.

Regenerate WordPress authentication keys and salts where appropriate.

9. Perform Incident Recovery

If malicious code execution is established, restore verified clean application files or a trustworthy backup where appropriate.

Remove confirmed backdoors and other attacker-created persistence mechanisms.

Examine the hosting environment for signs of compromise extending beyond WordPress.

10. Verify Remediation

Confirm that the plugin is patched.

Check that unexpected PHP files are absent from upload directories.

Verify WordPress core integrity.

Inspect administrator accounts, scheduled tasks and configuration changes.

Monitor the website for recurring suspicious activity.

11. Escalate Unresolved Compromise

If malicious files return, unauthorised access continues or the full scope of compromise cannot be established, involve the hosting provider or a qualified WordPress incident-response specialist.

Updating the plugin alone does not guarantee that malicious files introduced before the update have been removed.

05 / OUTCOME

Outcome

The Bricksforge vulnerability tracked as CVE-2026-85097 was addressed through vendor security updates.

Bricksforge version 3.1.8.10 was identified as the initial patched release.

The vendor also confirmed that the vulnerability was fixed in its 4.0.0 release line.

Additional Pro Forms security improvements were subsequently released in versions 4.0.1 and 4.0.2.

As of 11 November 2026, version 4.0.2 is the latest release verified in the vendor changelog reviewed for this investigation.

PATCH STATUS

A security fix is available.

Websites running affected versions should update promptly.

Installations that previously used vulnerable releases should also consider investigating historical activity and possible malicious file uploads.

OBSERVED EXPLOITATION

Patchstack confirmed exploitation attempts beginning on 7 October 2026.

The company identified 63 unique source IP addresses and coordinated activity consistent with automated attempts to exploit the vulnerability.

These findings establish genuine attacker activity.

However, the publicly reviewed evidence does not establish how many WordPress websites were successfully compromised.

It also does not establish that exploitation activity continued through 11 November 2026.

POTENTIAL PERSISTENCE

Successful exploitation may allow attackers to introduce executable PHP files and establish unauthorised access.

Such files may remain on a website even after the vulnerable plugin has been updated.

Consequently, patching prevents exploitation through the corrected vulnerability but does not independently establish that a previously compromised website is clean.

Website owners who identify suspicious executable files, unauthorised administrator accounts or other compromise indicators should conduct an appropriate incident investigation and recovery.

SECUREMYWP FINAL ASSESSMENT

Incident classification: EXPLOITATION OBSERVED

Technical severity: CRITICAL

Evidence confidence: HIGH

Patch status: AVAILABLE

Confirmed exploitation attempts: YES

Verified number of successful compromises: NOT ESTABLISHED

Ongoing exploitation as of assessment date: NOT ESTABLISHED

Publication recommendation: APPROVED

The incident demonstrates how insufficient validation of uploaded file metadata can expose WordPress websites to remote code execution and potentially persistent compromise.

This report is based on publicly available security research, vulnerability intelligence and vendor disclosures.

It does not represent a SecureMyWP customer incident, internal laboratory reproduction or independently verified customer recovery outcome.

Assessment date: 11 November 2026.

VERIFIED OUTCOME RECORDED See report text above for the governed outcome statement.

06 / HARDENING

Hardening and prevention

This incident demonstrates the importance of securing WordPress file upload functionality and preventing executable content from being introduced through publicly accessible application endpoints.

RECOMMENDED PREVENTATIVE CONTROLS

1. Maintain Updated Plugins

Regularly review installed WordPress plugins and apply vendor security updates promptly.

Pay particular attention to commercial plugins that distribute updates outside the official WordPress.org plugin repository.

2. Restrict PHP Execution in Upload Directories

Configure the web server to prevent uploaded files from executing as PHP wherever those directories are not intended to contain executable application code.

Apply these restrictions at the web server or hosting configuration level.

3. Use Layered File Upload Validation

Ensure application components validate file types, extensions, destinations and file contents.

Do not assume that a file is safe merely because its MIME type resembles an image.

4. Implement Suitable Firewall Protections

Use reputable firewall controls capable of identifying suspicious file-upload activity.

Understand that firewall protection supplements, but does not replace, software updates.

5. Monitor File Integrity

Establish a baseline of legitimate application files.

Investigate unexpected PHP files, modified plugin components and suspicious changes to WordPress configuration.

6. Review Upload Directories

Periodically inspect directories containing user-submitted files.

Pay attention to unexpected executable files, unusual extensions and recently modified content.

7. Restrict Administrative Privileges

Apply least-privilege access principles.

Remove unused administrator accounts.

Enable multi-factor authentication wherever supported.

8. Maintain Reliable Backups

Create regular backups of WordPress files and databases.

Protect backups from unauthorised modification and test restoration procedures.

9. Retain Security Logs

Maintain sufficient web server and application logs to investigate suspicious requests and file modifications.

Correlate file creation events with incoming requests whenever possible.

10. Harden the Hosting Environment

Apply appropriate file permissions.

Protect database credentials and application secrets.

Monitor unexpected outbound connections and suspicious scheduled tasks.

11. Prepare an Incident Response Procedure

Document how administrators should preserve evidence, investigate compromise, restore clean files and rotate credentials.

Know when to involve the hosting provider or a specialist incident-response service.

SECUREMYWP PREVENTION ASSESSMENT

File-upload vulnerabilities can allow attackers to bypass the normal WordPress authentication process.

Effective protection requires updated software, appropriate server restrictions, monitoring and reliable recovery procedures.

No single defensive measure guarantees complete protection against malicious file uploads or subsequent compromise.

07 / REPORT GOVERNANCE

Report governance

This public report is shown only because it satisfies SecureMyWP's governed publication requirements.

PROVENANCE: PUBLIC-SOURCE TECHNICAL ANALYSIS
PUBLISHED: 11 NOV 2026
PUBLIC STATUS: PUBLISHED