If your online shop runs on WooCommerce and uses the Wholesale Lead Capture plugin to sign up trade customers, treat this as urgent. CVE-2026-27540 is a critical, unauthenticated vulnerability, rated CVSS 9.0, that lets anyone on the internet upload a PHP webshell and take full control of the store. Wordfence has already blocked more than 100,000 attempts to exploit it. For a merchant in Cyprus or anywhere in the EU, this is not just a website problem. The moment card data and customer records are in reach, it becomes a GDPR and PCI DSS problem too.
The flaw, in plain terms
The plugin exposes an AJAX action, wwlc_file_upload_handler, that accepts file uploads during wholesale registration. Two things make it dangerous. First, it can be reached without logging in, so an attacker needs no account. Second, and this is the real defect, the plugin decides which file types are allowed by reading a list from a request parameter the attacker controls, file_settings — rather than from a fixed configuration on the server.
In other words, the same person uploading the file also gets to define the rules for what counts as a safe file. Add “php” to that list, send a PHP script, and the plugin accepts it as valid. The script is now on the server and executable, which gives the attacker remote code execution as the web server user. From a webshell, everything the site can touch is theirs.
| Detail | Value |
|---|---|
| CVE | CVE-2026-27540 |
| CVSS | 9.0, critical |
| Plugin | WooCommerce Wholesale Lead Capture (premium) |
| Flaw | unauthenticated arbitrary file upload → PHP webshell |
| Affected | version 2.0.3.1 and earlier |
| Fixed in | version 2.0.3.2 (released 20 February 2026) |
| In the wild | 100,000+ attempts blocked by Wordfence; ~6,000 sites affected |
For an EU merchant, this is a data-protection incident
A webshell on a store does not just deface a page; it sits on the machine that processes orders and holds your customers. That is where the compliance weight lands. Under the GDPR, a breach that exposes customer personal data — names, addresses, order history, contact details — is a reportable event, and the clock to notify the supervisory authority runs to 72 hours from the moment you become aware. “We were exploited through an outdated plugin” is not a mitigating explanation; failing to keep the software you chose to run up to date is part of what regulators weigh.
The stakes rise further if you take card payments. A compromise of the environment that handles cardholder data is squarely a PCI DSS matter, and for larger operators in regulated sectors the NIS2 directive adds its own incident-reporting duties. For a Cyprus business serving EU customers, the health of every plugin on a WooCommerce site is therefore not only an IT question but a legal one. That is exactly the gap a web application penetration test is designed to close before an attacker forces the issue.
The payment skimmer is the quiet killer
Defacement is loud and gets noticed. The outcome that actually ruins merchants is silent. With code execution on the store, an attacker can inject a payment skimmer into the checkout, so that every card number a customer types is copied to them in real time while the shop keeps working normally. These skimmers can run for weeks before anyone spots them, quietly harvesting cards, and the damage surfaces later as fraud reports, chargebacks and a mandatory breach disclosure.
This is the Magecart pattern, and WooCommerce stores are a natural target for it because so much trust and money flows through a stack assembled from third-party plugins. Any one of those plugins, if vulnerable, is a way onto the checkout. Reviewing the code that touches payment and the endpoints that accept input is precisely the work of a secure code review and an API penetration test, and it is far cheaper than the aftermath of a skimming campaign.
The patch existed — the exposure is operational
Here is the uncomfortable truth. The developers fixed this in version 2.0.3.2, released back on 20 February. The 100,000-plus blocked attacks and the ongoing exploitation are hitting sites that simply never installed the update. This is not a story about unpatched software so much as patched software nobody applied, and premium plugins make it worse: updates often require an active licence and a manual click, so they quietly drift out of date while the shop keeps selling.
That pattern is behind most WordPress and WooCommerce compromises. A flaw is disclosed, a fix ships, automated exploitation follows within days, and the sites that fall are the ones running the old version weeks or months later. What decides who gets breached is not whether a patch exists but how fast it is applied — and how quickly you would even notice a webshell if one landed. An assumed-breach assessment answers that second question honestly, by testing how far an intruder gets once they are already inside.
What to do now
- Update WooCommerce Wholesale Lead Capture to 2.0.3.2 or later at once. If you cannot update immediately, deactivate the plugin until you can.
- Assume compromise if you were exposed. Inspect the uploads directory and the wider site for unfamiliar PHP files, recently changed files and unexpected scheduled tasks — a webshell usually leaves a trace.
- Review the checkout specifically for injected scripts, and audit administrator accounts and API keys for anything you did not create. Rotate credentials and payment-gateway keys if there is any doubt.
- Map what is exposed. Know which plugins you run, which are current, and what faces the internet — a question an external penetration test answers directly.
- If customer or card data may have been taken, start your GDPR clock deliberately rather than by surprise, and document the timeline; the 72-hour window is unforgiving.
The bottom line
CVE-2026-27540 is a clean chain: an unauthenticated endpoint, a file-type allowlist the attacker gets to set, a PHP webshell, and then the whole store. The fix has been available since February, so the only reason it is still claiming victims is the gap between a patch existing and a patch being installed — and on an EU store that gap is measured in exposed customers, skimmed cards and regulatory deadlines, not just downtime. Update to 2.0.3.2 today, hunt for anything already dropped, and treat every third-party plugin on a site that handles money as part of your attack surface. If you are not certain your store is clean or your compliance obligations are covered, talk to our team and find out before the next 100,000 attempts include one that lands.