Why a patched vulnerability continues to infect WooCommerce sites

The case that explains the problem

In February 2026, developer Rymera Web Co patched a critical vulnerability in the WooCommerce Wholesale Lead Capture plugin: a critical flaw that allowed execution of PHP files to be uploaded. Wordfence blocked more than 100,000 exploit attempts from June onwards, despite a patched version being available since February. The severity rating leaves no room for doubt: Wordfence assigned CVE-2026-27540 a CVSS score of 9.8.

The detail of interest to anyone managing multiple sites is the timeline. Version 2.0.3.2, which fixed the bug, was released on 20 February. Yet Wordfence recorded the heaviest exploitation between 4 and 17 June, followed by further activity on 1 July and 30 August. Another publication calculated that when active exploitation was discovered, the patch had been available for nearly six months.

The point that the developer's statement omits, and which analysts emphasise, is this: updating the plugin is only part of the answer, because a web shell placed before the update can remain on the server even after the vulnerable upload path is closed. Anyone who ran a site with that version of the plugin between February and June must therefore check the files, not just verify the installed version.

Why automatic updates alone are not enough

WordPress plugin automatic updates cover minor versions, but many agencies disable them on commercial plugins or leave them disabled by default on installations managed via manual licensing. The result is that nobody actually checks, week after week, which plugins have fallen behind on which sites. With ten or twenty installations, manual checking from each site's dashboard becomes work that nobody does consistently.

Weekly checks with WP-CLI

On a single site, the command to view only plugins with an available update is:

wp plugin list --update=available

For a multisite installation, the same check needs to be repeated on each subsite using the --url flag:

for site in $(wp site list --field=url); do
 echo "=== $site ==="
 wp plugin list --update=available --url=$site
done

If you manage separate installations (the typical case for an agency with multiple clients on different paths on the same server or on different servers), run the same check by pointing to each installation's path with --path:

SITES=(
 "/var/www/client1"
 "/var/www/client2"
 "/var/www/client3"
)

for s in "${SITES[@]}"; do
 echo "=== $s ==="
 wp plugin list --update=available --path="$s"
done

Put in a file and executed via cron once a week with output redirected to a log or sent by email, this script gives you in seconds a list of all outdated plugins across all your managed sites, including the exact plugin name and installed version against the available version. It's the same output you'd get by opening each dashboard one by one, but in a single command.

What to do with the list

A weekly list doesn't replace security review, but it makes it possible: it allows you to know, before an external alert discovers it, which sites have a vulnerable plugin still installed. For plugins flagged with an active CVE, the additional check to perform is not just "I've updated", but "did the site receive suspicious requests before the update", verifiable in the access logs from the period when the vulnerable version was active.