WordPress Flaws and Vulnerabilities

Vulnerability in WooCommerce 2.3.10 : Object Injection

Blog WordPress Flaws and Vulnerabilities Vulnerability in WooCommerce 2.3.10 : Object Injection

WooCommerce 2.3.10

Yesderday, 10th,  june 2015, WooCommerce has been patched from a vulnerability called “Object Injection“.

We already seen this flaw in WordPress < 3.6.1 but here with a very high risk level, un WP from whom it was almost a null risk.

The risk does not depend on the fault itself, but several criteria assessed and calculated using the DREAD model means:

  • Damage,
  • Reproducibility,
  • Exploitability,
  • Affected users,
  • Discoverability.

This flaw has a very high risk, that is why its DREAD score is high (8/10). Indeed, it is easy to find and replicate the exploit on any WordPress containing WooCommerce < 2.3.11.

However, it happens that some sites may not update this plugin for reasons of maintenabilités. Yet it is very very very important to patch this vulnerability.


So what if you can not update WooCommerce but we would still like to be secure this flaw.

SecuPress offers you a mu-plugin, just drop this file in the “wp-content/mu-plugins” folder, create it if it does not exist.

The file is automatically included by WordPress before the plugins.

Plugin Name: Patch WooCommerce 2.3.10 -> 2.3.11 - Object Inhection Vulnerability
Author: SecuPress
add_action( 'plugins_loaded', 'patch_woocommerce_2310', 1 );
function patch_woocommerce_2310() {
if ( isset( $_REQUEST['cm'] ) ) {
$raw_custom = $_REQUEST['cm'];
$custom = sanitize_text_field( stripslashes( $_REQUEST['cm'] ) );
if ( ( false === ( $custom = json_decode( $raw_custom ) ) ) || ! is_object( $custom ) &&
! preg_match( '/^a:2:{/', $raw_custom ) || preg_match( '/[CO]:\+?[0-9]+:"/', $raw_custom ) ||
( false === $custom = maybe_unserialize( $raw_custom ) )
) {
$_REQUEST['cm'] = 'a:2:{i:0;i:0;i:1;i:0;}';

Save this code into a file and name it as you like in the mu-plugin folder (mu = must use = must be used).

The code and the fault, in a few words

The trouble comes from the parameter cm coming from a user via $_REQUEST, it will be unserialized and when unserialise an object, it instantiates.

If the user manage to give a malicious serialized object, then it will be instantiated. Of course you need that the class is present on the site.

Nevertheless it was possible to achieve the exploit to download the wp-config.php file through this loophole, I think this has added weight in the DREAD score.

In my code, I check if the parameter is a JSON or an array and not an object. If I find it, so I force the return of an arraycontaining a double zero, so that the result is gently broken.