Bricksforge File-Upload Flaw: Update and Check Your Site

If Bricksforge is installed on your WordPress site, record its exact version, preserve a backup or snapshot and any available logs, then check with Bricksforge’s current release guidance which version fixes the file-upload issue for your installation. The version guidance reported by Patchstack and the vendor’s changelog do not, by themselves, establish one definitive fixed version for every installation. Updating is important, but it does not show whether your site was previously compromised or remove anything an attacker may have left behind.

This workflow is for site owners and the developers maintaining their WordPress sites. If you find unexpected files or suspicious requests, treat them as leads for qualified host or incident-response review—not as proof on their own.

What the reports say—and what remains unclear

Patchstack’s October 8, 2026 report says its telemetry first observed exploitation attempts on October 7 at 21:47 UTC. That is Patchstack’s reported observation, not an independently verified first attack or a measure of all activity. Patchstack identifies Bricksforge versions through 3.1.8.9 as affected and 3.1.8.10 as fixed.

The Bricksforge version changelog lists a 4.0.1 release dated October 8, 2026, with a Pro Forms file-upload security fix. The entry says the issue affects sites with Pro Forms active, including forms without upload fields. However, it does not name CVE-2026-85097 or say whether 3.1.8.10 is a fixed release for the same issue. The CVE Program record for CVE-2026-85097 describes versions through 3.1.8.9 as affected and links to the vendor changelog; it does not resolve that release-version question.

So do not assume that the version numbers alone settle which release fixes your installation. Check the current vendor guidance for your installed branch, and ask Bricksforge to confirm the applicable fixed version if the guidance does not clearly address it.

Before you update, preserve what you can

Confirm whether Bricksforge is installed. In WordPress, check the Plugins screen and record the exact installed version. If you manage the site another way, use the relevant plugin inventory. Also note whether Pro Forms is active; the vendor’s 4.0.1 changelog entry describes its stated scope in relation to Pro Forms.
Preserve a restorable snapshot and relevant evidence. Arrange a backup or hosting snapshot, and download available access logs before they rotate or expire. Record when you saved them and where they came from. A backup is a recovery point, not evidence that the site is clean.
Check the vendor’s current release information. Confirm which release addresses the file-upload issue for your installation and branch. If the 3.1.8.10 versus 4.0.1 difference remains unresolved, request clarification from the vendor or your qualified WordPress security provider rather than treating either number as a universal minimum.
Update to a release confirmed to address the issue. Follow your normal deployment process, including testing where appropriate. Then record the version shown as installed. The update closes the version-management task only; it does not establish whether earlier activity occurred or clean up prior changes.
Investigate available evidence. Review the logs and upload locations described below. Keep a record of the sources and date ranges checked, including anything you could not access.

Get cPanel access logs if your host provides them

In cPanel, open Metrics > Raw Access. When the feature is available, it can provide downloadable compressed access logs for a domain. cPanel’s Raw Access documentation says raw logs can be downloaded and viewed as text; Apache or NGINX logs may be available depending on the hosting setup.

The interface may be disabled by your provider. Availability, retention, log format and recorded fields depend on the hosting configuration. Ask your host whether it can check server-side logs if Raw Access is missing or the relevant dates have expired.

Search available logs for these investigation leads, which Patchstack reports from its telemetry:

The REST route /wp-json/bricksforge/v1/form_submit.
The AJAX action bricksforge_form_submit.
temporaryFileUploads references, if that value appears in the logs you have.
Requests whose destination suggests an unexpected PHP or PHP-like file in an uploads location, and requests to newly created PHP files.

These are not an exhaustive signature. Ordinary access logs may show a request path and status but omit request bodies or individual parameters, so the absence of a temporaryFileUploads reference does not show that it was never sent. Log the date range and log type you reviewed, and refer suspicious requests to your host or a qualified incident responder for context.

Inspect Bricksforge temporary uploads and other uploads folders

With your developer or host, review /wp-content/uploads/bricksforge/tmp/, if it exists, and other uploads directories. Look for unexpected PHP-like files and files with recent creation or modification times that do not fit the site’s normal activity. Compare file names and timestamps with your own uploads and known maintenance where possible.

Do not open or execute an unfamiliar file, or delete it casually. Preserve its location and relevant details, such as the file name and timestamps, then ask your host or a qualified incident responder to assess it. An unexpected file is a reason to investigate, not standalone proof of exploitation. Not finding one does not prove the site was not affected.

Hypothetical: the plugin is affected, but logs are gone

Suppose an owner finds Bricksforge 3.1.8.9 installed, but the host no longer retains logs for the relevant period. The owner can still preserve the current site state, check with Bricksforge which release fixes the issue for that installation, update to the confirmed release and inspect the available upload directories. They can also ask the host whether server-side evidence remains. But without historical logs or other evidence, the owner cannot resolve whether the site was exposed during the missing period.

Keep a short verification record

Bricksforge version found before the update and version confirmed afterward.
The vendor release guidance checked, when you checked it, and any clarification received about the applicable fix.
Which log sources you reviewed and their date ranges—or why logs were unavailable.
Which upload locations you inspected and whether you found unexpected files or recent changes.
Any suspicious requests or files referred for host or incident-response review, and who owns the follow-up.

A record showing no suspicious findings describes only the evidence available and reviewed. It cannot rule out activity that the logs did not capture, that occurred outside their retention period, or that was not visible in the locations inspected.

Has your host confirmed which logs it retains and how long they remain available? Share the general setup or lessons learned, but don’t post log contents, credentials or other sensitive site details.

Sources

Editorial note: AI assists with research, drafting and automated checks. Sources are linked so you can verify the guidance. Platform requirements can change; confirm the details that apply to your setup.