Attacks on websites rarely involve anyone guessing a password. Far more often, a single add-on contains a flaw that lets a stranger place a file of their choosing on the server, and everything else follows from that. A campaign reported in the middle of September 2026 is a good illustration, because the flaw is ordinary, the fix had been available for months, and the sites being broken into are the ones where nobody was watching.
Plenty of legitimate features accept uploads: a contact form with an attachment, a product image, a customer uploading artwork to be printed. The code behind them is supposed to decide what is acceptable, and the usual approach is a list of permitted file types, so that a JPEG is accepted and a program is not.
The flaw appears when that decision is based on something the visitor sent. If the list of permitted types arrives with the upload itself, rather than being fixed in the code, an attacker can simply send their own list. The upload is then accepted precisely because it was checked, and the check was answered by the attacker.
The file they upload is normally a webshell: a small script that gives whoever knows its address a way to run commands, browse the file system and upload more files. From there the site can be used to send spam, to host phishing pages, to add hidden links for search engines, or to take card details at the checkout. The original flaw is forgotten; the webshell is the problem.
The vulnerability being exploited at the moment, CVE-2026-27540, is in a commercial WooCommerce add-on called WooCommerce Wholesale Lead Capture, in versions up to and including 2.0.3.1. It exposes an upload handler that anyone can reach without logging in, and the list of permitted file extensions is taken from the request, so php can be added to it. Version 2.0.3.2, which fixes it, was released in February.
Wordfence, which publishes figures from its own firewall, reported blocking more than 100,000 attempts against this one flaw, with bursts of activity in June, July and again at the end of August. The attack is a request to the site’s admin-ajax.php carrying a forged settings value and a PHP file, which lands in the uploads folder as a working webshell.
The point worth taking from it is the timing. The fix was published roughly six months before the attacks that are still succeeding. Every site being compromised now is one where the update was never applied.
The add-ons that go stale are rarely the free ones. Paid extensions update through the vendor’s own licence system, so when a licence lapses, the updates quietly stop while the extension carries on working. Nothing looks wrong. The site shows no update to apply, because it is no longer being told there is one.
Add to that the extension installed years ago by a developer who has since moved on, the trial that was never removed, and the plugin kept “just in case”, and most sites have at least one component nobody is responsible for.
find wp-content/uploads -name "*.php" should return nothing at all. The same idea applies to any platform: check its upload directory.wp-index.php or class-db.php in the wrong folder, are a common disguise.admin-ajax.php with an unusual action, are the attack itself. Requests to a PHP file in an uploads folder are the attacker using what they installed.Deleting the file you found is not the end of it. By the time a webshell is discovered there are usually several, plus an extra administrator account and a scheduled task to restore them. The reliable route is to restore the whole site from a backup taken before the compromise, update everything before putting it back online, and then change passwords, including the hosting account, the database user and any API keys the site holds.
.htaccess file in the uploads directory, and it stops a webshell working even if one is successfully uploaded. Open a ticket if you would like us to add it.Turn on automatic updates for plugins where you reasonably can, check the paid ones by hand, and confirm that each licence is current, since an expired licence is the most common reason a vulnerable version is still installed. Check the users list for administrators you do not recognise, and look through the plugins list for anything that has not been updated by its author in a couple of years.
CubeCart’s extension handling makes this easier to keep on top of: extensions installed from the marketplace are listed with their versions in one place, and it distinguishes between those it manages and those installed by hand, which we covered in managing CubeCart extensions. The same rules apply. Remove what you do not use, and be careful with extensions that accept uploads from customers.
If you are unsure whether a site is affected, or you would like the upload folder protection adding, open a ticket. Checking for the signs above on a site we host is a short job, and it is a much better use of everyone’s time than dealing with the aftermath. Our article on the website security measures that actually matter covers the rest of the ground.