CVE-2025-47577: Critical Arbitrary File Upload in TI WooCommerce Wishlist Puts 100,000+ Stores at Risk (CVSS 10.0)

In May 2025, security researchers at Patchstack publicly disclosed a vulnerability so severe it landed the maximum possible CVSS score of 10.0. The bug lives inside TI WooCommerce Wishlist, a plugin with more than 100,000 active installations on WordPress and WooCommerce stores around the world. Tracked as CVE-2025-47577, it allows an unauthenticated attacker to upload arbitrary files — including PHP backdoors — to a vulnerable site and use them to run code on the server.

If you sell online with WooCommerce and use wishlist functionality, this is the kind of flaw that turns a quiet Tuesday into an incident-response weekend. Here’s how it works, who is exploitable, and what to do today.

CVE details at a glance

• CVE ID: CVE-2025-47577
• Plugin: TI WooCommerce Wishlist by TemplateInvaders
• Active installations: 100,000+
• Vulnerability type: Arbitrary File Upload (leading to Remote Code Execution)
• CVSS score: 10.0 (Critical)
• Affected versions: 2.9.2 and below
• Patched in: 2.10.0 (released June 5, 2025)
• Authentication required: None — fully unauthenticated
• Reported by: Rafie Muhammad (Patchstack)

A CVSS of 10.0 is the highest score the system can assign. It’s reserved for vulnerabilities that are remotely exploitable, require no privileges or user interaction, and can fully compromise a system. This is a textbook example.

How the vulnerability works

The root cause is a single function inside the plugin called tinvwl_upload_file_wc_fields_factory. Its job is to handle file uploads submitted through wishlist forms when the plugin is integrated with the popular WC Fields Factory plugin, which lets store owners add custom fields to WooCommerce products.

Under the hood, the function passes uploaded files to WordPress’s built-in wp_handle_upload() helper. WordPress’s own upload helper is normally safe: by default, it checks the file’s MIME type and rejects anything that isn’t on the allowed list (images, PDFs, documents, and so on). PHP files are blocked. JSP files are blocked. Anything executable is blocked.

The problem is that the plugin’s developers explicitly disabled that protection. They called wp_handle_upload() with an option called 'test_type' => false, which tells WordPress: skip the file-type check entirely. From there, anything the attacker uploads is accepted, written to disk inside the WordPress uploads directory, and returned with a public URL.

Combined with the fact that the vulnerable endpoint is reachable without logging in, the attack flow is depressingly simple:

1. Send a crafted POST request to the plugin’s upload endpoint (tinvwl_meta_wc_fields_factory or tinvwl_cart_meta_wc_fields_factory) with a PHP file attached.
2. The plugin saves the PHP file to wp-content/uploads/.
3. The attacker visits the file’s URL directly in a browser, which causes the PHP code to execute under the web server user.
4. Game over: the attacker now has code execution on the server and can install persistent backdoors, drop new admin users, scrape data, deface the site, or pivot deeper.

One nuance: the vulnerable code only runs if the WC Fields Factory plugin is also active and the integration is enabled. That narrows the exploitable population to a subset of installs, but because the pair is commonly used together, it’s still a large attack surface — and a single scan can find the vulnerable combination quickly.

Real-world impact

Arbitrary file upload with unauthenticated access is one of the most dangerous classes of WordPress vulnerability, especially on WooCommerce stores. Practical consequences include:

• Customer data theft. Attackers can read database credentials from wp-config.php and dump customer records, hashed passwords, and order history.
• Payment skimming. With code execution, they can inject JavaScript card skimmers into checkout pages — a Magecart-style attack that often goes undetected for weeks.
• Full site takeover. The attacker can create a new admin user, lock you out, or take the site offline.
• SEO and reputation damage. Compromised sites are often used to inject spam pages or redirect visitors to scam sites. Google can flag the domain as deceptive, and recovering rankings takes months.
• Server-level pivoting. On poorly isolated hosting, the attacker may move from your site into other sites on the same server.

How to check if you’re affected

You should treat your store as at risk if all of the following are true:

• You have the TI WooCommerce Wishlist plugin installed.
• The version installed is 2.9.2 or older.
• You also have the WC Fields Factory plugin active and the integration enabled.

To check, log in to your WordPress dashboard and go to Plugins → Installed Plugins. Look for “TI WooCommerce Wishlist” and note the version number. If it’s anything older than 2.10.0, you’re running vulnerable code. While you’re there, check whether “WC Fields Factory” is also active. If both plugins are present and the wishlist version is below 2.10.0, assume you are exploitable until proven otherwise.

Also look for signs of past exploitation. Inspect wp-content/uploads/ for unfamiliar PHP files — anything with a .php extension there is worth investigating. Check your users list for admin accounts you didn’t create.

How to fix it

The fix is straightforward: update TI WooCommerce Wishlist to version 2.10.0 or later. The vendor patched the underlying issue by removing the test_type => false override, which restores WordPress’s default file-type validation. Anything that isn’t on the allowed MIME list will now be rejected, just as the platform intended.

1. Back up your site and database before making changes.
2. In your WordPress dashboard, go to Plugins → Installed Plugins.
3. Locate TI WooCommerce Wishlist and click Update Now. Confirm the new version is 2.10.0 or higher.
4. If automatic updates aren’t available, download the latest copy from wordpress.org and replace the plugin files manually.

Beyond patching, take a few minutes to harden the site:

• Block PHP execution in the uploads folder. Add a small .htaccess rule (or Nginx config) that prevents any .php file inside wp-content/uploads/ from being executed by the web server. This is one of the highest-value WordPress hardening steps; it would have made this exact vulnerability much less useful to an attacker.
• Enable automatic updates for plugins. Critical security patches are pointless if they sit untouched for weeks. WordPress supports per-plugin auto-updates from the Plugins screen.
• Audit installed plugins. Remove anything you aren’t actively using — fewer plugins means a smaller attack surface.
• Rotate secrets if you suspect compromise. Reset admin passwords, rotate salts in wp-config.php, and reissue stored API keys.
• Run a malware scan. If you ran a vulnerable version, scan for backdoors and unfamiliar scheduled tasks.

The takeaway

CVE-2025-47577 is a useful reminder that the WordPress platform itself often gives developers the right tools to stay safe — and that bypassing those tools, even with good intentions, can be catastrophic. The vulnerability didn’t come from a sophisticated zero-day in WordPress core. It came from a single argument flag ('test_type' => false) that turned off a default protection.

If you run a WooCommerce store, your security posture is the sum of every plugin you trust. Update on a schedule, remove what you don’t use, harden your uploads directory, and watch your activity logs. The vendor here did the right thing and shipped a fix quickly, but the patch only protects you once you install it. Take five minutes today to confirm your wishlist plugin — and every other plugin — is on its latest version.