WordPress upload flaw lets attackers plant executable files
WordPress sites running vulnerable versions of Bricksforge are facing active attempts to turn image uploads into executable files, according to Patchstack. Its October 8, 2026 advisory identifies CVE-2026-85097, a flaw that requires no attacker login and can allow remote code execution (RCE), meaning an outsider can run instructions on the website’s server. Site owners should update to Bricksforge 3.1.8.10 or later.
Versions up to and including 3.1.8.9 are affected. Patchstack assigns the vulnerability a Common Vulnerability Scoring System (CVSS) rating of 10.0, the maximum severity score, and records its first observed exploitation attempt at October 7, 2026, 21:47:17 UTC. Its advisory points to the Bricksforge changelog for the vendor’s update information. The reported activity establishes that attackers are trying to exploit the flaw, but the advisory does not give a count of successfully compromised websites.
Bricksforge extends Bricks Builder, a visual WordPress website-building tool. Its features include advanced forms, animations, custom interactions, dynamic data management and administration-area customization. The weakness lies in how its forms handle uploaded files, not in a requirement for an attacker to obtain a WordPress account.
How an image becomes executable
The plugin initially checks a file’s MIME type, a label describing its content format. But when a form is subsequently submitted, it trusts metadata, the descriptive fields supplied with the file, from the visitor’s browser. In particular, it fails to validate the url field within temporaryFileUploads. That lets attackers supply an image as the source while specifying a destination with an extension for PHP, the programming language used by WordPress.
Patchstack describes a four-stage chain. First, an attacker obtains a valid nonce, a request-validation token, through bricksforge_regenerate_nonce. This AJAX endpoint, a handler for background browser requests, is accessible without logging in. Next, the attacker uploads a GIF/PHP polyglot, a single file that is both a valid image and contains PHP code. It passes the initial content-type check and enters the temporary upload directory. The attacker then submits a form pointing to that accepted image but supplies a url ending in a PHP extension. Bricksforge uses the untrusted metadata to place the contents at the PHP destination. Requesting that file causes the server to execute its embedded code.
Patchstack identifies bricksforge/includes/elements/pro-forms/actions/init.php as the location where temporaryFileUploads metadata enters processing, and bricksforge/includes/elements/pro-forms/actions/base.php as the code location that subsequently permits arbitrary uploads. Successful exploitation can enable web shells, scripts for remotely controlling a compromised website, as well as content changes, access to sensitive data and persistent attacker access.
What the attack requests contain
All but one of the attempts Patchstack recorded used POST requests, which send data to a website, to /wp-json/bricksforge/v1/form_submit. This is the plugin’s REST API form-submission endpoint, a web address that accepts structured requests. The other request targeted /wp-admin/admin-ajax.php with the bricksforge_form_submit action. Every request carried a crafted temporaryFileUploads parameter.
The important warning sign is a mismatch between the source file path and destination URL, or web address. In Patchstack’s normalized example, the field value is form-field-file, the file.file value points to /var/www/example.com/wp-content/uploads/bricksforge/tmp/img_example.gif, file.url points to the corresponding img_example.php web address, and file.type is image/gif. These are illustrative values, not a reported victim address. In 95% of captured requests, the server-side path ended in .gif or .png; most of those paired it with a PHP-related destination.
Most attempts referenced /wp-content/uploads/bricksforge/tmp/. Others tried to put executable files in regular WordPress upload folders, including /wp-content/uploads/2026/10/, using names matching login_admin_*.php, where the asterisk represents a variable part of the name.
Patchstack observed several attempts to get around file-extension filtering. Submitted suffixes included .php, .php5, .php7, .php8, .phtml, .pht, .phtm and .phps. Capitalization variants included .PHP, .Php, .pHp and .PHTML. Attackers also used URL encoding, which represents characters with special sequences, and double encoding, which applies that transformation twice: examples included %2ephp, .%70hp and .%2570%2568%2570. Other requests changed or omitted path, name, originalFilename and url fields to probe how the plugin processed them.
Distributed activity, not confirmed attribution
Patchstack’s monitoring found one cluster of 44 IP addresses sending 56 identical requests within seconds, and another in which three addresses tried 25 PHP-extension and encoding variations against the same temporary file. IP addresses identify network connections. These patterns suggest automated attacks using rotating proxies, intermediary connections that change the apparent source, or distributed infrastructure. They do not establish that a single attacker controls the activity.
There were 63 unique source IP addresses, with the six busiest accounting for about 46% of requests. Patchstack lists 177.75.57.20 on EXPLORERNET, a Brazilian fixed-line internet provider, with 8 AbuseIPDB reports and no CleanTalk blacklist entry; 23.97.62.146 on Microsoft Azure with 1,270+ reports and no entry; 84.247.60.125 on HostRoyale with 12 reports and an entry; 38.154.185.97 on B2 Net Solutions with 11 and an entry; 150.109.16.166 on Tencent with 185 and an entry; and 153.75.90.146 on Cloudzy with 35 and an entry. These are the advisory’s reported reputation checks, not current independent measurements.
The sources span datacenters, cloud services, virtual private networks (VPNs), which route traffic through another connection, proxy services and residential or fixed-line connections. The busiest address, 177.75.57.20, stood out because it was on a fixed-line provider rather than a datacenter and had little recorded prior abuse history.
Update, then check for earlier intrusion
Install the fixed version and ask whoever maintains the site to review web-request and application logs. Relevant signs include form_submit requests containing temporaryFileUploads, image paths paired with PHP destinations, nonce-generation calls followed by uploads and form submissions, and repeated changes to extensions or capitalization. Check upload folders for unexpected PHP files, especially login_admin_*.php, and requests accessing newly created executable files. Sites previously running vulnerable versions without protection also need historical checks for unusual activity and unauthorized changes.