WooCommerce Patches Two SQLi Vulnerabilities

Yesterday, WooCommerce released an urgent announcement encouraging users to update because of a serious vulnerability.

They don’t get into the details, but for us it’s imperative to understand what they are patching so that we can virtually patch at the edge via the NOC Web Application Firewall (WAF). Especially when it comes to a platform like WooCommerce which is one of the dominant ecommerce platforms in the world.

Our researchers were able to confirm that the severity was not exaggerated. They have patched a SQLi vulnerability.

SQLi Vulnerabilities

SQL Injection (SQLi) vulnerabilities occur when data queries are performed dynamically with user generated inputs. It is literally the injection of a query directly into the database. Not all SQLi vulnerabilities are the same, the most successful ones give attackers full access to the database ( read, modify, write). This isn’t really the biggest issue with WordPress as it uses MySQLi and it won’t allow several queries to be send in one call.

In basic terms, this type of vulnerability can be extremely serious. If an attacker is able to gain access to your database, they can essentially gain access to all the information.

You can dive deeper into SQLi vulnerabilities on the Open Web Application Security Project (OWASP)

Now couple that with something like WooCommerce, an ecommerce platform. Think of all the wonderful content stored in an ecommerce database.

WooCommerce Patch Two SQLi Vulnerability

Here is what we were able to find looking at the recent WooCommerce changes, and what we can learn from a secure development perspective. This might seem like 1 patch, but it’s actually fixing two separate issues.

  1. Issue with how search is being handled in WooCommerce
  2. Issue with how taxonomies are being handled in WooCommerce Blocks.

Issue 1: Search Issue with WooCommerce

Here is what changed in WooCommerce with the latest update:

The problem seems to have stemmed from the improper use of $args[‘search’].

The original version used the sanitize_text_field function, which is only helpful against Cross Site Scripting (XSS) that doesn’t occur in HTML tag attributes, but won’t fully protect against SQL Injections.

The update corrects the problem by turning it into a prepared statement. In other words, the SQLi vulnerability that was patched yesterday was a result of the esc_like function outside of a prepared statement.

This one, however, isn’t the one we should all be worried about. This requires authentication, which in essence an admin has to hack themselves and is accessible via the wp-admin panel.

The real problem comes with the Taxonomy issue in the WooCommerce Blocks.

Issue 2: Taxonomy Issue with WooCommerce Blocks

The second issue is with how the WooCommerce blocks plugin was handling Taxonomies, and you can see here.

- $attributes_to_count = array_map( 'wc_sanitize_taxonomy_name', $attributes );
+ $attributes_to_count = array_map(
+ function( $attribute ) {
+ $attribute = wc_sanitize_taxonomy_name( $attribute );
+ return esc_sql( $attribute );
+ },
+ $attributes
+ );
$attributes_to_count_sql = 'AND term_taxonomy.taxonomy IN
("' . implode( '","', $attributes_to_count ) . '")';
$attribute_count_sql = "

This was allowing for an unauthenticated SQLi vulnerability to be introduced, which would allow attackers to abuse calculate_attribute_counts[][taxonomy]

Example exploit attempt:

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

Steps to Protecting WooCommerce

This type of vulnerability requires one simple step – update. For many micro-businesses this step will be performed on your behalf if auto-updates are enabled. The WooCommerce release provides you the latest versions that have been patched.

If you’re an enterprise, however, and updating is a bit more nuanced, we encourage you to leverage a Web Application Firewall (WAF). Something that helps virtually patch a vulnerability without having to make production level changes immediately. This type of change helps give you the time you require to test in staging and follow your appropriate change control process.

We highly recommend taking proactive steps, sources are claiming that it is being actively exploited in the wild. As we learn more we’ll share.