Bricksforge writes attacker PHP where the client asks

Bricksforge validates a file’s MIME type when it is uploaded, then stops trusting its own check as soon as the form carrying that file is submitted. On submission the plugin reads the client’s description of the file, including a url field that declares where the contents should be written, and does not re-validate it. Set that field to a path ending in .php and the plugin writes attacker-controlled code to a web-reachable location. Request the URL and the code runs.

That is CVE-2026-85097, a CVSS 10.0 unauthenticated remote code execution flaw in the Bricksforge plugin for WordPress. Patchstack reports exploitation in the wild starting 9:47 p.m. UTC on October 7, 2026. Affected versions run up to and including 3.1.8.9. The fix shipped in 3.1.8.10, and Patchstack points users to the current 4.0.1.

Bricksforge is an add-on for Bricks, the visual site builder, bundling animations, advanced forms, and scrolling video sequences.

The exploit runs in four steps. An unauthenticated request to the bricksforge_regenerate_nonce AJAX endpoint returns a valid nonce. The attacker uploads a GIF/PHP polyglot, a file that is a legitimate image and also carries PHP; it passes the MIME check and lands in the temporary upload directory. A form is then submitted whose temporaryFileUploads entry sets file to the validated GIF path and url to a path ending in .php. Bricksforge trusts the metadata, writes the file’s contents to the PHP location, and the embedded code executes on the next request.

A representative payload:

{
  "temporaryFileUploads": [
    {
      "field": "form-field-file",
      "file": {
        "file": "/var/www/example.com/wp-content/uploads/bricksforge/tmp/img_example.gif",
        "url": "https://example.com/wp-content/uploads/bricksforge/tmp/img_example.php",
        "type": "image/gif"
      }
    }
  ]
}

The requests target the REST endpoint /wp-json/bricksforge/v1/form_submit or /wp-admin/admin-ajax.php with the bricksforge_form_submit action. To defeat extension filtering, the observed traffic uses alternate PHP extensions (.php5, .php7, .phtml), case manipulation (.PHP, .Php, .pHp), and encoded extensions (.%70hp, %2ephp, .%2570%2568%2570).

Patchstack describes two clusters in its telemetry. In the first, 44 IPs sent 56 requests with identical payloads within seconds of each other. In the second, three IPs tested 25 variations of PHP extensions and encodings against the same temporary file. Both look like automated exploitation over rotating proxies or distributed infrastructure, and Patchstack declines to attribute either to a single actor. The activity spans 63 unique source IPs; six of them account for roughly 46% of requests:

• 177.75.57[.]20
• 23.97.62[.]146
• 84.247.60[.]125
• 38.154.185[.]97
• 150.109.16[.]166
• 153.75.90[.]146

Update to 4.0.1. Then look back through logs: requests to /wp-json/bricksforge/v1/form_submit carrying a temporaryFileUploads parameter, repeated form submissions, and any unexpected PHP files under /wp-content/uploads/bricksforge/tmp/. A successful write there means the site should be treated as compromised, with web shells, data access, and persistent footholds to hunt for.

Two more plugins, one implant

Separately, attackers are abusing cross-site scripting flaws in WPC Product Bundles for WooCommerce (CVE-2026-93836, CVSS 7.1) and Ninja Forms (CVE-2026-94504, CVSS 7.1) to deliver a JavaScript payload named x.js. Patchstack describes it as a post-exploitation implant that runs inside the browser of a logged-in administrator. Using that authenticated wp-admin session, it installs a malicious plugin, creates a new administrator account, invokes a hidden persistence mechanism, and reports back to attacker infrastructure. The implanted plugin ships an unauthenticated file manager reachable by a direct request to its main PHP file, a WordPress admin account hidden from the Users screen, and a magic login URL that authenticates the holder as the site’s oldest administrator.

Patched versions are 8.6.7 for WPC Product Bundles and 3.15.4 for Ninja Forms. Updating closes the XSS but does not remove an existing implant. If either plugin was exposed, query the database directly for administrators that do not appear in the Users screen, check the must-use plugin directory, and review web server logs for the file-manager request.