Unserialisation in Post Indexer could allow man-in-the-middle to execute arbitrary code (in some circumstances)


Last revised:

Twice a day the blog makes an automated unencrypted HTTP request to and the value that is returned is passed to unserialize(). It is possible for or any one on the network in a man-in-the-middle position to return a string that contains an evil encoded object that executes arbitrary code (depending on the active plugins and themes).

This code is called twice a day by wp_schedule_event(time(), 'twicedaily', 'wpmudev_scheduled_jobs') (extra/wpmudev-dash-notification.php):

var $server_url = ''; // line 12
$url = $this->server_url . '?action=check&un-version=3.3.3&wp=' . urlencode($wp) . '&bcount=' . $blog_count . '&domain=' . urlencode(network_site_url()) . $projects; // line 393
$response = wp_remote_get($url, $options); // line 400
$data = $response['body']; // line 402
$data = unserialize($data); // line 404

There is a class called ProcessLocker in this plugin with an exploitable __destruct method, which could be used as a jumping-off point for attacks using this unserialize() vulnerability (or the use of unserialize() in WordPress core which requires access to the database to exploit).

Current state: Fixed

CVSS Summary

CVSS base scores for this vulnerability
Score 7.6 High
Vector Network
Complexity High
Authentication None
Confidentiality Complete
Integrity Complete
Availability Complete
You can read more about CVSS base scores on Wikipedia or in the CVSS specification.

Proof of concept

Achieving arbitrary code execution depends on which classes are available (i.e. which plugins and themes are installed and active). It won’t be possible in all situations.

Advisory timeline

  1. 2016-11-01: Discovered
  2. 2016-11-14: Reported to plugin author via
  3. 2016-11-14: Plugin author responded
  4. 2016-11-17: Confirmed that version fixes the issue
  5. 2016-11-17: Requested CVE
  6. 2016-11-17: Advisory published

Mitigation/further actions

Upgrade to version or later.