Yesterday, data we track showed that what was likely a hacker was probing for usage of the 100,000+ install WordPress plugin TI WooCommerce Wishlist, by requesting its readme.txt file. Why would a hacker be interested in the plugin? Presumably there shouldn’t be any publicly known unfixed vulnerabilities, as the plugin hasn’t been closed in the WordPress plugin directory:

Contrary to that, various data sources on vulnerabilities in WordPress are claiming there are unfixed vulnerabilities in the plugin. Here is WPScan, which is part of Automattic, the company from the head of WordPress, claiming that:

With the “critical” vulnerability, they don’t provide the details needed to vet the claim:

They also admit they haven’t verified the claim, which seems problematic.

They cite a competitor, Patchstack, which also doesn’t provide details needed to vet the claim:

They also claim to have known about it since March.

Wordfence is claiming the vulnerability exists, but also doesn’t provide the details needed to vet the claim:

It turns out an arbitrary file upload vulnerability exists, but a key limitation on its exploitation has been left out.

Vulnerable Code

The vulnerability is supposed to involve functionality that allows uploading files without any restriction on what type can be uploaded. And it is accessible by those not logged in to WordPress. Checking over the plugin’s code, there are several files with code that utilizes PHP’s file uploads variable, $_FILES. One of those requires being logged in as an Administrator. A couple of other call a function that doesn’t exist in the plugin to handle an upload. The remaining instance is in the file /integrations/wc-fields-factory.php. In that file, the function tinvwl_cart_meta_wc_fields_factory() passes a file sent with a request to a second function tinvwl_upload_file_wc_fields_factory():

332
333
334
335
336
337
338
339
340

function tinvwl_cart_meta_wc_fields_factory( $meta ) {
 
	if ( function_exists( 'wcff' ) ) {
 
		$files = $_FILES;
 
		foreach ( $files as $name => $file ) {
			if ( ! array_key_exists( $name, $meta ) ) {
				$upload = tinvwl_upload_file_wc_fields_factory( $file );

That second function utilizes WordPress’ wp_handle_upload() function to handle the upload, but the code disables the function’s default check to limit what types of files can be uploaded.

373
374
375
376
377
378
379
380
381
382
383
384

function tinvwl_upload_file_wc_fields_factory( $file ) {
 
	if ( ! function_exists( 'wp_handle_upload' ) ) {
		require_once( ABSPATH . 'wp-admin/includes/file.php' );
	}
	$upload = wp_handle_upload(
		$file,
		[
			'test_form' => false,
			'test_type' => false,
		]
	);

That lack of file type restriction is caused by the override that sets ‘test_type’ to false.

Additional Plugin Requited

The first function requires that a function named wcff also exists for the upload to happen. A function with that name doesn’t exist in the plugin, so the code will only run if other code that has a function with that name is also running. There is only one plugin in the WordPress Plugin Directory that contains a function with that name, WC Fields Factory. That lines up with the name of the file in this plugin with the code, which is /integrations/wc-fields-factory.php. So the file is an integration for those also using that plugin.

So this is only exploitable with that plugin also installed. It has 9,000+ installs, and is like this plugin, used to extend WooCommerce, so there are likely some websites that contain both.

Notably, other data sources have failed to note this important limitation on who is impacted.

Accessing the Code

We have confirmed the code is accessible and exploitable. It is exploitable by sending a request add a product to the plugin’s wishlist.

Where the Uploaded File Would be Located

The file would be uploaded to WordPress upload directory for the current month, so this month it would be stored in the sub-directory /wp-content/uploads/2025/05/ of the directory the WordPress website is located on the server.

Why Hasn’t WordPress Taken Action?

Despite apparently being known about for almost two months, the plugin is still vulnerable and available through the WordPress Plugin Directory. There are multiple security providers who claim to care about the security of WordPress who haven’t raised alarm over it still being in that state.

There are several options currently available to WordPress in this type of situation. They can close the plugin. They can provide a fixed version, even if the developer isn’t around any more (which might be the case with this plugin based on the lack of responses on its support forum). They can force out that fixed version.

Fixing this enough to stop exploitation would be easy. One option would be to disable the upload functionality entirely, which could be done by changing a single line of code. Restricting what types of files can be uploaded could also be done by changing a single line of code. For situations like this, we have offered for years to provide WordPress with the needed change. They haven’t taken up our offer. They have rarely done it themselves, despite the usual ease of doing it.

We have reached out to the developer about the situation.

We Already Provided Protection

We tested and confirmed that our firewall plugin for WordPress protected against the type of exploitation of this vulnerability you would see in a mass hack, even before the vulnerability was discovered, as part of its protection against zero-day vulnerabilities.

Free Warning

As the vulnerability looks to be targeted by a hacker, we are adding accurate data on it to the free data that comes with our Plugin Vulnerabilities plugin.

Plugin Security Scorecard Grade for Patchstack

See issues causing the plugin to get less than A+ grade

Plugin Security Scorecard Grade for WPScan

See issues causing the plugin to get less than A+ grade