Third party plugin risk is not usually a technical problem. It is a management one. A patch for a critical flaw (CVE-2026-27540) in WooCommerce Wholesale Lead Capture has existed since 20 February. That patch closed a hole letting anyone on the internet upload a PHP web shell without logging in. Wordfence has still blocked more than 100,000 attempts to exploit it since June, with fresh waves in July and August, according to BleepingComputer’s reporting. Seven months of warning, and criminals are still finding sites that never applied it.
Table of Contents
Seven months, three attack waves, one patch
Lay the dates out and the pattern is stark. Rymera Web Co shipped the fix on 20 February. Nothing happened for months, because a patch sitting quietly in a changelog does not attract attention on its own. Then, starting in June, Infosecurity Magazine reports, Wordfence recorded exploitation waves on 4 to 17 June, 1 July and again on 30 August. Each wave was presumably a different group of attackers rediscovering the same opportunity in the same unpatched sites. The vulnerability itself did not get worse over that period. The population of sites still running it simply stayed large enough to be worth attacking, wave after wave.
The plugin nobody remembers installing
WooCommerce Wholesale Lead Capture is not a household name. A web agency typically installs it once, during a project to set up wholesale pricing tiers, then hands over a finished site and moves on. The client rarely knows it is there, let alone tracks whether it needs updating. That is exactly the profile of plugin that stays vulnerable long after a fix ships: nobody owns it, so nobody patches it.
Multiply that pattern across every WordPress site running dozens of plugins from different vendors, most bought for a single feature and forgotten the moment it worked. That is the real attack surface. It is exactly what let five separate WordPress plugins get hit with critical, no-login flaws in a single week earlier this year. This has nothing to do with how good WordPress’s core security team is. It has everything to do with who is watching the plugins list.
A patch is not protection, it is an offer
Security teams sometimes talk about vulnerabilities as though disclosure and patching are the end of the story. They are not. Between 20 February and the first recorded exploitation attempt in June, this bug sat there doing nothing, because nobody was attacking it yet. Then attackers noticed. Unpatched installs became a target list, and the count kept climbing through the summer.
A published fix only protects the sites that install it. Everything else stays exactly as exposed as it was the day the CVE was assigned. In this case, that means full remote code execution from a single unauthenticated request. It is the same shape of flaw that let an unauthenticated file upload compromise Forminator installs not long before this one.
Why third party plugin risk keeps getting ignored
Most businesses running WooCommerce treat the plugin list the way they treat the fuse box: fine as long as nothing trips it. Nobody reviews it unless something breaks. Core WordPress nags site owners with update notices they cannot ignore. Plugins rarely do. That gap explains why bugs like this one linger for months while platform-level flaws get patched within days.
The fix is not complicated. Somebody, whether an in-house IT contact, the web agency on retainer, or an external tester, needs to own an actual list of every plugin on every site. They need to check it against known vulnerabilities on a set schedule. And they need the authority to force an update, rather than waiting for the client to notice a problem.
Where responsibility usually falls through the gap
Contracts between a business and its web agency rarely spell out who owns ongoing plugin maintenance once a build is delivered. The agency built the site and moved on to the next client. The business owner assumes updates happen automatically, because most other software they use does update itself. WooCommerce plugins do not, unless someone configures automatic updates and then actually monitors whether they succeeded.
That ambiguity is where bugs like this one survive. Nobody is lying about responsibility. They simply never agreed on it in the first place. A plugin with 6,000 installs, sitting quietly unpatched for seven months, is what that looks like at scale.
What this should change
If your business runs WordPress or WooCommerce, managing third party plugin risk properly matters more than this one plugin flaw. The real question is who checks your plugin list against new CVEs, and how often? If the honest answer is nobody, or not since the site launched, that is the gap worth closing. Better to close it now than after the next plugin with 6,000 installs turns up in a Wordfence advisory.
Update to version 2.0.3.2 if you run this plugin, and check your uploads folder for stray PHP files. Then do the less exciting thing: put plugin auditing on somebody’s calendar, on a schedule, indefinitely. That single habit is what closes third party plugin risk for good, not just this one bug.
Write that ownership down explicitly, whether in a contract with your agency or an internal IT policy, rather than leaving it implied. Ask directly: who checks our plugin list against new vulnerabilities, and how often. If nobody can answer that question today, that answer is the finding, long before the next CVE with a 9.8 score shows up.
Subscribe to our newsletter
Honest updates, straight to your inbox. Unsubscribe any time.
