Attackers Exploit CVSS 10.0 Bricksforge WordPress Flaw Enabling Unauthenticated RCE

A WordPress plugin is an add-on that gives a website extra features. Bricksforge supports animations, advanced forms, and scrolling video sequences for the Bricks visual builder. Plugins operate within the WordPress site, so their code can interact with files, forms, uploads, and server functions. A security flaw can therefore become a site-wide problem.

In this incident, Bricksforge accepted unsafe file metadata during form submission. An unauthenticated attacker could obtain a nonce, upload a GIF/PHP polyglot, and make the server place its contents at a PHP-named location. When requested, that file could execute code on the server.

The impact goes beyond the plugin’s advertised features. Successful exploitation could let attackers seize control of the WordPress site, deploy web shells, read sensitive data, and establish persistent access. Bricksforge versions through 3.1.8.9 were affected, while patches were released in 3.1.8.10. Users were advised to update to version 4.0.1.

CVSS is a system for expressing the severity of a security vulnerability. A score of 10.0 is the maximum rating. It indicates that the flaw has especially serious consequences and can be exploited under highly dangerous conditions. In this incident, the vulnerability allowed arbitrary PHP code execution on vulnerable WordPress websites.

Unauthenticated means the attacker does not need a WordPress account or prior login. The attacker could request a valid nonce from the unauthenticated bricksforge_regenerate_nonce AJAX endpoint, upload a crafted file, and submit manipulated form data. The server then trusted an attacker-controlled URL field.

Remote code execution means the attacker’s code runs on the target server rather than only on the attacker’s own device. The article reports that successful exploitation could enable site takeover, web shells, sensitive-data access, and persistent access. Patches were released in Bricksforge 3.1.8.10, and users were advised to update to 4.0.1.

The exploit abused a mismatch between what Bricksforge checked during upload and what it trusted during form submission. The initial upload passed MIME validation because the file was a valid image. However, the later submission included a temporaryFileUploads parameter whose URL field was not properly validated.

Attackers first obtained a nonce, then uploaded a GIF/PHP polyglot containing both image data and PHP code. They submitted a form with the file path pointing to the validated GIF in Bricksforge’s temporary directory. At the same time, they supplied a URL ending in .php, such as a PHP-named path. Bricksforge copied the image file’s contents to that location.

The resulting file still contained the embedded PHP code, but now had an executable PHP-style name. When someone requested it, the server could execute the code. Patchstack observed attacks against the REST form endpoint and the admin AJAX form-submission action. Version 4.0.1 was recommended for protection.

The observed exploitation was distributed across 63 unique source IP addresses. Patchstack identified two notable activity clusters. One involved 44 IPs sending 56 requests with identical payloads within seconds. Another involved three IPs testing 25 PHP-extension and encoding variations against the same temporary file.

Six source addresses accounted for roughly 46% of all requests. The listed addresses were 177.75.57[.]20, 23.97.62[.]146, 84.247.60[.]125, 38.154.185[.]97, 150.109.16[.]166, and 153.75.90[.]146. The repeated payloads and rapid testing indicate automated exploitation rather than isolated manual activity.

Patchstack said the patterns pointed to rotating proxies or distributed infrastructure. It also cautioned that the patterns did not, by themselves, attribute the activity to one threat actor. Exploitation was detected on October 7, 2026, at 9:47 p.m. UTC. Site owners should audit suspicious form submissions and unexpected PHP files.

PHP execution means attacker-supplied instructions run on the WordPress server. Because the vulnerable plugin handled uploads and form submissions within the website’s environment, successful exploitation could affect more than one form or temporary file. It could provide a path toward controlling the site itself.

The article lists several consequences. Attackers could seize control of the WordPress site, deploy web shells, read sensitive data, and establish persistent access. A web shell can provide a convenient way to send further commands through a web request, while persistent access helps an attacker return after some immediate activity ends.

The observed Bricksforge flaw was especially serious because it was remotely exploitable without authentication. Attackers targeted form-submission endpoints with crafted temporaryFileUploads data. Site owners were advised to update to Bricksforge 4.0.1, review incoming requests, watch for repeated submissions, and search the temporary upload directory for unexpected PHP files.

The attackers were trying to get a PHP payload accepted and executed despite extension filtering. A basic defense may look for the exact string .php. If it rejects only that spelling, other representations can provide alternate paths for testing. The article records this behavior during active exploitation of Bricksforge.

Observed variations included .php5, .php7, and .phtml, along with capitalized forms such as .PHP, .Php, and .pHp. Attackers also tried encoded forms, including .%70hp, %2ephp, and .%2570%2568%2570. These attempts targeted the mismatch between filtering and later interpretation of the filename or URL.

Patchstack reported that three IPs tested 25 variations of PHP extensions and encodings against the same temporary file. This suggests automated probing for a form the application or server would accept. The activity reinforces why file validation must examine trusted server-side paths and normalized names, not merely rely on a client-supplied extension string.

When configured for PHP, a web server passes a requested PHP file to the PHP interpreter instead of returning it as ordinary download content. The interpreter runs PHP code and sends the result back through the server. This explains why a filename ending in a recognized PHP extension can be dangerous. The article states that embedded code executed when the PHP-named file was requested.

Bricksforge initially checked the uploaded file’s MIME type, so a GIF/PHP polyglot could enter the temporary directory as an image. During form submission, however, it trusted the client-supplied url field inside temporaryFileUploads. An attacker could keep the file path pointing to the GIF while choosing a PHP-style destination.

That is a fundamental security risk because clients control submitted data. Server-side code must verify the actual file, destination, and allowed type rather than trusting metadata supplied by a browser or script. In this case, the mismatch enabled arbitrary PHP execution without authentication. The fix was released in Bricksforge 3.1.8.10.