CVE-2026-14270: WordPress Plugin RCE Vulnerability

CVE-2026-14270 Overview

CVE-2026-14270 affects the Extra Checkout Options plugin for WordPress, an addon for Extra Product Options & Add-Ons for WooCommerce. The vulnerability enables authenticated attackers with Subscriber-level access or higher to upload arbitrary PHP files and achieve remote code execution. The flaw exists in all versions up to and including 2.3.2. The root cause is missing authorization and nonce validation in the eco_save_settings() function, combined with insufficient authorization on the wc_eco_upload_file AJAX action. This vulnerability is classified as [CWE-434] Unrestricted Upload of File with Dangerous Type. The vendor released a partial fix in version 2.3.2.

Critical Impact
Authenticated attackers with minimal Subscriber privileges can achieve full remote code execution on affected WordPress sites, leading to complete server compromise.

Affected Products

Extra Checkout Options (addon for Extra Product Options & Add-Ons for WooCommerce) plugin for WordPress
All versions up to and including 2.3.2
WooCommerce-enabled WordPress sites using this addon

Discovery Timeline

2026-07-29 - CVE-2026-14270 published to NVD
2026-07-30 - Last updated in NVD database

Technical Details for CVE-2026-14270

Vulnerability Analysis

The vulnerability chains two distinct authorization failures within the Extra Checkout Options plugin. The eco_save_settings() function lacks both capability checks and nonce validation. This allows any authenticated user to modify plugin settings, including the tc_eco_custom_file_types upload allowlist. An attacker adds php to the permitted file extensions.

The second flaw resides in the wc_eco_upload_file AJAX handler. This action performs insufficient authorization checks and relies on a frontend upload nonce that is exposed on cart and checkout pages. Any authenticated visitor can retrieve this nonce and invoke the upload endpoint.

Once the allowlist accepts PHP files, the attacker uploads a PHP payload through the frontend upload endpoint. The web server executes the uploaded file, granting remote code execution under the WordPress process context. This provides full site compromise, database access, and a foothold for lateral movement.

Root Cause

The root cause is broken access control combined with missing CSRF protection. The eco_save_settings() function does not verify user capabilities using current_user_can() and omits check_ajax_referer() nonce validation. The upload allowlist becomes writable by low-privileged users. The wc_eco_upload_file action similarly fails to enforce role-based authorization before processing uploaded content.

Attack Vector

The attack requires network access and a Subscriber-level WordPress account, which many WooCommerce sites grant by default for customer registration. The attacker first sends a request to eco_save_settings() to add php to tc_eco_custom_file_types. The attacker then loads the cart or checkout page to harvest the frontend upload nonce. Finally, the attacker submits the PHP webshell to wc_eco_upload_file and requests the uploaded file to trigger execution. No user interaction is required beyond the attacker's own authenticated session.

See the Wordfence Vulnerability Report for additional technical details.

Detection Methods for CVE-2026-14270

Indicators of Compromise

Unexpected .php files in the WordPress uploads directory, particularly in plugin-specific subdirectories under wp-content/uploads/
Modifications to the tc_eco_custom_file_types option in the wp_options database table adding PHP or other executable extensions
POST requests to admin-ajax.php with action=eco_save_settings or action=wc_eco_upload_file originating from Subscriber accounts
Outbound network connections from the web server to unfamiliar hosts following upload activity

Detection Strategies

Monitor WordPress option changes for the tc_eco_custom_file_types key and alert on additions of executable file types
Inspect webserver access logs for sequential requests to eco_save_settings followed by wc_eco_upload_file from the same session
Deploy file integrity monitoring on wp-content/uploads/ to detect new PHP files
Correlate low-privileged user authentication events with subsequent admin-ajax activity

Monitoring Recommendations

Enable WordPress audit logging for plugin settings changes and file uploads
Alert on any PHP file execution originating from user-controlled upload directories
Track process creation from the web server user account for unexpected shell or interpreter invocations
Review Subscriber-role account creation patterns for anomalous registration bursts preceding attacks

How to Mitigate CVE-2026-14270

Immediate Actions Required

Deactivate the Extra Checkout Options plugin until a fully patched version is available, as version 2.3.2 only partially addresses the flaw
Audit all WordPress user accounts and remove untrusted Subscriber-level accounts created recently
Scan wp-content/uploads/ for unauthorized PHP files and remove them
Reset the tc_eco_custom_file_types option to allow only non-executable file extensions

Patch Information

The vendor released version 2.3.2 as a partial fix. According to the Wordfence Vulnerability Report, the vulnerability is not fully remediated in 2.3.2. Administrators should monitor the CodeCanyon Plugin Details page for a complete patch release and apply it immediately when available.

Workarounds

Restrict WordPress registration to prevent unauthenticated users from obtaining Subscriber accounts
Configure the web server to deny PHP execution within wp-content/uploads/ using directory-level rules
Deploy a web application firewall rule that blocks POST requests to admin-ajax.php with the eco_save_settings and wc_eco_upload_file actions from non-administrator sessions
Enforce filesystem permissions that prevent the web server user from writing executable content to upload directories

bash

# Apache: block PHP execution in uploads directory
# Add to .htaccess in wp-content/uploads/
<FilesMatch "\.(php|phtml|php3|php4|php5|php7|phar)$">
    Require all denied
</FilesMatch>

# Nginx equivalent (in server block)
location ~* /wp-content/uploads/.*\.php$ {
    deny all;
    return 403;
}