Bricksforge Upload Flaw: Patch and Investigate
Bricksforge’s critical file-upload flaw can let unauthenticated attackers execute PHP on WordPress sites. Patchstack first recorded attempts against CVE-2026-85097 on 7 October.
Bricksforge extends Bricks Builder. Image files containing PHP could pass an initial check, then reach an executable path because later processing trusted attacker-supplied metadata.
Those attempts establish targeting, not successful compromise, a victim count or attribution to one actor. Whether a particular site was compromised needs to be established from its own evidence.
The original fix and the later releases
Bricksforge 3.1.8.9 and earlier are affected, while 3.1.8.10 is the first fixed 3.x release. Version 4.0.0, released on 17 September, already included the original security fixes.
Version 4.0.1, released on 8 October, fixed a separate issue affecting every site with Pro Forms active, even without upload fields. It was not a new fix for the original CVE.
Version 4.0.2, released on 13 October, hardens REST endpoints, protects the temporary directory against execution and corrects valid image rejections. This added protection does not mean 4.0.0 remained vulnerable to the original CVE.
Closing the vulnerability is not the end of the response
Update to the newest supported Bricksforge release, then establish the site’s exposure window: which version was installed, when it was reachable from the internet and when the update completed. Include staging, development and abandoned copies, rather than checking only the main production site.
The UK National Cyber Security Centre’s guidance on active exploitation calls for rapid remediation alongside an investigation for evidence of compromise. These are separate jobs: one reduces the opportunity for another attack; the other establishes whether an incident has already occurred.
The useful traces are concrete: submissions containing temporaryFileUploads, image paths paired with PHP destinations, unexpected PHP files and requests to them.
If those indicators appear, isolate the affected site and begin incident response. Keep the evidence needed for that investigation, including available logs and suspicious files. Establish what any uploaded code did and review unauthorised changes. Where evidence is incomplete or the site is business-critical, bring in a qualified incident-response provider.
Bricksforge also says 4.0.2 filters stored credentials more thoroughly and recommends renewing API keys as a precaution. That recommendation is not proof that keys were stolen.
Sources
- Bricksforge changelog
- Patchstack analysis, published 8 October 2026
- Patchstack vulnerability record, published 7 October 2026
- NCSC response guidance
