The immediate fix is version 2.0.3.2 or later, but an update by itself does not answer the more important question for administrators: whether attackers already wrote a backdoor to the server. The vulnerable upload handler lets a remote visitor plant executable PHP in the site’s upload area, which can provide a durable foothold for adding administrator accounts, stealing WooCommerce customer data, modifying checkout code, or installing further malware.
This is a WordPress and PHP server incident rather than a Windows client vulnerability, but it directly concerns Windows-based web teams, agencies, IIS administrators, and anyone using Windows workstations to manage a WordPress or WooCommerce estate. The operational lesson is familiar: patching closes the door; it does not remove someone already inside.
CVE-2026-27540 trusts a setting supplied by the attacker
According to Wordfence’s technical analysis, the vulnerable plugin exposes an unauthenticated WordPress AJAX action named wwlc_file_upload_handler. The handler was intended to support file submissions through a wholesale registration form—useful for B2B shops that ask applicants for resale certificates or business documentation.
The problem is that the code checked an uploaded file extension against an allowed file types list supplied in the HTTP request. Rather than relying solely on trusted server-side form configuration, it accepted a client-provided file_settings value. An attacker could tell the plugin that PHP was an allowed type, then upload a PHP file through WordPress’s admin-ajax.php endpoint.
Wordfence says the observed payload is commonly named shell.php. It reports basic host details and includes a browser-based file-upload capability, turning an initial upload into a staging point for additional malicious files. That is why “arbitrary file upload” should not be read as a narrowly limited document-upload bug: on a server configured to execute PHP from the destination directory, it can become remote code execution.
BleepingComputer independently described the same flaw and mechanism, reporting that the vulnerable component is reachable without authentication and that the attacker-controlled allowlist is central to the bypass. The public evidence supports a straightforward conclusion: stores still running a vulnerable release should assume that anonymous internet traffic can attempt a full server-side compromise, not merely abuse a registration workflow.
The patch record contains an important version discrepancy
The fix path looks simple at first glance. Wordfence lists versions through 2.0.3.1 as affected and identifies 2.0.3.2 as the patched release; Rapid7’s vulnerability database also directs administrators to update to 2.0.3.2 or newer. Wordfence says version 2.0.3.2 was released on February 20, 2026.
However, the vendor’s own current changelog adds a detail that administrators should not ignore. It lists version 2.0.3.1 with a line saying it fixed an unauthenticated arbitrary file-upload issue in wwlc_file_upload_handler, while listing version 2.0.3.2 more generally as “security issue fixes and hardening.” That directly conflicts with the vulnerability intelligence record stating that 2.0.3.1 remains affected.
The available records do not explain whether 2.0.3.1 contained an incomplete initial remediation, whether the changelog entry was attached to the wrong release, or whether another implementation detail left the bypass possible. Whatever the cause, the action is clear: do not regard 2.0.3.1 as safe because its changelog mentions a security fix. Use 2.0.3.2 as the minimum version, and move to the newest vendor-supported release where licensing permits.
There is a second discrepancy in severity reporting. Wordfence assigns CVE-2026-27540 a 9.8 CVSS score, while the CVE-derived record reflected by Rapid7 and GitHub’s advisory database shows 9.0. Both rate the issue as critical. The difference comes from distinct scoring assumptions rather than a disagreement over the underlying behavior: an unauthenticated, network-reachable upload of executable server-side code carries severe consequences even if deployment conditions influence whether PHP is executed.
The submitted report’s claim of more than 20,000 active installations also does not match Wordfence’s estimate of roughly 6,000 active installations for the premium Lead Capture component. The vendor markets its broader Wholesale Suite family as serving more than 25,000 stores, which is not evidence that every one of those stores runs this particular paid add-on. For defenders, the smaller estimate is no comfort. A few thousand business-to-business stores are a valuable target set because their registration forms can hold company details, tax information, customer contacts, order records, and payment-adjacent data.
The campaign began months after the patch window opened
Wordfence says it added the vulnerability to its intelligence database on February 25 and provided a firewall rule to paid Wordfence customers on February 27. The same rule reached the free edition 30 days later, on March 29. Yet the company’s firewall telemetry shows substantial attack activity from June through the end of August, months after the patch became available.
Its recorded spikes ran from June 4 through June 17, then on July 1 and August 30. More than 100,000 blocked attempts are a count of requests stopped by Wordfence-protected sites, not a count of confirmed compromises or unique victim sites. It nevertheless shows that attackers had working exploit traffic at scale and kept scanning for stores that had missed the update.
The timeline exposes a routine but costly weakness in premium WordPress plugin management. A WordPress core update may be visible in the dashboard, but commercial extensions are frequently governed by expired licenses, disabled automatic updates, disconnected staging-to-production processes, or agencies that no longer maintain a client’s store. A security patch released in February can therefore remain absent in September even where the software vendor has already shipped a correction.
The vendor’s product page says Lead Capture licenses include automatic updates for one year. That leaves a practical administration question unanswered for expired-license installations: whether they can retrieve the patched package normally, must renew first, or need support intervention. Organizations that cannot obtain a confirmed fixed build promptly should disable the plugin and remove or restrict public exposure of its registration page while they resolve access to the update.
Update first, then investigate for persistence
Administrators should update the plugin before performing a long forensic review, because leaving the vulnerable code online risks a new upload during the investigation. Take a backup or snapshot first if the hosting platform allows it, but do not let a backup workflow postpone the patch.
After the update, review the server rather than relying on the WordPress dashboard alone. Wordfence specifically recommends looking for recently created or unexpected .php files in upload locations; its observed samples used the name shell.php, but a filename is an unreliable indicator. Attackers can choose any name, timestamp, directory, or secondary payload after reaching the server.
A reasonable incident triage should include the following:
- Review web-server access logs for POST requests to
/wp-admin/admin-ajax.phpcontaining thewwlc_file_upload_handleraction, particularly from June 2026 onward. - Search
wp-content/uploadsand any plugin-specific temporary upload directories for PHP files, unusual nested directories, and files whose modification dates do not align with legitimate content uploads. - Compare WordPress administrator accounts, active plugins, mu-plugins, scheduled tasks, and theme files against a known-good baseline.
- Rotate WordPress administrator credentials, hosting-panel credentials, SFTP or SSH credentials, database passwords, API keys, and payment-provider secrets if a webshell or unauthorized administrator account is found.
- Preserve relevant access and PHP error logs before cleanup so an incident responder can determine when the intrusion began and what it accessed.
Do not assume that deleting a single webshell ends the incident. Wordfence explicitly warns that an attacker able to upload PHP can create administrator accounts and add other backdoors. In WooCommerce deployments, a compromise review should also cover checkout templates, payment gateway settings, customer exports, and any custom code loaded by the active theme. A small PHP implant can be only the first artifact of a broader fraud or data-theft operation.
Windows administrators should check the server role, not only WordPress
Teams using Windows Server and IIS for PHP-hosted WordPress sites should verify whether their server permits PHP execution under upload directories. The flaw’s impact is highest when a file placed in a WordPress uploads path is served through the PHP handler. Preventing script execution in upload locations can reduce the blast radius of this class of bug, though it does not replace updating the vulnerable plugin or checking for compromise.
That mitigation needs testing. Some WordPress extensions legitimately process files in ways that can break under blanket execution restrictions, and a PHP handler configuration varies across IIS FastCGI, Apache, Nginx with PHP-FPM, and managed hosting environments. Still, a production WordPress design that permits arbitrary PHP execution from publicly writable upload directories gives attackers an unusually direct path from one upload-validation failure to code execution.
The key date is February 20, 2026: that is when Wordfence says version 2.0.3.2 became available. Any site that remained on 2.0.3.1 or earlier after that date needs an investigation proportionate to a potential server compromise, because the active campaign did not merely probe a form—it attempted to place executable backdoors on business websites.