CVE-2025-12846: Blocksy Companion WordPress RCE Vulnerability

CVE-2025-12846 Overview

CVE-2025-12846 is an authenticated arbitrary file upload vulnerability in the Blocksy Companion plugin for WordPress, affecting all versions up to and including 2.1.19. The flaw resides in the plugin's SVG file handling logic, which performs insufficient file type validation. Attackers can craft files with double extensions that bypass the sanitization routine while still being accepted as valid SVG files. Authenticated users with author-level access or above can exploit this flaw to upload arbitrary files to the affected site's server. Successful exploitation may lead to remote code execution on the underlying host. The vulnerability is classified under CWE-434: Unrestricted Upload of File with Dangerous Type.

Critical Impact
Authenticated attackers with author-level access can upload arbitrary files using double-extension bypass, potentially leading to remote code execution on the WordPress server.

Affected Products

Blocksy Companion plugin for WordPress, all versions up to and including 2.1.19
WordPress sites granting author-level access or higher to untrusted users
WordPress deployments using Blocksy Companion's SVG upload feature

Discovery Timeline

2025-11-11 - CVE-2025-12846 published to the National Vulnerability Database (NVD)
2026-06-17 - Last updated in the NVD database

Technical Details for CVE-2025-12846

Vulnerability Analysis

The vulnerability stems from incomplete file type validation inside the plugin's SVG handling logic, located in framework/features/svg.php. The plugin attempts to permit SVG uploads by inspecting file content for SVG markers. However, the validation does not enforce strict extension checks. Attackers can submit files with double extensions such as payload.php.svg or shell.svg.phtml and pass the SVG content inspection. The web server then interprets the file according to its executable extension rather than its claimed type. This bypass turns a content-type check into a code execution primitive when combined with PHP-handling extensions.

Root Cause

The root cause is improper input validation [CWE-434] in the SVG sanitization routine. The plugin verifies that uploaded content matches SVG markup patterns but does not reject filenames containing additional extensions before or after .svg. WordPress's media library accepts the file as SVG, while Apache or NGINX may execute it based on the secondary extension. The validation logic conflates content inspection with safe storage, which leaves the upload pipeline open to extension confusion attacks.

Attack Vector

An attacker first authenticates to the target WordPress site with an account holding author-level capabilities or higher. The attacker then uses the media upload endpoint to submit a crafted file containing valid SVG markup but named with a double extension. The plugin accepts the file, and the server stores it within the uploads directory. The attacker requests the file directly via its URL, triggering server-side interpretation of the embedded code. This grants the attacker code execution under the web server's user context, enabling further compromise of the site and database.

No verified public proof-of-concept code is available. Technical detail can be reviewed in the WordPress Change Log Update and the Wordfence Vulnerability Report.

Detection Methods for CVE-2025-12846

Indicators of Compromise

Files in wp-content/uploads/ with double extensions such as .php.svg, .svg.phtml, or .svg.php
New or modified files in the uploads directory created by author-level or contributor accounts
Outbound network connections from the web server process to unfamiliar destinations following an SVG upload
Web shell strings such as eval(, base64_decode(, or system( appearing inside files served as SVG

Detection Strategies

Audit the WordPress media library and uploads directory for files containing more than one extension separator
Review web server access logs for POST requests to /wp-admin/async-upload.php followed by direct GET requests to newly created upload paths
Inspect installed Blocksy Companion plugin versions across managed WordPress fleets and flag any at or below 2.1.19
Correlate author or editor account logins with file upload events to surface anomalous publishing activity

Monitoring Recommendations

Enable file integrity monitoring on the wp-content/uploads/ directory to alert on creation of executable file types
Forward WordPress audit logs and web server access logs to a centralized SIEM for retention and correlation
Alert on PHP execution originating from paths under wp-content/uploads/, which should never occur under normal operation
Monitor for privilege use by author-level accounts that historically only published text content

How to Mitigate CVE-2025-12846

Immediate Actions Required

Update the Blocksy Companion plugin to the version released after 2.1.19 that addresses this issue
Audit all author-level and higher accounts and remove accounts that are no longer required
Scan the uploads directory for files with double extensions and quarantine any matches for forensic review
Rotate WordPress administrator credentials and database passwords if compromise is suspected

Patch Information

The vendor addressed the vulnerability in the plugin source tree. The fix is documented in the WordPress Change Log Update, which strengthens validation in framework/features/svg.php. Administrators should upgrade through the WordPress plugin updater or by replacing plugin files from the official repository.

Workarounds

Disable SVG upload functionality within the Blocksy Companion plugin until the patch is applied
Restrict author-level and higher accounts to trusted users only and require multi-factor authentication
Configure the web server to deny PHP execution within wp-content/uploads/ using directory-level handler rules
Place a Web Application Firewall (WAF) in front of WordPress to block requests containing double-extension filenames

bash

# Example NGINX configuration to block script execution in uploads
location ~* /wp-content/uploads/.*\.(php|phtml|phar|pl|py|jsp|asp|sh|cgi)$ {
    deny all;
    return 403;
}