Product Filter for WooCommerce by WBW < 3.1.3 - Unauthenticated SQL Injection

This analysis targets an unauthenticated SQL injection vulnerability in the Product Filter for WooCommerce by WBW plugin (version < 3.1.3). The vulnerability stems from improper sanitization and lack of query preparation when processing filter parameters in the frontend AJAX request.

1. Vulnerability Summary

The vulnerability exists in the WoofiltersControllerWpf class within the modules/woofilters/controller.php file. Specifically, the filtersFrontend() method processes user-supplied JSON data from the filtersDataBackend and queryvars parameters. This data is passed into SQL-building functions that utilize the _prepareTextLikeSearch() method, which performs direct string concatenation of user input into a SQL LIKE clause without using $wpdb->prepare() or sufficient escaping.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• Action: wpf_ajax
• Query Parameters: pl=wpf, mod=woofilters, task=filtersFrontend
• POST Parameters:
  • filtersDataBackend: A JSON-encoded array containing filter configurations.
  • queryvars: A JSON-encoded object containing WooCommerce query arguments.
• Authentication: None required (Unauthenticated).
• Preconditions: At least one product must exist in WooCommerce for the filter logic to execute its database queries.

3. Code Flow

1. Entry: A request is sent to admin-ajax.php with action=wpf_ajax.
2. Routing: FrameWpf::parseRoute() (in classes/frame.php) extracts mod=woofilters and task=filtersFrontend.
3. Execution: FrameWpf::exec() calls WoofiltersControllerWpf::filtersFrontend().
4. Processing: filtersFrontend() decodes the filtersDataBackend JSON.
5. Vulnerable Sink: The controller logic (via createArgsForFiltering) processes search-type filters using _prepareTextLikeSearch($val) (line 15 of modules/woofilters/controller.php):

   protected function _prepareTextLikeSearch( $val ) {
       $query = '(title LIKE "%' . $val . '%"'; // <--- SQL INJECTION POINT
       if ( is_numeric($val) ) {
           $query .= ' OR id LIKE "%' . (int) $val . '%"';
       }
       $query .= ')';
       return $query;
   }
   

6. Query Execution: The resulting unescaped string is added to the model's WHERE clause via $model->addWhere(array('additionalCondition' => $query)) and executed against the database.

4. Nonce Acquisition Strategy

While filtersFrontend does not strictly enforce a nonce check (making it unauthenticated), the plugin often localizes a nonce for other frontend features. If an environment requires a nonce for all wpf_ajax actions, use the following:

1. Shortcode: The plugin uses [wpf-filters id=...].
2. Setup: Create a filter and a page containing its shortcode.

   wp post create --post_type=wpf_filters --post_title="Exploit Filter" --post_status=publish
   # Note the ID of the new post (e.g., 123)
   wp post create --post_type=page --post_title="Filter Page" --post_content="[wpf-filters id=123]" --post_status=publish
   

3. Extraction: Use browser_navigate to the new page and browser_eval to extract the localized settings:

   // WBW typically localizes data into a variable named after the plugin/module
   // Look for 'wpfNonce' in the localized object
   window.wpfFrontendPage?.nonce || window.wpfMainWrapper?.wpfNonce
   

5. Exploitation Strategy

We will use a time-based blind SQL injection payload within the filtersDataBackend JSON structure, targeting the search filter logic.

**HTTP Request (via `http_