Bricksforge Vulnerability: Check Uploads and Recover a Compromised Site

In this guide

If your site used an affected Bricksforge version, update through the trusted vendor channel and review its exposure history. If executable uploads or unauthorized changes are present, treat those findings as a possible compromise requiring investigation. Updating the plugin alone does not remove files an attacker may already have placed.

Patchstack’s October 8, 2026 report identifies CVE-2026-85097 in Bricksforge through 3.1.8.9, with 3.1.8.10 the historical fixed release. It reports exploitation attempts first observed October 7. Those observations concern Patchstack’s telemetry, not proof that your particular site was attacked or compromised.

Establish what was installed and when

Record the Bricksforge version now installed and ask your maintainer for previous deployment or backup records. A patched version today does not reveal whether the site ran an affected build during an earlier period. Note the dates on which the plugin was updated, disabled, removed or restored from a backup.

Identify the exact component: Bricksforge extends Bricks Builder, and this advisory concerns its form-upload handling. Do not mark a site affected solely because the builder’s name appears somewhere in the plugin list. Conversely, a familiar-looking form does not establish which code processes its submissions.

The owner can collect plugin screenshots, affected form addresses and the time suspicious behavior appeared. The developer should verify the installed package, form configuration, deployment history and any exposed copies. Keep that distinction clear when reporting findings to staff.

Preserve evidence before broad cleanup

Ask the host to retain access logs, PHP errors and malware scan history for the relevant period. Export useful records to a protected location before routine retention rotates them away. Record the server timezone so an upload time can be compared sensibly with a request or account change.

• Preserve a protected snapshot of the current files and database, clearly labelled as potentially infected.
• Save suspicious paths, file sizes, hashes if available, and detection messages without executing the files.
• Record unfamiliar administrators, scheduled jobs and changes to form recipients.
• Identify connected services or credentials that could have been reachable from the compromised environment.

Do not browse directly to an unknown PHP file to “see what it does.” Do not share full customer submissions or secrets in a public support thread. Our WordPress security-log guide explains how to retain useful evidence without creating another exposure.

Use the upload findings to choose the response

The report points to Bricksforge temporary uploads and the wider uploads tree as areas relevant to its observed campaign. These are investigation starting points, not a complete list of possible persistence locations. A filename matching an example is not required for compromise, and an unfamiliar filename alone is not a sufficient verdict.

1. Affected version, no suspicious finding yet: patch promptly, preserve available history and assess the exposure window. Report the limits of that review.
2. Suspicious executable upload or changed file: restrict the affected workflow where needed and have a qualified responder inspect it without execution.
3. Confirmed malicious code or unauthorized access: expand the investigation beyond the upload directory and recover from trusted components.
4. Incomplete logs: acknowledge the uncertainty and use file, account and database review to improve confidence; absence of logs is not a clean bill of health.

A firewall event may show a blocked attempt. Correlate it with origin evidence before calling it a successful upload. Our first steps for a suspected WordPress hack cover wider containment priorities if the evidence extends beyond the form.

Repair the entry point and any persistence

The developer or host should install a supported patched Bricksforge release from the vendor, assess unexpected executable files, and compare affected components with trusted packages. Check privileged accounts, must-use plugins, configuration, scheduled work and other sites sharing the account when the evidence warrants it.

Do not restore an entire old backup simply because the homepage looks normal in it. Establish whether that backup predates the incident, patch its vulnerable components before exposure, and preserve newer enquiries, orders and content. The WordPress hardening handbook supports trusted software sources, controlled access and recoverable backups.

Credential rotation should follow the exposure assessment and use a clean administrative environment. Changing the dashboard password while a webshell remains accessible does not resolve the underlying access. Ask the responder to explain what was removed, what was replaced and which uncertainty remains.

Restore enquiries with an acceptance test

Before reopening an affected upload form, submit ordinary permitted files through a controlled test. Confirm the file reaches its intended protected location and the correct team receives the enquiry. Check both a successful submission and a normal rejected upload, such as a file outside the published limits.

Verify the server’s upload execution restrictions with the host without placing a working malicious script on production. Then rescan and review new events during an agreed observation period. Recovery should leave a useful enquiry process as well as a patched plugin.

FAQs

Is Bricksforge 3.1.8.10 still the latest release?

It is the historical fix identified for this advisory. Check the vendor’s current release channel for the supported version to install; do not treat the historical boundary as a permanent latest-version label.

Does a blocked Bricksforge request prove the site was hacked?

No. It shows a request was detected at that layer. Successful compromise requires additional evidence, such as malicious files, unauthorized access or confirmed execution.

Will updating remove a malicious PHP upload?

A plugin update addresses the vulnerable plugin code. An already placed file or other persistence may remain and needs separate investigation and removal.

Can I delete the whole uploads folder?

That can destroy legitimate media and business records. Preserve evidence and have suspicious items assessed so recovery can remove malicious content while retaining necessary files.

Sources

• Patchstack: Bricksforge vulnerability and observed exploitation
• WordPress: hardening and trusted recovery foundations

Prepared for website owners by Nithu / Suthakaran Nithursan. Dated advisory facts link to primary sources. Examples are illustrative and are not client results or guarantees.