TUESDAY, OCTOBER 13, 2026 Tech news, minus the noise.
N News Cast International Edition Subscribe
LIVE
Cybersecurity

Hackers Exploited a Critical WordPress Plugin Flaw Before It Was Disclosed

CVE-2026-85097 is a CVSS 10.0 unauthenticated file-upload flaw in the Bricksforge WordPress plugin — and attackers were exploiting it a day before disclosure. The attack chain and what to do.

Hackers Exploited a Critical WordPress Plugin Flaw Before It Was Disclosed
Illustration: News Cast

Here's a nightmare scenario for anyone running a WordPress site: attackers were exploiting a critical flaw in the Bricksforge plugin a full day before the vulnerability was even publicly disclosed. CVE-2026-85097 — an unauthenticated file-upload bug leading to remote code execution — was disclosed on October 8. Patchstack's telemetry shows in-the-wild exploitation starting October 7 at 21:47:17 UTC.

The WordPress Plugin Vulnerability, Step by Step

The basics: Bricksforge is a commercial add-on for Bricks, the popular visual site builder for WordPress. The flaw, classified CWE-434 (unrestricted file upload), lets an attacker upload arbitrary files without logging in — and turn that upload into full remote code execution. No credentials, no user interaction, complete site takeover.

Roughly 6,000 websites run the plugin. Versions up to and including 3.1.8.9 are affected; the fix landed in 3.1.8.10. Patchstack scored it a 10.0 critical; SecurityWeek reported 9.8. Wordfence is the assigned CNA. However you slice the scoring, this is as bad as plugin vulnerabilities get.

Exploited Before Disclosure

The timeline is what makes this story stand out. Responsible disclosure is supposed to give vendors a head start: researcher finds bug, vendor patches, public learns about it, attackers start probing. Here the order inverted. Attackers were firing exploits at 21:47 UTC on October 7 — before Patchstack's October 8 disclosure, which strongly suggests they independently discovered the flaw or got wind of it early.

Patchstack's telemetry caught two distinct automated clusters. One: 44 IP addresses sending 56 identical-payload requests within seconds of each other — a coordinated mass-exploitation wave. The other: 3 IPs testing 25 PHP-extension and encoding variants, methodically probing for the bypass that works. No single actor has been attributed, which is normal at this stage — and irrelevant to the defense, which is the same regardless of who's attacking.

This is part of a pattern, not an anomaly. The October breach wave showed how quickly known flaws get weaponized at scale. The lesson keeps repeating: the gap between disclosure and mass exploitation is now measured in hours, and sometimes — like here — the exploitation starts first.

How the Attack Works

The root cause is a classic trust-the-client flaw. The plugin validated the file's MIME type on upload, but then trusted client-supplied file metadata at submission time. Attackers slipped executable PHP past the check using polyglot GIFs — files that are valid images and valid PHP at the same time.

The attack chain, per published analysis:

  1. Hit the bricksforge_regenerate_nonce AJAX endpoint to get a valid nonce.
  2. Upload a polyglot GIF to wp-content/uploads/bricksforge/tmp/.
  3. Rename it to .php, .PHP, or .php5 — the extension variants the probing cluster was testing.
  4. Request the file directly: you now have a web shell and full control of the site.

Every step is unauthenticated. The only thing standing between an attacker and your server was a MIME check that trusted the attacker's own description of the file. It's the kind of bug that makes security engineers sigh — not sophisticated, just devastating.

What to Do If You Run WordPress

If Bricksforge is installed anywhere you manage, treat this as an incident until proven otherwise:

  • Update to 3.1.8.10 immediately. This is the entire fix; everything else is cleanup.
  • Check for compromise. Look in wp-content/uploads/bricksforge/tmp/ for PHP files or anything that shouldn't be there, and scan for unknown admin users and recently modified files. Exploitation predates disclosure, so 'I updated the day it was announced' isn't sufficient.
  • Harden the fundamentals. Strip unused plugins, enable auto-updates where you can, and put strong authentication on wp-admin — passkeys where your host supports them.

The broader takeaway: your plugin supply chain is your attack surface. A visual builder add-on most site owners installed once and forgot about became a remote shell for thousands of sites. Audit what you're running — the plugin you ignore is the one attackers love.

AS
News Cast Editorial Team

We cover AI, gadgets, startups and security — original reporting and explainers, written by humans, for humans. Got a tip? Reach us via the contact page.