Bricksforge Vulnerability: 7 Proven Fixes for CVE-2026-85097 (2026)

The Bricksforge vulnerability (CVE-2026-85097) is a critical, unauthenticated arbitrary file upload flaw in the Bricksforge add-on for Bricks Builder that lets an attacker upload and run PHP code on your WordPress site without ever logging in. Patchstack rates the Bricksforge vulnerability CVSS 10.0, and exploitation attempts began on October 7, 2026. If your site runs Bricksforge 3.1.8.9 or earlier, update it today and check for signs of compromise before reading further.

What Is the Bricksforge Vulnerability (CVE-2026-85097)?

CVE-2026-85097 is an unauthenticated arbitrary file upload vulnerability in Bricksforge, a premium add-on that extends the Bricks Builder page builder with extra elements, dynamic data, and form tools. According to Patchstack, the Bricksforge vulnerability sits in the plugin’s Pro Forms module and lets anyone — with no account and no login — upload a file that WordPress later executes as PHP code. That is effectively a full site takeover: once an attacker’s PHP file runs on the server, they can create admin accounts, read the database, export customer data, or plant a backdoor that survives a simple plugin update.

Patchstack assigned the Bricksforge vulnerability a CVSS score of 10.0, the maximum possible. Other trackers that score it against the standard CVSS 3.1 vector, including Rapid7’s vulnerability database, list it at 9.8. Either way, it sits at the top end of severity: no authentication required, no user interaction required, and the outcome is remote code execution — the same category of flaw security teams treat as an emergency rather than routine maintenance.

The timing matters as much as the score. A vulnerability that requires a logged-in subscriber account is a meaningful but containable risk. The Bricksforge vulnerability requires nothing at all from the visitor’s side, which is why Patchstack escalated it the moment exploitation attempts appeared, rather than waiting for a slower, staged disclosure.

How Does CVE-2026-85097 Actually Work?

The attack behind the Bricksforge vulnerability abuses a two-step upload process in the plugin’s form builder. First, the attacker calls Bricksforge’s unauthenticated bricksforge_regenerate_nonce AJAX endpoint to obtain a valid security nonce without ever logging in. Using that nonce, they upload a file crafted as a GIF/PHP polyglot — a file that passes the plugin’s MIME-type check because its header looks like an image, while its body also contains valid, executable PHP code.

Second, when the form is actually submitted, Bricksforge trusts client-supplied file metadata instead of re-validating the file it already stored on disk. By pointing the submission at a filename ending in .php, the attacker gets the server to treat the previously “validated” image as a PHP script and execute it directly. This is what separates the Bricksforge vulnerability from a simple upload bug: the MIME check happens once, early, and is never repeated at the point where the file is actually used.

Patchstack’s telemetry recorded the first exploitation attempts tied to the Bricksforge vulnerability on October 7, 2026, with activity reported from dozens of distinct IP addresses within days of the initial disclosure. That speed is typical of modern WordPress attacks: automated scanners probe for vulnerable plugin versions within hours of a public write-up, long before most site owners have read the news.

Which Bricksforge Versions Are Affected?

Bricksforge versions up to and including 3.1.8.9 are vulnerable to CVE-2026-85097. The vendor’s own fix for the Bricksforge vulnerability shipped in version 3.1.8.10, and Bricksforge has since released a newer 4.x branch that also includes the fix. Because changelog details vary slightly between security trackers, treat 3.1.8.10 as the minimum safe version and confirm you are on the latest release available in your WordPress dashboard rather than assuming any single version number is still current by the time you read this.

The table below summarizes the core facts of the Bricksforge vulnerability in one place, pulled from Patchstack’s advisory and Rapid7’s NVD-sourced database entry.

How Do You Patch the Bricksforge Vulnerability Right Now?

Fixing the Bricksforge vulnerability on a single site only takes a few minutes once you know where to look. Work through these steps in order rather than skipping straight to an update:

1. Log in to wp-admin and open Plugins. Find Bricksforge and check the installed version number against 3.1.8.9.
2. If an update is available, update Bricksforge immediately. If you manage the site through a staging workflow, push this particular update straight to production — a critical, actively exploited flaw like the Bricksforge vulnerability is not one to batch with your next scheduled release cycle.
3. If no update shows up automatically in your dashboard, download the latest version directly from your Bricksforge account and install it manually, since premium-plugin updates do not always appear through the standard WordPress update checker.
4. Re-check the plugin’s version number after updating to confirm it actually changed, rather than assuming the update succeeded.
5. If you cannot update immediately for any reason, disable the plugin’s form-related features or deactivate Bricksforge entirely until you can apply the fix.
6. Clear any server-side or CDN cache afterward so a cached, pre-patch version of a page is not served to visitors.

