Vulnerability analysis

Missing Authorisation in Product Filter for WooCommerce Lets Anyone Delete Your Filter Data

Vulnerability details

Software

Product Filter for WooCommerce

woo-product-filter

Vulnerability type

Missing Authorisation

Threat level

Medium

Product Filter for WooCommerce versions up to and including 3.1.2 have a missing authorisation vulnerability (CVE-2026-3138). It allows unauthenticated attackers to permanently wipe all your product filter configurations with a single request. If you’re running an older version, you should update to 3.1.3 immediately.

What the vulnerability does

The plugin uses an internal MVC framework that registers AJAX handlers for its modules. The problem is a chain of four issues that combine to give unauthenticated users access to destructive database operations.

First, the framework’s havePermissions() method defaults to allowing access. If a module’s controller does not explicitly define permissions (and the WooFilters controller does not), every action is treated as permitted. Second, when the framework registers AJAX handlers, it registers both authenticated and unauthenticated routes. Third, the base controller uses a PHP magic method __call() that forwards any undefined method call to the model layer. Finally, the model’s delete() method runs TRUNCATE TABLE when called without parameters.

The result: an unauthenticated POST request to admin-ajax.php with action=delete&mod=woofilters&reqType=ajax triggers a full truncation of the wp_wpf_filters table. Every filter configuration on the site is gone.

What makes this really frustrating is that the plugin already has a properly secured deleteByID() method with nonce verification and capability checks. The vulnerability exists because an attacker can bypass that method entirely by calling the raw “delete” action through the magic method forwarding.

The fix

The patch in version 3.1.3 changes a single default value in the framework’s permission check:

// Before (vulnerable - default allow):
public function havePermissions( $code, $action ) {
$res = true;
// ...
// After (patched - default deny):
public function havePermissions( $code, $action ) {
$res = false;
// ...

This is textbook “default deny”. If a module does not explicitly define permissions for an action, the action is now blocked rather than allowed. It is a small change with a big impact.

Check if you are affected

Look in your WordPress admin under Plugins for “Product Filter for WooCommerce” or “Product Filter by WBW”. If the version number is 3.1.2 or lower, you are vulnerable.

You can also check with WP-CLI:

# Check which version of Woo Product Fiter you're running
wp plugin list --name=woo-product-filter --fields=name,version,status

Just update the plugin…

Update to version 3.1.3 or later through your WordPress dashboard or via WP-CLI:

If you can’t update immediately, consider deactivating the plugin for now. The vulnerability requires no authentication and no user interaction, so any site running the affected version is exposed.

After updating, verify your filter configurations are still intact. If you suspect exploitation, check your database backups. The `TRUNCATE TABLE` operation leaves no partial data to recover from.

Stop checking plugin versions manually.

Vulnz subscribers were notified about this vulnerability automatically. Drop the 50KB agent onto your client sites and get a weekly "Zero-Click" security digest straight to your inbox.

Automate your vulnerability reporting