Hackers Exploit WooCommerce Plugin Bug to Take Over WordPress Sites Without Login

Attackers are actively exploiting a critical flaw in a WooCommerce extension to seize control of WordPress sites without a username or password. The issue affects Wholesale Lead Capture and turns a routine file-upload feature into a direct path to server access.

The vulnerability, tracked as CVE-2026-27540, has a CVSS severity score of 9.8 and affects versions through 2.0.3.1. An attacker can reach the exposed upload function and place executable code on an unpatched website. This means an online store can be compromised before its owner even logs in.

Wordfence analysts identified active abuse and reported blocking more than 100,000 exploit attempts. Activity has continued for months, with notable bursts from June 4 through June 17, then again on July 1 and August 30.

Wordfence said in a report shared with Cyber Security News (CSN) that the scale matters because the affected extension is estimated to run on about 6,000 active sites.

A successful intrusion can expose customer data, enable payment fraud, or turn a store into a platform for more attacks. Recent coverage of WordPress migration plugin flaws shows why unauthenticated bugs deserve immediate attention.

Hackers Exploit WooCommerce Plugin Bug

The weakness lies in the plugin’s wholesale registration form, which allows visitors to upload files. Its upload process checks a list of permitted file types, but it accepts that list from the visitor’s request rather than using a trusted setting held by the server.

An attacker can therefore alter the list and make the site accept a PHP file. That small validation error has serious consequences. PHP is code that a WordPress server can run, so an uploaded backdoor can give an intruder a remote foothold.

From there, the operator may run commands, add administrator accounts, copy stored information, or make changes that let them return later. It resembles the persistence risks described in coverage of malicious WooCommerce site malware.

The upload needs no WordPress account. The attacker only has to submit a crafted request to the plugin’s public handler. The vulnerable upload logic also bypasses normal file-type checks, removing a key safeguard that should stop executable files.

This is not simply a theoretical finding. The observed payload provides a browser-based way to view host details and write more files, allowing attackers to deepen their access after the initial break-in. Owners should treat unexplained server changes as a possible compromise.

Patch Sites and Review for Intrusion

Update Wholesale Lead Capture to version 2.0.3.2 as soon as possible. Administrators should also inventory WordPress extensions across every store and staging environment. Before upgrading, teams should record plugin versions and preserve a copy of the affected site for analysis.

They should verify backups were created before the intrusion. Keeping a tested backup is useful, but it should be checked before restoration so it does not reintroduce malicious files.

Site owners should examine upload folders for unexpected or recently created PHP files, inspect administrator accounts for unfamiliar entries, and review server logs for the attack pattern listed below.

They should remove confirmed malicious files, revoke unknown accounts, reset privileged passwords, and look for secondary backdoors. A similar response discipline is important after plugin supply chain backdoors, where attackers may leave durable access behind.

The absence of suspicious log entries does not prove a site is safe, because attackers can use other infrastructure or erase traces.

Organizations that process orders should also check for unusual changes to checkout pages, new scheduled tasks, and unexpected outbound connections. Preserve logs and copies of suspicious files before cleanup if an incident investigation may be needed.

Developers should validate file types and size limits on the server, avoid trusting browser-supplied settings, and prevent uploaded files from running as code.

For store operators, fast patching and routine checks remain the most practical defense when attackers are already scanning for a known flaw. New plugin update security checks add another defensive layer, but they do not replace rapid patching or post-incident review.

Indicators of compromise (IoCs):-

Type	Indicator	Description
IP address	92.241.13.213	Observed source of more than 24,900 blocked exploit requests
IP address	31.59.129.150	Observed source of more than 24,000 blocked exploit requests
IPv6 address	2a0f:85c1:840:5389::1	Observed source of more than 16,000 blocked exploit requests
IP address	92.241.13.140	Observed source of more than 9,100 blocked exploit requests
IP address	23.137.105.214	Observed source of more than 6,700 blocked exploit requests
IP address	23.180.120.140	Observed source of more than 6,600 blocked exploit requests
IP address	104.194.9.138	Observed source of more than 6,100 blocked exploit requests
IP address	187.75.114.36	Observed source of more than 470 blocked exploit requests
IP address	114.10.43.203	Observed source of more than 310 blocked exploit requests
IP address	37.114.144.209	Observed source of more than 310 blocked exploit requests
File name	shell.php	Observed PHP webshell filename used in exploitation
Request path	/wp-admin/admin-ajax.php	WordPress AJAX endpoint targeted during exploitation
Request parameter	action=wwlc_file_upload_handler	Malicious requests use this action value to reach the vulnerable upload handler

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Keep your SOC up to date on active malware & phishing within 24h of their emergence. Try ANYRUN to prevent incidents with early detection.