Critical Bricksforge Flaw Under Active Exploitation
A maximum-severity vulnerability in the Bricksforge plugin for WordPress is being actively exploited in the wild, according to security firm Patchstack. The flaw, tracked as CVE-2026-85097, allows completely unauthenticated attackers to upload and execute arbitrary PHP code on vulnerable sites, resulting in full remote code execution (RCE). Patchstack rates the issue CVSS 10.0 — the maximum possible score — while other trackers list it at 9.8. Bricksforge is a commercial "Swiss Army knife" add-on for the Bricks visual site builder, used to extend it with custom forms, animations, and dynamic content, and Patchstack estimates roughly 6,000 active installations are affected. Exploitation attempts were first detected on October 7, 2026 at 21:47 UTC, and a patched release, version 3.1.8.10, is already available.
Vulnerability Details
| Attribute | Value |
|---|---|
| CVE ID | CVE-2026-85097 |
| CVSS Score | 10.0 (Patchstack); 9.8 per other trackers |
| Weakness Class | CWE-434 — Unrestricted Upload of File with Dangerous Type |
| Affected Product | Bricksforge plugin for WordPress (add-on for the Bricks visual builder) |
| Affected Versions | Up to and including 3.1.8.9 |
| Patched Version | 3.1.8.10 and later |
| Estimated Exposure | Approximately 6,000 active installations |
| Authentication Required | None — fully unauthenticated |
| Discovered By | Patchstack; credited to researcher d.v4n_s3c |
| CVE Timeline | Reserved September 3, 2026; published October 8, 2026 |
| Active Exploitation Detected | October 7, 2026, 21:47 UTC |
How the Attack Works
Step 1 — Grabbing an unauthenticated nonce
Bricksforge's form-handling functionality relies on a WordPress security nonce for its AJAX calls. Because the bricksforge_regenerate_nonce endpoint can be called by anyone without logging in, an attacker simply requests a fresh, valid nonce before doing anything else — no credentials or session needed.
Step 2 — Uploading a GIF/PHP polyglot
Using that nonce, the attacker uploads a crafted polyglot file — a single file that is simultaneously a valid GIF image and a valid PHP script — to Bricksforge's temporary upload directory. Because the file's header bytes match a legitimate image format, it sails through the plugin's MIME-type validation, even though executable PHP code is embedded further inside the file.
Step 3 — Spoofing the destination path
This is the core of the bug. According to Patchstack, "Bricksforge validates a file's MIME type when it is first uploaded. When a form is later submitted, however, it trusts the file metadata the client sends." When the attacker submits the form a second time, they supply their own value for the url field inside the temporaryFileUploads parameter — referencing the already-validated image, but with the destination filename changed to end in .php. Because the server never re-validates this client-supplied metadata against the actual file contents, it writes the polyglot's contents out under the attacker-chosen .php filename.
Step 4 — Achieving code execution
With a live .php file now sitting inside a web-accessible uploads path, the attacker simply requests it directly. The web server executes the embedded PHP, giving the attacker a working web shell and full remote code execution on the host — all without ever authenticating to WordPress.
Exploitation in the Wild
Patchstack's telemetry shows automated attacks arriving through two separate entry points: the plugin's REST API route (/wp-json/bricksforge/v1/form_submit) and the legacy AJAX handler (/wp-admin/admin-ajax.php with the bricksforge_form_submit action), both carrying the malicious temporaryFileUploads payload.
Researchers identified 63 unique source IP addresses participating in the campaign, with just six IPs responsible for roughly 46% of all malicious requests observed — suggesting a small, concentrated group of operators running the bulk of the scanning and exploitation traffic. To dodge naive filename blocklists, attackers have been observed rotating through alternate PHP extensions (.php5, .php7, .phtml), mixed-case variants (.PHP, .Php), and URL-encoded extensions (.%70hp, %2ephp) when naming their uploaded payloads.
Impact Assessment
| Impact Area | Description |
|---|---|
| Remote Code Execution | Successful exploitation hands the attacker a functioning PHP web shell with the privileges of the web server process |
| Site Takeover | Web shell access enables full administrative control of the WordPress installation, including the database and other plugins |
| Data Exposure | Attackers can exfiltrate customer data, credentials, API keys, and any other sensitive content stored on or accessible from the compromised site |
| Persistence | Dropped web shells and rogue admin accounts can survive a plugin update if the underlying compromise isn't fully remediated |
| Supply Chain Risk | Agencies and hosts managing many Bricks/Bricksforge sites on shared infrastructure risk lateral spread across client sites |
| Scale of Exposure | ~6,000 active Bricksforge installs were vulnerable at disclosure; exact current compromise count is not yet published |
Recommendations
For site administrators
- Update Bricksforge to version 3.1.8.10 or later immediately — this is the single most important remediation step.
- After patching, treat the site as potentially already compromised if it was exposed before the update: rotate WordPress admin passwords, database credentials, and any API keys stored in the environment.
- Search the uploads tree, especially
/wp-content/uploads/bricksforge/tmp/, for unexpected.php,.php5,.php7,.phtml, or oddly-cased/encoded files that don't belong there. - Review the WordPress admin user list for unfamiliar accounts created after October 7, 2026.
For security teams
- Audit web server and WAF logs for requests to
/wp-json/bricksforge/v1/form_submitand/wp-admin/admin-ajax.php?action=bricksforge_form_submitcontaining atemporaryFileUploadsparameter, particularly ones referencing non-image file extensions. - Correlate any hits against the known concentrated source-IP pattern Patchstack observed, and consider deploying Patchstack's published mitigation rule if you run a compatible WAF/virtual-patching product.
- Flag and alert on any newly written PHP files inside plugin upload directories site-wide, not just Bricksforge's — this upload-then-execute pattern is common across WordPress plugin vulnerabilities.
For agencies and hosting providers
- Inventory every client site running Bricks Builder to identify which also run the separate Bricksforge add-on — sites using Bricks alone are not affected by this specific CVE.
- Push the 3.1.8.10+ update across managed fleets on an expedited schedule rather than waiting for routine maintenance windows, given confirmed active exploitation.
- Consider temporary virtual patching or WAF rules for any site that cannot be updated immediately.
Key Takeaways
- CVE-2026-85097 is a maximum-severity (CVSS 10.0 per Patchstack) unauthenticated arbitrary file upload flaw in the Bricksforge WordPress plugin, leading to full remote code execution.
- The flaw affects versions ≤ 3.1.8.9 and is fixed in 3.1.8.10; roughly 6,000 sites were running vulnerable versions at disclosure.
- The exploit chain combines an unauthenticated nonce grab, a GIF/PHP polyglot upload that bypasses MIME validation, and a trust gap where the server accepts attacker-supplied destination metadata instead of re-validating it.
- Active exploitation began October 7, 2026, from at least 63 source IPs, using extension-case and encoding tricks to evade filename-based defenses.
- Successful attacks grant a web shell and full site takeover, with downstream risk of data theft and persistence even after the plugin is updated.
- Site owners should patch immediately, inspect upload directories for rogue PHP files, and rotate credentials on any site that was exposed before patching.