WooCommerce Patches Two SQLi Vulnerabilities

WooCommerce published an urgent update advisory addressing a serious vulnerability in 2021. While the advisory was light on details, our goal is always to understand what changed so we can virtually patch at the edge via the NOC WAF—especially for a platform as widely deployed as WooCommerce.

Our research confirmed the core issue involved SQL injection (SQLi), and in practice there were two separate vulnerabilities addressed across WooCommerce and WooCommerce Blocks.

SQLi, quickly

SQL injection occurs when user-controlled input ends up in a database query without proper parameterization. Impacts range from information disclosure to modification of data. WordPress’ $wpdb supports prepared statements—use them. Simple string sanitization functions alone (e.g., sanitize_text_field) don’t prevent SQLi if the value is later interpolated into a query string.

What changed in WooCommerce

1. Search handling (WooCommerce core): insufficiently protected search term used in a SQL fragment was converted to a prepared statement using $wpdb->prepare() with esc_like() applied inside the binding.
2. Taxonomy handling (WooCommerce Blocks): taxonomy names from request attributes now undergo stricter sanitation (wc_sanitize_taxonomy_name()) and explicit SQL escaping before being used in an IN (...) clause.

Issue 1: Search (authenticated)

The original code assembled a LIKE filter using esc_like( sanitize_text_field( $args['search'] ) ) but still interpolated the string directly into SQL. The patch moved that into $wpdb->prepare():

// Before: built a string with ... LIKE '%<term>%'
// After (conceptual):
$search = ! empty( $args['search'] )
  ? $wpdb->prepare( "AND `name` LIKE %s", '%' . $wpdb->esc_like( sanitize_text_field( $args['search'] ) ) . '%' )
  : '';

This vector required authentication (admin context). Serious, but lower priority than the unauthenticated path below.

Issue 2: Taxonomies (unauthenticated)

WooCommerce Blocks tightened handling of taxonomy names used for collection data queries by sanitizing and SQL-escaping each attribute before building the IN list:

// Conceptual diff
$attributes_to_count = array_map(
  function( $attribute ) {
    $attribute = wc_sanitize_taxonomy_name( $attribute );
    return esc_sql( $attribute );
  },
  $attributes
);

Example exploit attempt observed in the wild targeting the REST endpoint:

/wp-json/wc/store/products/collection-data?calculate_attribute_counts[]
[taxonomy]=%252522%252529%252520union%252520all%252520SELECT%2525201%25252Cuser_id%252520FROM%252520wp_users%252523

How to protect your store

• Update immediately. Apply the patched WooCommerce and WooCommerce Blocks versions listed in the official advisory.
• Use a WAF for virtual patching. For enterprises with change control constraints, deploy or enable NOC WAF rules to block known exploit patterns while you validate updates in staging.
• Principles for developers: always parameterize ($wpdb->prepare()), scope and sanitize taxonomy names (wc_sanitize_taxonomy_name), and never concatenate user input into SQL.