What happened
CVE-2026-27540 is a critical arbitrary file upload vulnerability affecting WooCommerce Wholesale Lead Capture, a premium WordPress plugin used to build wholesale customer registration and lead-capture workflows. The vulnerability affects versions through 2.0.3.1 and can be exploited remotely by an unauthenticated attacker.
The flaw carries a CVSS 3.1 score of 9.8 and is classified as an unrestricted upload of a file with a dangerous type. A corrected release is available in version 2.0.3.2. Security researcher Teemu Saarentaus discovered the issue, and the vulnerability was publicly disclosed in February 2026.
Despite a patch being available for months, exploitation has continued. The Hacker News reported on September 16 that Wordfence had blocked more than 100,000 attempts targeting CVE-2026-27540 since June, including additional activity during the previous 24 hours. Attackers have been observed attempting to upload executable PHP web shells to vulnerable WordPress installations.
Successful exploitation can give an attacker server-side code execution without first obtaining a WordPress account. From there, the attacker may be able to modify files, establish persistence, access credentials available to WordPress, create administrator accounts, alter WooCommerce content, or use the compromised server to distribute additional malicious content.
How the vulnerability works
WooCommerce Wholesale Lead Capture supports file uploads as part of wholesale registration workflows. File upload features must enforce their security rules on the server because filenames, extensions, MIME types, and other values supplied by the visitor cannot be trusted.
The vulnerable plugin exposes an AJAX action named wwlc_file_upload_handler. The action is reachable by unauthenticated users and processes uploaded files. The problem is that affected versions allow the incoming request to influence the list of file extensions that the application considers acceptable.
The handler uses a request value named file_settings. Instead of relying only on a trusted server-side configuration to determine which file types are allowed, the vulnerable code accepts the allowed file types from this user-controlled input. An attacker can therefore claim that PHP is an approved file extension.
In simplified form, the vulnerable workflow looks like this:
Unauthenticated visitor
|
v
Public WordPress AJAX action
|
v
Attacker-controlled file_settings
|
v
Dangerous extension treated as allowed
|
v
PHP file written to server
|
v
Uploaded PHP requested by attacker
|
v
Remote code executionThe underlying security failure is a broken trust boundary. The request providing the potentially dangerous file is also able to influence the rule used to decide whether that file is acceptable.
What attackers are doing
The active exploitation observed by Wordfence uses crafted requests sent to the WordPress AJAX endpoint at /wp-admin/admin-ajax.php. The request specifies the vulnerable wwlc_file_upload_handler action and manipulates the file settings so that PHP is treated as an allowed upload type.
Attackers have been observed attempting to upload a file named shell.php. The resulting file acts as a web shell that can display information about the compromised server and provide a browser-based interface for writing additional files.
The filename is useful as an indicator of compromise, but it is not a complete detection method. Attackers can change filenames, upload other web shells, modify existing PHP files, or use the initial shell to place more persistent code elsewhere on the WordPress installation.
An uploaded web shell can turn a single vulnerable plugin into a broader server compromise. The attacker is no longer limited to the registration form or the plugin's normal functionality once arbitrary PHP is executing.
Why arbitrary file upload is dangerous
WordPress is built primarily on PHP. If an attacker can place a PHP file in a directory where the web server permits PHP execution, requesting that file can cause the server to execute the attacker's code.
This differs from uploading a normal image, PDF, or spreadsheet. A legitimate upload is meant to remain data. An executable web shell becomes a program running under the permissions of the website's PHP process.
Depending on hosting configuration, this may expose wp-config.php, database credentials, plugin and theme files, customer data, API keys, SMTP credentials, payment integration settings, and other secrets available to the application.
Remote code execution can also be used to create additional persistence. An attacker may modify legitimate plugins, create hidden administrator accounts, install malicious must-use plugins, inject JavaScript into customer-facing pages, redirect visitors, or place additional backdoors that remain after the original uploaded file is removed.
Affected versions and fix
The affected and corrected versions are clearly defined:
WooCommerce Wholesale Lead Capture 2.0.3.1 and earlier: AFFECTED
WooCommerce Wholesale Lead Capture 2.0.3.2 and later patched releases: FIXEDAdministrators should update to version 2.0.3.2 or a newer supported version. If the plugin is no longer required, removing it entirely reduces unnecessary attack surface.
A web application firewall can provide additional protection against known exploit patterns, but it should not replace installing the fixed plugin. The vulnerable upload logic remains present until the component itself is updated or removed.
Administrators should also establish when the site was patched. A website that is now running 2.0.3.2 may still require investigation if it was exposed on an older release during the period of known exploitation.
Why it matters for website owners
WooCommerce sites often contain significantly more sensitive business data than a simple brochure website. Customer records, order information, wholesale pricing, shipping information, integration credentials, and payment-related configuration may all be accessible to the WordPress application.
The plugin itself has an estimated 6,000 active installations, which is relatively modest compared with WordPress's largest extensions. That does not reduce the risk to an individual site. Automated attackers scan broadly for vulnerable software and do not need to know anything about the organization before attempting exploitation.
The lack of an authentication requirement is especially important. Attackers do not need to steal a password, register a customer account, or persuade an administrator to click a link. The vulnerable file handling functionality can be reached directly over the network.
Because exploitation is confirmed in the wild, administrators should treat vulnerable historical exposure differently from a vulnerability discovered only in laboratory testing. Updating closes the flaw but does not erase changes an attacker may already have made.
What to check on your site
- Confirm whether WooCommerce Wholesale Lead Capture is installed. Check production, staging, development, archived, and cloned WordPress environments.
- Check the plugin version. Versions 2.0.3.1 and earlier are affected. Update to 2.0.3.2 or a newer patched release.
- Determine when the site was patched. If a vulnerable version was exposed during the active exploitation period, perform retrospective checks.
- Inspect upload directories. Look for unexpected or recently created PHP files, particularly in locations normally intended for user uploads.
- Search for observed web-shell names. Check for
shell.php, but do not rely on this filename alone. - Review access logs. Investigate requests to
/wp-admin/admin-ajax.phpwhere the action iswwlc_file_upload_handler. - Review administrator accounts. Look for unfamiliar users, unexpected password changes, new administrators, or unexplained privilege increases.
- Inspect plugins and themes. Compare important PHP files against trusted vendor copies where compromise is suspected.
- Check persistence locations. Review must-use plugins, scheduled tasks, configuration files, and other locations attackers may use after obtaining code execution.
- Review credentials after confirmed compromise. Credentials accessible to WordPress should be considered potentially exposed if a web shell executed successfully.
Recommended response
The first step is to update WooCommerce Wholesale Lead Capture to version 2.0.3.2 or later. If that cannot be completed immediately, disabling the plugin can reduce exposure while remediation is prepared.
Sites that ran an affected release during the known attack period should then be checked for signs of compromise. Do not assume that installing the latest version proves the server is clean.
If an unexpected PHP file is discovered, determine whether it was requested or executed. Deleting the initial file alone may not remove additional payloads or persistence created after exploitation.
Where compromise is confirmed, review the entire WordPress installation and hosting environment. Replace modified application files with trusted copies, remove unauthorized users and backdoors, inspect logs, and rotate database, hosting, WordPress, API, email, and other credentials that may have been accessible to the compromised PHP process.
Reducing file upload risk
File upload security must be controlled by the server. A browser can provide metadata about an uploaded file, but those values should be considered untrusted input.
Applications should define permitted file types using a server-controlled allowlist. Filename extensions and MIME types should be validated independently where practical, server-generated filenames should be used, and uploaded files should be stored with restrictive permissions.
Where the hosting architecture allows it, directories intended for user uploads should also be configured so PHP and other server-side scripts cannot execute from them. This creates an additional barrier if an application-level validation problem allows an executable file to reach storage.
Unused upload functionality should be removed or disabled. Public upload endpoints expand the attack surface because they accept attacker-controlled content by design.
Using Vulnify for WordPress review
The WordPress Stack Checker can help identify publicly detectable WordPress components and provide an external view of the technology exposed by a site. This is useful when reviewing multiple WordPress properties and deciding which installations need closer plugin inventory checks.
For CVE-2026-27540, external scanning should be combined with direct WordPress, filesystem, and log review. A public-surface scanner cannot reliably determine whether a PHP web shell executed several weeks earlier or whether an attacker subsequently established persistence elsewhere on the server.
The WordPress Security Hardening Checklist provides broader guidance for managing WordPress plugins, reducing unnecessary functionality, protecting administrative access, and reviewing exposed components.
Related reading
Conclusion
CVE-2026-27540 is a critical example of why upload validation must be enforced independently of user-controlled request data. Vulnerable versions of WooCommerce Wholesale Lead Capture allow unauthenticated visitors to influence the list of approved file types, creating a path to placing executable PHP on the server.
Versions through 2.0.3.1 are affected and version 2.0.3.2 contains the fix. The vulnerability is being actively exploited, with Wordfence reporting more than 100,000 blocked attempts since June.
Administrators should update immediately, but remediation should not end there if an affected release was previously exposed. Review upload directories, server logs, administrator accounts, and application files for signs of compromise, and investigate further if evidence indicates that arbitrary PHP executed on the server.