Attackers have spent months trying to plant PHP backdoors on WooCommerce stores through a plugin flaw that has had a patch since February. Wordfence's firewall has now blocked more than 100,000 attempts at it.
The target is WooCommerce Wholesale Lead Capture, a premium WordPress plugin with an estimated 6,000 active installations that gives wholesale buyers a custom registration form. The flaw, CVE-2026-27540, carries a CVSS score of 9.8 and lets anybody on the internet upload a file of their choosing to the server, with no account and no password. Wordfence's István Márton published the attack data on September 14; the vulnerability itself was reported by researcher Teemu Saarentaus and disclosed publicly on February 20.
A file filter the attacker gets to write
The plugin exposes an upload handler that unauthenticated visitors can reach directly. It does check the uploaded file's extension against a list of permitted types, which sounds like the right thing to do. The problem is where that list comes from. It is read out of the request itself rather than from the form's settings stored on the server, so the attacker supplies both the file and the rules the file will be judged against.
Submit a list that includes php, and the check passes. The plugin then explicitly switches off WordPress's own file type test before writing the upload to disk, and the result is an executable PHP file sitting on the server.
The payload Wordfence observed is a small web shell, usually named shell.php, that reports the host's details and draws an upload form in the browser so the intruder can write further files whenever they like. From there the usual next moves are creating an administrator account, exfiltrating customer data, or simply taking the store over.
Months of attempts against a fix shipped in February
Wordfence added the flaw to its vulnerability database on February 25 and issued a firewall rule to paying customers on February 27. Sites on the free version received the same rule 30 days later, on March 29. Its telemetry shows attackers have been working this flaw for months, with heavy bursts between June 4 and June 17, and again on July 1 and August 30.
That timeline is the point. This is not a fresh disclosure being probed for the first time, it is a long running campaign against stores that never applied an update available seven months ago.
Check the uploads folder before you update
The patched version is 2.0.3.2, and anything up to and including 2.0.3.1 is vulnerable. Because a successful attack leaves a file behind, updating on its own is not enough for a site that may already have been hit. Wordfence recommends reviewing the site for unexpected or recently created .php files, especially inside the uploads directory, and checking web server access logs for requests to /wp-admin/admin-ajax.php carrying the plugin's file upload action. The most active sources of blocked requests were 92[.]241[.]13[.]213 and 31[.]59[.]129[.]150, each with more than 24,000 attempts, followed by 92[.]241[.]13[.]140, 23[.]137[.]105[.]214 and 23[.]180[.]120[.]140. An absence of such log entries does not prove a site is clean, so treat unknown administrator accounts and unfamiliar files as the stronger signal.
The ending is becoming routine on WordPress: an unauthenticated upload endpoint, a validation check the attacker controls, a web shell. We covered the same finish in the Super Forms plugin earlier this month, and a hash confusion bug that produced it in Gravity Forms before that. The plugins keep changing. The upload handler does not.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.