Bricksforge CVE-2026-85097: Unauthenticated PHP Upload Under Attack Since 7 October

An unauthenticated file upload flaw in Bricksforge, a commercial add-on for the Bricks Builder WordPress theme, is being exploited to plant PHP code on vulnerable sites. The bug is tracked as CVE-2026-85097. NVD and Wordfence list versions up to and including 3.1.8.9, but the vendor's changelog shows 4.0.0 (17 September) shipped after that and before the fix in 4.0.1 (8 October), so 4.0.0 sites should be treated as likely exposed. Patchstack saw the first attempt on 7 October 2026 at 21:47 UTC.

What happened

CVE-2026-85097 was published on 8 October 2026 by Wordfence, acting as CVE Numbering Authority. NVD lists it as an arbitrary file upload (CWE-434) in the Bricksforge plugin and carries Wordfence's CVSS 3.1 score of 9.8 (Critical, network, low complexity, no privileges, no user interaction). NVD's own analysis is deferred. Patchstack rates the same flaw 10.0.

Patchstack says its telemetry shows active exploitation, first seen 7 October 2026 at 21:47:17 UTC, and that its mitigation rule was live before the first attack. It recorded 63 unique source IPs. CISA's SSVC entry, added the same day (8 October), recorded exploitation as "none", automatable as "yes" and technical impact as "total". CISA's call, timestamped 14:24 UTC on 8 October, came after Patchstack had already seen attempts the previous evening. As of our check on 13 October the CVE was not in CISA's Known Exploited Vulnerabilities catalog.

The CVE.org record from Wordfence gives this timeline: the vendor was notified on 3 September 2026; Wordfence lists the report as disclosed on 7 October; Patchstack's first observed attack was the evening of 7 October; the CVE was published at 07:16 UTC on 8 October; and Bricksforge dated version 4.0.1 the same day. The finder is credited as "d.v4n_s3c".

Why it matters

The flaw needs no login, and CISA marks it as automatable, which fits what Patchstack describes: scripted attempts over rotating proxies and cloud hosts. A successful request gives the attacker PHP execution on the web server, which Patchstack says can lead to web shells, content changes, data theft and persistent access.

Bricksforge extends Bricks Builder with forms, animations and dynamic data. It is not listed on WordPress.org (the plugin API returns "not found") and is sold from bricksforge.io, so sites will not see updates through the usual WordPress.org channel unless the vendor's own updater is active. We could not confirm an install count. Patchstack's page shows a "6K" figure without a label, and we have not treated it as an install count.

Technical details

Per NVD and Patchstack, Bricksforge checks a file's MIME type when it is first uploaded, but when a form is later submitted it trusts metadata supplied by the client. The url field inside the temporaryFileUploads parameter is not validated. The attack runs in four steps:

How the upload attack works, step by step

1. Request a valid nonce from the unauthenticated bricksforge_regenerate_nonce AJAX endpoint.
2. Upload a GIF/PHP polyglot, a valid image that also contains PHP. It passes the MIME check and lands in the temporary upload directory.
3. Submit a form in which the server-side file path points to that image but the url ends in a PHP extension.
4. The plugin places the file contents at the PHP location. Requesting it runs the code.

Patchstack names bricksforge/includes/elements/pro-forms/actions/init.php (where the metadata is injected) and .../actions/base.php (where the upload happens).

Almost all observed attempts went to POST /wp-json/bricksforge/v1/form_submit; one used /wp-admin/admin-ajax.php with the bricksforge_form_submit action. In 95% of captured requests the server-side path ended in .gif or .png. Most targeted /wp-content/uploads/bricksforge/tmp/; some wrote files named login_admin_*.php into the normal uploads folder, such as /wp-content/uploads/2026/10/. Attackers also tried extension variants (.php5, .php7, .php8, .phtml, .pht, .phtm, .phps), case changes (.pHp) and URL-encoded or double-encoded forms such as %2ephp.

Patchstack described two clusters: 44 IPs sending 56 identical requests within seconds, and three IPs testing 25 extension and encoding variants against one temporary file. It says this points to automation but does not attribute it to one actor.

What defenders should do

• Update Bricksforge to 4.0.1, the only fixed build the vendor documents. Patchstack also names 3.1.8.10 for the 3.x line, but the changelog we read has no 3.1.8.10 entry, so confirm the installed version against the vendor's download page.
• If you run 4.0.0, treat the site as likely exposed. NVD and Wordfence list only 3.1.8.9 and earlier and the vendor has not published affected versions; our inference comes from 4.0.1's fix date and the 3 September notification, which 4.0.0 shipped after.
• The 4.0.1 notice says the issue affects every site with Pro Forms active, including sites with no upload fields.
• If you cannot update, our suggestion is to disable the plugin, or at least Pro Forms, or block the endpoints at the WAF. Patchstack itself only names its RapidMitigate rule for customers.
• Search for PHP files in /wp-content/uploads/bricksforge/tmp/ and elsewhere under uploads, especially login_admin_*.php, and for requests to newly created PHP files in upload directories.
• Search logs for form_submit requests containing temporaryFileUploads with an image path and a PHP-style url, and for bricksforge_regenerate_nonce calls followed by an upload and a form submission.
• Patchstack's most active IPs: 177.75.57.20, 23.97.62.146, 84.247.60.125, 38.154.185.97, 150.109.16.166, 153.75.90.146. They are shared or proxy infrastructure, so treat them as hunting leads, not a complete blocklist.
• If a site ran 4.0.0, 3.1.8.9 or earlier since 7 October, assume possible compromise: check the host for unexpected PHP files and unauthorized changes, and rotate credentials if any are found.

Related reading: our earlier coverage of WordPress core CVE-2026-87902.

What is still unclear

• Install base: no verified count of Bricksforge sites.
• The fixed version: Patchstack says 3.1.8.10; the vendor changelog shows no such entry, only 4.0.1 and no CVE reference.
• Whether 4.0.0 is vulnerable: no source says so; we infer it from the release dates.
• Whether any compromises have been confirmed. Patchstack reports attempts and payloads, not successful intrusions.
• Wordfence's own advisory page could not be read (blocked), so we rely on its text as published in NVD.
• The CVSS gap (9.8 versus 10.0) is unexplained; Patchstack does not publish its vector in the article.
• The actor behind the campaign is unknown.

Sources

• CVE.org CNA record (timeline, credits): https://cveawg.mitre.org/api/cve/CVE-2026-85097
• NVD record: https://nvd.nist.gov/vuln/detail/CVE-2026-85097 (API: https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-85097)
• Patchstack: https://patchstack.com/articles/critical-unauthenticated-arbitrary-file-upload-vulnerability-exploited-in-bricksforge-plugin/
• Bricksforge changelog: https://bricksforge.io/version-changelog/
• Wordfence advisory (referenced by NVD): https://www.wordfence.com/threat-intel/vulnerabilities/id/e993c929-f175-43a7-92e6-9d3b089b8dde
• CISA KEV feed: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json