Our broader WordPress plugin security audit walks through the same kind of version-checking process for every plugin on a site, not just Bricksforge, and is worth running on a recurring schedule rather than only after a headline about the Bricksforge vulnerability sends you looking.

How Can You Tell If Your Site Was Already Compromised?

Updating the plugin stops new attacks that try to exploit the Bricksforge vulnerability, but it does not undo anything an attacker already did before you patched. Look for these signs, especially if your site ran an affected version at any point after October 7, 2026:

• Unfamiliar admin or editor accounts in Users, particularly ones created recently that you did not add yourself.
• New or unexpected .php files inside wp-content/uploads, a folder that should never contain executable PHP under normal operation.
• Unusual outbound traffic, spikes in server load, or new cron jobs you did not schedule, which can indicate a backdoor phoning home or sending spam.
• Changes to .htaccess, wp-config.php, or core files that you cannot explain through your own recent edits.
• Search engine warnings, hosting provider abuse notices, or browser “deceptive site” flags appearing for visitors.

A file-integrity scan from a security plugin, or a manual review with your host’s file manager, will catch most of these signs faster than waiting for a visible symptom to show up on the front end. The longer a site sits compromised after the Bricksforge vulnerability was exploited, the more backdoors an attacker typically has time to plant.

What Should You Do If You Find Signs of a Hack?

If you find any of the signs above, treat the site as compromised, not just outdated. Restore from a backup taken before October 7, 2026, if one exists and is verified clean. If you cannot roll back that far, bring in a WordPress security specialist or your host’s malware-removal service rather than deleting suspicious files one by one — attackers who achieve remote code execution through a flaw like the Bricksforge vulnerability often leave more than one backdoor, so a partial cleanup frequently leaves a way back in.

Afterward, rotate every credential tied to the site: WordPress admin passwords, database passwords, hosting and SFTP logins, and any API keys stored inside other plugins. Our guide on the vulnerability disclosure process explains how to report what you find back to a plugin vendor, which helps other site owners running the same software get warned faster the next time a flaw like the Bricksforge vulnerability surfaces.

Why Are Page Builder Add-ons Like Bricksforge Such a Common Target?

The Bricksforge vulnerability is not an isolated case. Bricks Builder itself, the core plugin Bricksforge extends, had its own critical unauthenticated remote code execution flaw in early 2024, CVE-2024-25600, caused by unsafe use of PHP’s eval() function and reachable through an unauthenticated REST endpoint. Multiple trackers rated that bug 9.8 to 10.0 as well, and it was actively exploited within days of disclosure — the same pattern seen with the Bricksforge vulnerability nearly two years later.

Page builders and their add-ons share a common risk profile: they expose large numbers of AJAX actions and REST endpoints to support live editing, dynamic content, and form submissions, and many of those endpoints are deliberately left open to logged-out visitors because contact forms and dynamic blocks need to work for anonymous site visitors too. Every one of those open endpoints is a potential entry point, and a single missed validation check — as with the Bricksforge vulnerability’s form upload flow — can turn a convenience feature into a full compromise.

What Should You Do If Your Site Is on Shared Hosting?

Many small WordPress sites, including ones built with Bricks Builder and Bricksforge, run on shared hosting plans where several accounts sit behind the same server and the same outbound IP ranges. That setup changes how you should respond to a flaw like this one in two ways. First, check whether your host already applies virtual patching or a web application firewall at the server level — many managed and shared hosts quietly block known exploit patterns for high-profile CVEs within a day or two of disclosure, before most customers even update. Ask your host’s support team directly rather than assuming either way.

Second, if your account was compromised, do not assume the damage is contained to your own files. On shared hosting, a successful remote-code-execution exploit can sometimes be used to probe for weaknesses in neighboring accounts on the same server. Report the incident to your host’s security or abuse team as soon as you find signs of compromise, both so they can check server-wide logs and so they can confirm whether the account-level isolation on your plan held.

