Attackers are telling a WooCommerce plugin that PHP is an allowed upload extension

The defect is that the allowed-extension list arrives in the request. An attacker POSTs to `wwlc_file_upload_handler` at `/wp-admin/admin-ajax.php` with a `file_settings` parameter that names PHP as permitted, and the handler trusts what it was sent ^[4][5][6]. In the request examples published with the writeup, the same parameter also raised the maximum file size ^[5]. Nothing requires a login, and no shopper or staff member has to click anything ^[11].

The plugin appends a timestamp to the saved file name, so the destination cannot be worked out from the request alone ^[7]. The attacker has to go find the file it just wrote. The same property works against a defender searching disk for the submitted name, because that name is not what was saved ^[23].

Wordfence's figure counts requests its rules matched and stopped, more than 100,000 of them, in a 14 September report drawing on Wordfence and BleepingComputer ^[2][3]. The writeup states that blocked events do not indicate how many executions succeeded ^[14]. For that number to describe your store, your store would have to sit behind the same rules, and even then it measures attempts. Execution results for individual sites have not been published ^[9].

Writing the file and running it are separate stages ^[10]. Updating to 2.0.3.2 stops the write, 2.0.3.1 and earlier are the affected versions, and the fix is therefore one patch-level increment ^[12][13][21]. Disabling PHP execution in the upload directory stops the run, and the writeup is explicit that this is a different control from fixing the save ^[16]. Either one breaks the chain ^[22]. I would ship both, because the second keeps working the next time a plugin believes a client-supplied extension list.

The writeup also treats a WAF block as temporary cover and says not to use it in place of the update ^[15]. Updating does not settle whether a site was already compromised, and that has to be verified separately ^[13]. It labels its suggested starting points as inferences: PHP files newly created in the upload directory, administrator accounts created outside the normal flow, outbound traffic to unknown download hosts or command-and-control ^[18][20]. The evidence would sit in POST bodies, which standard access logs often do not retain ^[17].

If execution succeeded, the code ran with the privileges of WordPress and the web server ^[10]. The published web shell displays host information and writes further files ^[8]. The writeup lists what those privileges allow next: running additional malicious code, creating administrator accounts, exfiltrating data ^[19].