Critical WooCommerce Plugin RCE Exploited at Scale: WordPress AJAX Handler Failures Strike Again

As reported by The Hacker News, threat actors are actively exploiting a critical arbitrary file upload vulnerability in the WooCommerce Wholesale Lead Capture plugin, tracked as CVE-2026-27540 (CVSS 9.8). Wordfence reports blocking over 100,000 exploit attempts since June 2026. The same disclosure cycle revealed two additional critical RCE vulnerabilities in The Events Calendar plugin, affecting over 600,000 sites. Together, these represent a concentrated wave of attacks against the WordPress plugin ecosystem.

Vulnerability Summary

Why This Pattern Keeps Repeating

The WooCommerce vulnerability stems from a fundamentally familiar failure: an AJAX action (wwlc_file_upload_handler) registered via WordPress's wp_ajax_nopriv_* hook, making it accessible to unauthenticated users, combined with absent server-side file type validation. This is not a novel attack vector — it is a recurring architectural anti-pattern in WordPress plugin development.

What makes this exploitation notable is the scale and persistence. Over 100,000 blocked attempts over roughly three months indicates automated, opportunistic scanning rather than targeted attacks. The threat actors are casting a wide net across the WordPress ecosystem, knowing that a subset of sites will be running vulnerable plugin versions with outdated configurations.

The core issue: WordPress's AJAX architecture allows plugins to register handlers accessible to unauthenticated users via the nopriv hook prefix. When developers combine this with file upload functionality and skip server-side MIME validation, the result is a pre-auth RCE — the most severe class of web vulnerability.

Who Is Most at Risk

Immediate Actions

• Update WooCommerce Wholesale Lead Capture to the latest available version immediately. If no patched version exists, disable the plugin as a stopgap.
• Update The Events Calendar to a version newer than 6.17.3.
• Hunt for web shells: Search the wp-content/uploads/ directory for unexpected .php files. Use find . -name "*.php" -newer /reference/file to identify recently created files.
• Review web server logs for POST requests to /wp-admin/admin-ajax.php with action=wwlc_file_upload_handler. Block and investigate hits from the known malicious IPs.
• Disable file uploads in the plugin settings if business operations permit.

Shield53 Recommendations

Beyond patching the immediate vulnerabilities, organizations running WordPress at scale should implement structural defenses:

• Deploy a WAF with virtual patching — solutions like Cloudflare, Sucuri, or AWS WAF can block malicious AJAX requests before they reach the application, buying time during patch cycles.
• Restrict wp-admin/admin-ajax.php at the web server level for unauthenticated nopriv actions that don't require public access. Not all AJAX actions need to be publicly callable.
• Disable PHP execution in upload directories by adding .htaccess rules: <Files *.php> Deny from All </Files> within wp-content/uploads/. This renders uploaded web shells inert.
• Implement file integrity monitoring (FIM) on WordPress installations to detect new PHP files in non-core directories.
• Maintain a plugin inventory with version tracking and subscribe to vendor advisory feeds. The gap between vulnerability disclosure and patching is where exploitation occurs.
• Enforce least privilege on the web server — run PHP-FPM as a per-site user with minimal filesystem permissions to limit the blast radius of successful RCE.

The WordPress plugin ecosystem's scale — over 60,000 plugins — means these disclosure cycles will continue. Organizations must treat plugin management as a continuous security discipline, not a periodic maintenance task. The 100,000+ blocked exploitation attempts against a plugin with only 6,000 active installs demonstrate that attackers are not selective — they are systematic.