CVE-2024-3242: Brizy Page Builder RCE Vulnerability

CVE-2024-3242 Overview

The Brizy – Page Builder plugin for WordPress contains an arbitrary file upload vulnerability affecting all versions up to and including 2.4.43. The flaw resides in the validateImageContent function called via storeImages, which fails to validate file extensions before writing uploads to the server. Authenticated attackers with Contributor-level access or above can upload arbitrary files, potentially leading to remote code execution on the affected site. The vulnerability is classified as [CWE-434] Unrestricted Upload of File with Dangerous Type. Version 2.4.44 introduced partial mitigation by blocking .sh and .php extensions, and version 2.4.45 fully patches the issue.

Critical Impact
Authenticated Contributor accounts can upload executable files to WordPress servers running Brizy 2.4.43 or earlier, enabling arbitrary code execution under the web server context.

Affected Products

Brizy – Page Builder for WordPress, all versions ≤ 2.4.43
Brizy 2.4.44 (partial fix; blocks only .sh and .php)
Fully patched in Brizy 2.4.45

Discovery Timeline

2024-07-18 - CVE-2024-3242 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-3242

Vulnerability Analysis

The vulnerability exists in the Brizy plugin's image handling logic within editor/zip/archiver.php. The storeImages routine invokes validateImageContent to inspect uploaded content, but the function does not enforce an allow-list of safe extensions or reject dangerous server-executable file types. As a result, an attacker with Contributor privileges can supply a file whose name ends in .php, .phtml, .phar, or a shell extension, and the plugin will write it into a web-accessible directory. Once written, the file can be requested directly through the web server, causing the PHP interpreter to execute attacker-controlled code within the WordPress process context.

Root Cause

The root cause is missing file extension validation in validateImageContent. The function relied on content inspection alone without cross-checking the file name against an allow-list of image extensions. This is a classic [CWE-434] Unrestricted Upload of File with Dangerous Type weakness. The 2.4.44 changeset introduced a deny-list for .sh and .php, which was insufficient because other executable handlers such as .phtml, .phar, and .php7 remained permitted. Version 2.4.45 replaces the deny-list with a stricter validation model.

Attack Vector

Exploitation requires an authenticated account with Contributor role or higher on the target WordPress site. The attacker submits a crafted upload request to the Brizy editor endpoint that invokes storeImages, packaging a PHP payload with an image-like header or content. Because the extension is not enforced, the file lands in the plugin's asset directory under wp-content. The attacker then issues an HTTP request to the uploaded file's URL. The web server passes it to the PHP handler, granting remote code execution under the web server user. See the Wordfence Vulnerability Report and the WordPress Plugin Code Reference for technical details.

Detection Methods for CVE-2024-3242

Indicators of Compromise

Files with .php, .phtml, .phar, or .sh extensions written into wp-content/uploads/brizy/ or the plugin's asset directories.
Unexpected outbound network connections originating from the PHP-FPM or Apache worker process shortly after Contributor-level activity.
New or modified WordPress user accounts created without an administrator initiating the change.
HTTP POST requests to Brizy editor endpoints from Contributor accounts followed by direct GET requests to newly created files under wp-content.

Detection Strategies

Monitor web server logs for POST traffic to Brizy AJAX or REST endpoints followed by GET requests to newly created files in the uploads directory.
Deploy file integrity monitoring on wp-content/uploads to alert on any non-image file creation.
Use static scanners such as Wordfence, Sucuri, or wp-cli scans to detect PHP files placed inside upload directories.
Correlate authenticated Contributor sessions with subsequent file uploads that deviate from typical author behavior.

Monitoring Recommendations

Enable WordPress audit logging for user role activity, especially Contributor and Author uploads.
Alert on any process spawned by the web server user that executes system utilities such as sh, bash, curl, or wget.
Track HTTP referrer chains and user agents that repeatedly touch Brizy endpoints from the same IP.
Forward WordPress and web server logs to a centralized SIEM for retention and behavioral correlation.

How to Mitigate CVE-2024-3242

Immediate Actions Required

Upgrade the Brizy – Page Builder plugin to version 2.4.45 or later on every WordPress instance where it is installed.
Audit the wp-content/uploads/brizy/ directory and remove any file that is not a legitimate image asset.
Review Contributor, Author, and Editor accounts, revoke unused accounts, and rotate credentials for any account that showed suspicious upload activity.
Verify no unauthorized administrator accounts, scheduled tasks, or plugin modifications were introduced.

Patch Information

The vendor addressed the issue across two releases. Version 2.4.44 introduced a partial deny-list blocking .sh and .php extensions, tracked in Changeset 3086506. Version 2.4.45 fully patches the vulnerability, tracked in Changeset 3112878. Administrators should update directly to 2.4.45 or later rather than stopping at 2.4.44.

Workarounds

Deactivate the Brizy plugin until 2.4.45 can be deployed if patching cannot occur immediately.
Restrict Contributor and Author role assignments to trusted users only, since exploitation requires an authenticated session.
Configure the web server to deny PHP execution within wp-content/uploads using an Apache .htaccess rule or an Nginx location block.
Deploy a WordPress-aware web application firewall with rules that block execution of files under the uploads path.

bash

# Nginx: block PHP execution inside the WordPress uploads directory
location ~* /wp-content/uploads/.*\.(php|phtml|phar|php7|sh)$ {
    deny all;
    return 403;
}

# Apache: equivalent .htaccess placed in wp-content/uploads/
<FilesMatch "\.(php|phtml|phar|php7|sh)$">
    Require all denied
</FilesMatch>