If you manage the site yourself through a control panel like hPanel or cPanel, use its built-in file manager or malware scanner as a first check rather than relying only on a WordPress plugin, since a sufficiently capable backdoor can sometimes disable security plugins from inside WordPress itself.

How Does This Compare to Other WordPress Plugin Vulnerabilities in 2026?

Bricksforge is far from the only builder add-on to take a hit in 2026. Comparing severity and attack surface helps you prioritize patching across your whole plugin list rather than firefighting one CVE at a time.

The pattern across all four rows is the same one driving the Bricksforge vulnerability: page-builder add-ons carry a large surface area of form handlers, AJAX endpoints, and dynamic content features, and each one is a potential entry point. Our Kirki vulnerability fix guide and Elementor Pro vulnerability guide cover the other two rows in that table in more detail, and both follow roughly the same patch-then-inspect process described above for the Bricksforge vulnerability.

How Do You Prevent the Next Bricksforge-Style Vulnerability?

You cannot predict which plugin will have the next critical CVE, but you can shrink how much damage one causes. Keep the number of active plugins low, especially page-builder add-ons that bundle form handling and file uploads, since each added feature widens the surface a future bug like the Bricksforge vulnerability could exploit. Use a web application firewall that can block exploitation attempts at the network edge even before you apply a plugin update — Patchstack and similar services pushed a virtual patch for the Bricksforge vulnerability within days of disclosure, buying site owners time to update properly.

Keep off-site backups running daily, and store them somewhere an attacker who gains WordPress access cannot also delete them. A backup taken the night before an incident like the Bricksforge vulnerability is often the difference between an hour of recovery work and a week of it. Our guide to a related backup-plugin vulnerability is a useful reminder that even the tools you use for recovery need their own patching discipline.

Finally, subscribe to a vulnerability feed for the specific plugins you run, rather than waiting to hear about an exploit secondhand. Patchstack, WPScan, and Wordfence all publish free vulnerability databases that cover premium plugins like Bricksforge, not just the ones hosted on the public WordPress.org repository, so you can learn about the next Bricksforge vulnerability the same day it is disclosed instead of weeks later.

It also helps to keep a simple written log of which plugins run on which sites, with version numbers and update dates, especially if you manage more than one WordPress install. When a CVE drops for a plugin you recognize, that log turns a stressful scramble into a five-minute lookup, and it is far easier to maintain proactively than to reconstruct after an incident.

Frequently Asked Questions

Is the Bricksforge vulnerability still being actively exploited?

Patchstack’s telemetry showed active exploitation attempts tied to the Bricksforge vulnerability starting October 7, 2026, and continuing in the days afterward. Treat any unpatched, internet-facing Bricksforge install as actively targeted, not just theoretically at risk.

Do I need Bricks Builder installed for this to affect my site?

Yes. Bricksforge is an add-on for the Bricks Builder page builder, so the Bricksforge vulnerability only applies to sites running both Bricks Builder and the Bricksforge plugin together.

Does updating Bricksforge remove an existing backdoor?

No. Updating the plugin closes the upload flaw behind the Bricksforge vulnerability but does nothing to files an attacker already placed on your server beforehand. Check for compromise separately using the signs listed earlier in this guide.

What CVSS score does CVE-2026-85097 actually have?

Patchstack rates the Bricksforge vulnerability CVSS 10.0, the maximum possible score. NVD-sourced databases such as Rapid7 list it at 9.8 under the standard CVSS 3.1 vector. Both place it firmly in the critical range.

Is a web application firewall enough protection on its own?

A WAF or virtual patch can block known exploitation patterns for the Bricksforge vulnerability quickly, which is valuable while you schedule an update, but it is not a substitute for actually updating the plugin. Treat it as a stopgap, not a fix.

Where can I verify the latest fixed version of Bricksforge?

Check the plugin’s changelog inside your Bricksforge account dashboard, since it is a premium add-on not distributed through the WordPress.org plugin repository. Compare your installed version against the latest listed release before assuming the Bricksforge vulnerability no longer applies to your site.

Will my hosting provider automatically block this attack for me?

Some managed and shared hosts deploy server-level firewall rules or virtual patches for high-profile CVEs within a day or two, but this is not guaranteed and varies by provider and plan. Contact your host directly to confirm, and update the plugin regardless — a server-side mitigation is not a substitute for closing the underlying flaw.