Webshell campaign exploits critical WooCommerce plugin flaw

Attackers are actively exploiting a critical vulnerability in the WooCommerce Wholesale Lead Capture plugin to upload PHP webshells onto WordPress sites, with more than 100,000 exploit attempts blocked since June, Wordfence data shows.

The flaw, tracked as CVE-2026-27540, affects versions 2.0.3.1 and earlier of the premium plugin and allows unauthenticated attackers to upload arbitrary files to a vulnerable server. Wordfence rates the bug 9.8 on the CVSS severity scale, while the CVE record issued by Patchstack carries a 9.0 score.

The scoring difference reflects contrasting assessments of attack complexity. Wordfence treats exploitation as low complexity, while the CVE vector used by Patchstack rates attack complexity as high. Both assessments classify the flaw as critical because successful exploitation can result in remote code execution and full compromise of an affected website.

Wordfence said its firewall has blocked more than 100,000 attempts aimed at the vulnerability, with the heaviest activity recorded between June 4 and June 17 and further spikes on July 1 and August 30. Security researchers have also observed attackers using the flaw to plant a file commonly named shell. php, which functions as a webshell.

The uploaded PHP file can report host information and provide a browser-based interface for placing additional files on the compromised server. That gives attackers a foothold for reconnaissance and creates a route for installing further malicious code, establishing persistence or altering website content.

The vulnerability exists in an AJAX action called wwlcfileupload_handler, which processes files submitted through the plugin’s wholesale registration functionality. The upload routine checks file extensions against an allowlist, but the allowed types are drawn from data supplied in the incoming request rather than being enforced exclusively through trusted server-side configuration.

That design allows an unauthenticated attacker to submit crafted settings that add the php extension to the permitted list. The plugin then passes the uploaded file to WordPress with its own type checking disabled, leaving the attacker-influenced extension validation as the effective barrier.

The vulnerability was disclosed on February 20 by researcher Teemu Saarentaus and was fixed the same day in version 2.0.3.2. Wordfence added the issue to its vulnerability database on February 25 and introduced a firewall rule for its premium protection tiers on February 27. Users of the free Wordfence service received the corresponding rule on March 29.

Patchstack’s vulnerability entry also identifies version 2.0.3.2 as the patched release and classifies the issue as an unauthenticated arbitrary file-upload flaw. The associated CVE record assigns the weakness to unrestricted upload of a dangerous file type, a class of bug that can be especially severe when the server executes the uploaded content.

The affected software is a third-party WooCommerce extension developed by Rymera Web Co Pty Ltd and is separate from WooCommerce core. The plugin is designed to manage wholesale customer registration and onboarding, including collection of information and files from prospective business customers.

The campaign illustrates why patch availability alone does not end exposure. Sites may remain on older premium-plugin releases because updates depend on vendor licensing and maintenance practices rather than the WordPress. org repository. Wordfence estimates the plugin has more than 6,000 active installations, making even a modest proportion of unpatched sites a useful target for automated scanning. The observed waves show attackers returning repeatedly after the fix became widely available.

Wordfence has urged administrators running an affected release to update to version 2.0.3.2 or later and to examine sites that remained unpatched after the February fix. A firewall can block known exploit patterns, but it does not remove malicious files already placed on a server before protection was enabled or an update was installed.

Site owners have been advised to inspect upload directories and other writable locations for unexpected PHP files, particularly files created during the identified attack windows. Access logs should also be checked for requests to wp-admin/admin-ajax. php invoking the wwlcfileupload_handler action.