Bricksforge CVE-2026-85097: Check for Arbitrary File Uploads and Backdoors

Bricksforge CVE-2026-85097 is a critical unauthenticated arbitrary file upload vulnerability in the Bricksforge WordPress plugin. Patchstack reported active exploitation on October 7, 2026. Versions through 3.1.8.9 are affected; 3.1.8.10 contains the fix. If the plugin was present while vulnerable, an update closes the entry point but does not tell you whether an attacker already uploaded a file.

This article is a practical triage guide based on Patchstack’s vulnerability analysis. It does not assume every installation was compromised.

Who should act?

Check any WordPress site that ran Bricksforge 3.1.8.9 or earlier, especially sites exposed to the internet before the fixed release. Confirm the version in the plugin screen and the actual installed files. A plugin that is currently updated may still have been vulnerable earlier. Preserve the date and version history from backups, deployment logs, or the host when possible.

Immediate response

1. Take a copy of the current files, database, and web server logs before cleanup.
2. Update Bricksforge to 3.1.8.10 or a later trusted release. If you cannot update promptly, temporarily disable the affected plugin or restrict the attack surface while you arrange a fix.
3. Review uploads and newly changed PHP files around the exposure period. Look beyond the public media library: attackers can use paths and filenames that do not appear as attachments.
4. Inspect administrator accounts, active plugins, must-use plugins, scheduled jobs, and recent configuration changes.

How to inspect suspicious files

Start with wp-content/uploads/ and other writable locations. Compare the filesystem with a known clean backup. Look for executable PHP, unexpected extensions, double extensions, misleading image names, and files with code content despite an image extension. The presence of an unfamiliar file is an investigation lead, not proof by itself. Also review web server rules that could make an uploaded file executable.

Use access logs to correlate suspicious requests with the first appearance of a file. Preserve copies and hashes before removing a confirmed payload. If the attacker reached code execution, checking only one upload directory is insufficient: a second-stage backdoor may be in wp-content/plugins/, mu-plugins/, the active theme, or a writable root file. My guide to file types that hide WordPress malware covers disguised files and why extension checks alone fail.

Check the database and accounts

Review new users, changed roles, and unexpected administrator capabilities. Compare the Users dashboard with a direct database or WP-CLI audit when a plugin might hide accounts. Inspect options and scheduled tasks for loaders that can restore removed files. If the site redirected visitors or displayed spam, search posts, options, widgets, and custom code as well. My WordPress database malware guide explains those persistence areas.

After cleanup

Replace compromised files with verified vendor or repository copies, remove confirmed malicious components, rotate affected credentials, invalidate sessions, and review hosting and deployment access. Recheck logs and file changes over the following days. Do not treat a clean scanner report as a substitute for examining the files and activity tied to this exposure.

A practical investigation sequence

Build a timeline before interpreting individual indicators. Find the earliest date the vulnerable Bricksforge version was installed, the date it was fixed, and the period covered by available access logs. Sort changed files by time, but compare them with deployments, backups, cache regeneration, and legitimate uploads. A timestamp is useful for narrowing a search; it can be altered and is not a verdict.

In web access logs, focus on requests to the affected plugin endpoint and any immediate requests to newly created files. Look for requests that succeed with unexpected status codes or upload-like bodies, then examine the source IP’s adjacent requests. An attacker may use multiple IPs or a proxy, so absence of a single obvious source does not prove safety. Check server error logs too; failed payloads can reveal paths and filenames. If logs have already rotated away, state that limitation in your incident notes instead of declaring the site clean.

List files modified in the relevant interval under uploads, plugins, themes, and the web root. Compare hashes with official plugin packages where possible. Inspect any executable or oddly named file with a text editor in an isolated copy; do not open an unknown URL in the browser to “test” whether a shell works. Search for functions and behaviors in context, such as dynamic code execution, obfuscated strings, remote fetches, and unauthorized user creation. Legitimate plugins can use some of these patterns, so inspect surrounding code and provenance.

What a clean recovery looks like

After removing a confirmed payload, compare the site with a trusted baseline and test normal workflows: Bricks pages, forms, logins, and scheduled jobs. Check whether an unknown account returns, a file reappears, or an outbound request recurs. If it does, there is another persistence point. Review manual malware detection steps for additional file and database locations.

Keep a concise record of affected plugin version, exposure window, suspicious requests, file hashes, users changed, and every remediation action. This helps distinguish an actual compromise from a vulnerable-but-unexploited site and makes subsequent monitoring meaningful. A WAF rule may reduce probing, but it is not a substitute for the vendor fix or for removing a previously uploaded backdoor.

Common questions

Does updating Bricksforge remove a backdoor?

No. Updating fixes the vulnerable plugin code; a separately uploaded payload or user account requires its own investigation and cleanup.

What if I see no suspicious PHP in Media Library?

The Media Library lists attachments, not every filesystem object. Inspect writable directories and logs directly, preferably against a clean baseline.

Should I restore an old backup?

A clean backup can help, but identify the exposure window and fix the vulnerable version first. Recheck users, credentials, and other access paths after restoring.

Source: Patchstack, Bricksforge vulnerability and exploitation report.