by WPadawan WordPress

Bricksforge Flaw Under Attack: What WordPress Site Owners Need to Know About CVE-2026-85097

A critical vulnerability in Bricksforge, a commercial add-on for the Bricks visual site builder, is being actively exploited. It lets anyone on the internet run code on a vulnerable WordPress site without logging in. The flaw is tracked as CVE-2026-85097 and was disclosed by security firm Patchstack on October 8, 2026.

What is affected

Bricksforge versions up to and including 3.1.8.9 are vulnerable. The developer fixed the problem in 3.1.8.10. Version 4.0.1 followed on October 8, and its changelog includes a further security fix for the Pro Forms module. Per the vendor, it applies even if your forms have no upload fields. Bricksforge pitches itself as a "Swiss Army knife" for Bricks, and it adds forms, animations, scrolling video sequences and an email designer. Patchstack estimates it runs on roughly 6,000 sites.

The severity score depends on the source. Patchstack and The Hacker News report a CVSS of 10.0, while SecurityWeek cites 9.8. Both are at the top of the critical range, so the difference should not change how urgently you act.

How the attack works

The bug is in how the Pro Forms module handles temporary file uploads. Bricksforge checks a file’s MIME type when it is first uploaded. When the form is submitted, though, it trusts the file details sent by the browser. It does not validate the url field inside the temporaryFileUploads parameter.

According to the technical write-ups, an attacker can chain several steps without any account:

  • Request a valid nonce from an unauthenticated AJAX endpoint named bricksforge_regenerate_nonce.
  • Upload a GIF/PHP polyglot, a file that passes as an image but contains PHP code.
  • Submit a crafted form that points the plugin at a PHP path for that file, so the server executes it.

The result is remote code execution with the privileges of the web server’s PHP process, which is usually enough to take over a site.

Exploitation began before the advisory

Patchstack says its telemetry first recorded exploitation attempts on October 7 at 21:47 UTC, the day before the public advisory. Within about 48 hours it had seen 63 unique source IP addresses. One cluster had 44 IPs sending 56 identical requests within seconds of each other. In another, three IPs tried 25 variations of PHP extensions and encodings against the same temporary file. Patchstack says this points to automated attacks over rotating or distributed infrastructure. It does not attribute them to a single threat actor.

Some attempts tried to place files named login_admin_*.php in normal WordPress upload folders rather than the temporary directory.

What you should do

  • Update now. Move to Bricksforge 3.1.8.10 at minimum, and preferably the current 4.0.1.
  • Check your logs. Look for requests to /wp-json/bricksforge/v1/form_submit that include a temporaryFileUploads parameter.
  • Inspect the file system. Look for unexpected PHP files in /wp-content/uploads/bricksforge/tmp/ and in other upload directories, especially login_admin_*.php.
  • Look for signs of a deeper compromise. Unfamiliar administrator accounts, modified core files, odd scheduled tasks and unexplained outbound connections are all warning signs.
  • Consider a virtual patch. Patchstack says its RapidMitigate rule blocks these attempts. That is a stopgap if you cannot update immediately, not a replacement for updating.

Why it matters

This is a familiar pattern. A premium add-on with a small install base still attracts opportunistic attackers, and the gap between disclosure and mass scanning has shrunk to almost nothing. Updating after you read about a flaw may be too late. If you ran a vulnerable Bricksforge version between October 7 and your patch date, treat the update as the first step and not the last. Audit the site for leftover backdoors, because patching does not remove a shell that was already planted.

Fuentes