As reported by The Hacker News, a CVSS 10.0 vulnerability in the Bricksforge WordPress plugin (CVE-2026-85097) is now under active exploitation, giving unauthenticated attackers full remote code execution on affected sites. This is not a theoretical risk — Patchstack confirmed in-the-wild attacks beginning October 7, 2026, and the exploit path requires no credentials, no user interaction, and no privileges.
What makes this vulnerability particularly instructive for defenders is its root cause: a two-stage validation trust gap. Bricksforge correctly validates MIME types at upload time, but when the form is subsequently submitted, it trusts client-supplied metadata — specifically the url field inside the temporaryFileUploads parameter — without revalidating server-side. An attacker uploads a GIF/PHP polyglot that passes the initial MIME check, then submits a form pointing the server-side path to that validated image while setting the url to a .php extension. The plugin dutifully writes the malicious file contents to the PHP path, and the embedded code executes on request.
This is a textbook server-side trust boundary failure, and it is the same class of flaw that has plagued WordPress plugin ecosystems for over a decade. The attack is further simplified by the bricksforge_regenerate_nonce AJAX endpoint, which hands out valid nonces to unauthenticated users — effectively neutralizing WordPress's CSRF protection for this attack chain.
Vulnerability Details
| Field | Detail |
|---|---|
| CVE | CVE-2026-85097 |
| CVSS | 10.0 (Critical) |
| Affected Product | Bricksforge plugin for WordPress |
| Affected Versions | Up to and including 3.1.8.9 |
| Patched Version | 3.1.8.10 |
| Exploitation Status | Active in the wild (confirmed October 7, 2026) |
| Authentication Required | No — fully unauthenticated |
| Impact | Remote Code Execution, web shell deployment, full site compromise |
Who Is at Risk
Any WordPress site running Bricksforge versions 3.1.8.9 or earlier is exposed. Given Bricksforge's positioning as a companion to the Bricks page builder — which has gained significant traction among agencies, freelancers, and SMBs building marketing sites — the exposed population likely skews toward small-to-medium businesses and managed hosting environments where plugin update hygiene is often inconsistent. Sites with publicly accessible form endpoints (the default configuration) are fully exposed.
Broader Implications
This incident underscores a persistent structural problem: the WordPress plugin ecosystem continues to be a dominant initial access vector because a single plugin flaw can compromise the entire host. The attack pattern — polyglot file uploads combined with metadata trust gaps — is well-understood and detectable, yet it recurs because validation logic is frequently split across request lifecycle stages. Defenders should note that Web Application Firewalls (WAFs) may not catch this traffic if the polyglot upload and the form submission appear as separate, seemingly benign requests.
Immediate Actions
bricksforge_regenerate_nonce AJAX endpoint and the Bricksforge REST API form submission endpoint at the WAF or reverse proxy level if the plugin must remain active..php files with image-related names. Review web server access logs for POST requests to /wp-json/ endpoints associated with Bricksforge form submissions.wp-content/uploads/ directory tree for PHP files, especially those containing eval(), base64_decode(), or system() calls.Shield53 Recommendations
Beyond the immediate patch, organizations running WordPress at scale should implement the following:
- Adopt continuous plugin inventory management. Maintain a real-time inventory of all installed plugins and their versions. Automated alerting on newly disclosed critical CVEs for any installed plugin should be standard.
- Enforce file upload validation at the web server layer. Configure nginx or Apache to deny execution of PHP in upload directories. This provides defense-in-depth even when plugin validation logic fails.
- Deploy runtime integrity monitoring. Use file integrity monitoring (FIM) on WordPress document roots to detect new PHP files in upload directories within minutes of creation.
- Restrict AJAX and REST endpoints by default. For non-authenticated users, consider blocking or rate-limiting WordPress AJAX and REST API endpoints that are not strictly required for site functionality.
- Review WordPress hosting architecture. Consider PHP-FPM pool isolation, disable dangerous functions (
exec,system,shell_exec), and implement open_basedir restrictions to limit the blast radius of any RCE.
The lesson here is not new, but it bears repeating: never trust client-supplied metadata for security decisions. The moment a server accepts a client-controlled
urlorpathfield and acts on it without revalidation, you have created an exploitable trust boundary. Audit your file upload and form handling code accordingly.
