16 Apr

Our Proactive Monitoring Caught a PHP Object Injection Vulnerability in a Another Brand New Plugin

One of the ways we help to improve the security of WordPress plugins, not just for our customers, but for everyone using them, is the proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities. That again has lead to us catching a vulnerability of a type that hackers are likely to exploit if they know about it.

This vulnerability is in a brand new plugin, Disc Golf Manager, and should have been something that the security review that is supposed to be done before new plugins can be added to the Plugin Directory should have caught. It is something that would have been flagged by our Plugin Security Checker, so it would make sense to run plugins through that during that security review to avoid this type of situation continuing to happen. That it continues to happen speaks to the continued lack of interest in improving security by the leadership of WordPress (starting at the top with Matt Mullenweg) and the continued role we play in limiting the impact of that for everyone else. We would be happy to provide the Plugin Directory team free access to the upload and developer mode capabilities to facilitate that.

The vulnerability occurs in function flashProcess() in the file /main.php where the value of the cookie “disc_golf_flash” is passed through the unserialize() function, which can lead to PHP object injection:

4043
4044
4045
function flashProcess() {
	if(isset($_COOKIE[$this->key . '_flash'])) {
		$temp = unserialize(base64_decode($_COOKIE[$this->key . '_flash']));

That function will run anytime a WordPress page is being accessed:

3811
add_action('init', array($this, 'flashProcess'));

We notified the developer of the issue a week ago. We haven’t heard back from them and no new version has been released to fix the issue. In line with our disclosure policy, which is based on the need to provide our customers with information on vulnerabilities on a timely basis, we are now disclosing this vulnerability.

Proof of Concept

With our plugin for testing for PHP object injection installed and activated, set the value of the cookie “disc_golf_flash” to “TzoyMDoicGhwX29iamVjdF9pbmplY3Rpb24iOjA6e30=” and then when you visit a page on the webiste the message “PHP object injection has occurred.” will be shown.

Timeline

  • April 9, 2018 – Developer notified.
23 Mar

Our Proactive Monitoring Caught a PHP Object Injection Vulnerability in DukaPress

One of the ways we help to improve the security of WordPress plugins, not just for our customers, but for everyone using them, is the proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities. That again has lead to us catching a vulnerability of a type that hackers are likely to exploit if they know about it. Since the check used to spot this is also included in our Plugin Security Checker (which  is now accessible through a WordPress plugin of its own), it is another of reminder of how that can help to indicate which plugins are in greater need of security review (for which we do as part of our main service as well as separately).

In the plugin DukaPress, the value of a cookie was passed through the unserialize() function, which could lead to PHP object injection. That occurred in the function get_cart_cookie() (in the file /classes/dukapress-cart.php):

33
34
35
36
37
38
static function get_cart_cookie() {
 
	$cookie_id = self::$cookie_id_string . COOKIEHASH;
 
	if ( isset( $_COOKIE[ $cookie_id ] ) ) {
		$cart = unserialize( stripslashes( $_COOKIE[ $cookie_id ] ) );

The value of COOKIEHASH in that is set by WordPress with the following code:

define( 'COOKIEHASH', md5( $siteurl ) );

That function is accessible through WordPress’ AJAX functionality whether someone is logged in to WordPress or not:

12
13
add_action('wp_ajax_nopriv_dpsc_update_cart', array(__CLASS__, 'update_cart'));
add_action('wp_ajax_dpsc_update_cart', array(__CLASS__, 'update_cart'));

We contacted the developer about the vulnerability yesterday and within hours they had released version 3.2 that resolved it by replacing use of unserialize() with json_decode() (and replaces related use of serialize() with json_encode()):

38
$cart = json_decode(  $_COOKIE[ $cookie_id ] , true );

Proof of Concept

With our plugin for testing for PHP object injection installed and activated, set the value of the cookie “dpsc_cart_” plus the md5 hashed version of the website’s site URL to “O:20:”php_object_injection”:0:{}” and then when you visit the following URL  the message “PHP object injection has occurred.” will be shown if you are not logged in to WordPress.

Make sure to replace “[path to WordPress]” with the location of WordPress.

http://[path to WordPress]/wp-admin/admin-ajax.php?action=wsfl_add_product_to_cart

Timeline

  • March 23, 2018 – Developer notified.
  • March 23, 2018 – Version 3.2 released, which fixes vulnerability.
  • March 23, 2018 – Developer responds.
14 Mar

Our Proactive Monitoring Caught a PHP Object Injection Vulnerability in a Another Brand New Plugin

One of the ways we help to improve the security of WordPress plugins, not just for our customers, but for everyone using them, is the proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities. That again has lead to us catching a vulnerability of a type that hackers are likely to exploit if they know about it.

This vulnerability is in a brand new plugin, HappyForms, and should have been something that the security review that is supposed to be done before new plugins can be added to the Plugin Directory should have caught. It is something that would have been flagged by our Plugin Security Checker, so it would make sense to run plugins through that during that security review to avoid this type of situation continuing to happen. That it continues to happen speaks to the continued lack of interest in improving security by the leadership of WordPress (starting at the top with Matt Mullenweg) and the continued role we play in limiting the impact of that for everyone else. We would be happy to provide the Plugin Directory team free access to the upload and developer mode capabilities to facilitate that.

The vulnerability occurred in function read() in the file /inc/classes/class-message-notices.php where the value of the cookie “happyforms-message-notices” was passed through the unserialize() function, which can lead to PHP object injection:

108
109
110
111
112
public function read() {
	$this->messages = array();
 
	if ( isset( $_COOKIE[ $this->cookie_name ] ) && ! empty( $_COOKIE[ $this->cookie_name ] ) ) {
		$this->messages = unserialize( stripslashes( $_COOKIE[ $this->cookie_name ] ) );

That function will run anytime a non-admin page is being accessed:

67
68
69
if ( ! is_admin() ) {
	add_action( 'send_headers', array( $this, 'read' ) );
}

After we notified the developer of the issue, they released version 1.1, which resolves the vulnerability by replacing use of unserialize() with json_decode() (and replaces related use of serialize() with json_encode()):

112
$this->messages = json_decode( stripslashes( $_COOKIE[ $this->cookie_name ] ), true );

Proof of Concept

With our plugin for testing for PHP object injection installed and activated, set the value of the cookie “happyforms-message-notices” to “O:20:”php_object_injection”:0:{}” and then when you visit a frontend page the message “PHP object injection has occurred.” will be shown.

Timeline

  • February 13, 2018 – Developer notified.
  • February 14, 2018 – Developer responds.
  • March 13, 2018 – Version 1.1 released, which fixes vulnerability.
12 Mar

Our Proactive Monitoring Caught a Authenticated PHP Object Injection Vulnerability in bbPress Move Topics

One of the ways we help to improve the security of WordPress plugins, not just for our customers, but for everyone using them, is the proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities. That sometimes leads to us catching a vulnerability of a more limited variant of one of those serious vulnerability types, which isn’t as much concern for the average website, but could be utilized in a targeted attack. That happened with the authenticated PHP object injection vulnerability we found in the plugin bbPress Move Topics. This vulnerability could have allowed an attacker that had access to a WordPress account of contributor level or above to exploit a PHP object injection vulnerability. It also could have allowed an attacker that could get a user logged in as a Contributor-level or above to visit a URL the attacker controls, to exploit the vulnerability as well.

Since the check used to spot this is also included in our Plugin Security Checker (which  is now accessible through a WordPress plugin of its own), it is another of reminder of how that can help to indicate which plugins are in greater need of security review (for which we do as part of our service as well as separately).

The vulnerability occurred in the function aforums_move_topics_page(). That function passed the base64 decoded value of the POST input “allforums” through the unserialize() function, which could lead to PHP object injection:

54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
function forums_move_topics_page() {
	// Backward compatibility
	// Clean v1.1.2
	delete_option('bbpmt-ptot-donot-close');
 
	echo '>h1<Move topics Forum to Forum>/h1<';
	if ( !function_exists( 'bbp_list_forums' ) ) {
		require_once ABSPATH . PLUGINDIR . '/bbpress/includes/forums/template.php';
	}
 
	// Check if coming from form (POST data)
 
	// Choose topics to move
	if ( isset($_POST['goforum']) ) {
		if( empty($_POST["sourceforum"]) ) {
			echo 'No forum selected';
		} else {
			global $wpdb;
			$allforumarray = unserialize(base64_decode($_POST["allforums"]));

That function is accessed through a page in the admin area of WordPress:

514
$confHook = add_submenu_page('edit.php?post_type=forum', 'Move topics', 'Move topics', 'edit_posts', 'forums_move_topics', 'forums_move_topics_page');

The capability required to access that “edit_posts” is usually provided to Contributor-level and above users.

Since there was no nonce check that ran before that code ran, the vulnerability could be exploited through cross-site request forgery (CSRF).

After we notified the developer of the issue, it was resolved in version 1.1.5, which replaces the usage of unserialize() with a new function, bbpmt_get_forum_structure().

Proof of Concept

With our plugin for testing for PHP object injection installed and activated, the following proof of concept will cause the message “PHP object injection has occurred.” be shown, when logged in as a Contributor-level or above user.

Make sure to replace “[path to WordPress]” with the location of WordPress.

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/edit.php?post_type=forum&page=forums_move_topics" method="POST">
<input type="hidden" name="goforum" value="test" />
<input type="hidden" name="sourceforum" value="test" />
<input type="hidden" name="allforums" value="TzoyMDoicGhwX29iamVjdF9pbmplY3Rpb24iOjA6e30=" />
<input type="submit" name="submit" value="Submit" />
</form>
</body>
</html>

Timeline

  • February 16, 2018 – Developer notified.
  • February 23, 2018 – Developer responds.
  • March 11, 2018 – Version 1.1.5 released, which fixes vulnerability.
08 Mar

Our Proactive Monitoring Caught a PHP Object Injection Vulnerability in WooCommerce Save For Later Cart Enhancement

One of the ways we help to improve the security of WordPress plugins, not just for our customers, but for everyone using them, is the proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities. That again has lead to us catching a vulnerability of a type that hackers are likely to exploit if they know about it. Since the check used to spot this is also included in our Plugin Security Checker (which  is now accessible through a WordPress plugin of its own), it is another of reminder of how that can help to indicate which plugins are in greater need of security review (for which we do as part of our main service as well as separately).

In the plugin WooCommerce Save For Later Cart Enhancement the value of cookies are passed through the unserialize() function, which could lead to PHP object injection. One of the instances of that occurs is in the function wsfl_add_product_to_cart() (in the file /public/class-woo-save-for-later-public.php):

256
257
258
259
260
261
262
263
264
265
266
public function wsfl_add_product_to_cart() {
 
	global $product,$woocommerce,$post;
 
	$getCurrentUserID = get_current_user_id();
	$encodeUserID = md5($getCurrentUserID);
	$cookieName = WSFL_PLUGIN_COOKIE_NAME.$encodeUserID;
 
	$productID = ( $_POST['productID'] )? $_POST['productID'] : '';
 
	$cookieProductArr = maybe_unserialize(stripslashes( $_COOKIE[$cookieName]) );

That function is accessible through WordPress’ AJAX functionality whether someone is logged in to WordPress or not:

199
200
$this->loader->add_action( 'wp_ajax_wsfl_add_product_to_cart', $plugin_public, 'wsfl_add_product_to_cart' ); 
$this->loader->add_action( 'wp_ajax_nopriv_wsfl_add_product_to_cart', $plugin_public, 'wsfl_add_product_to_cart' );

We notified the developer of the issue a week ago. We haven’t heard back from them and no new version has been released to fix the issue. In line with our disclosure policy, which is based on the need to provide our customers with information on vulnerabilities on a timely basis, we are now disclosing this vulnerability.

Proof of Concept

With our plugin for testing for PHP object injection installed and activated, set the value of the cookie “wsfl_save_product_cfcd208495d565ef66e7dff9f98764da” to “O:20:”php_object_injection”:0:{}” and then when you visit the following URL  the message “PHP object injection has occurred.” will be shown if you are not logged in to WordPress.

Make sure to replace “[path to WordPress]” with the location of WordPress.

http://[path to WordPress]/wp-admin/admin-ajax.php?action=wsfl_add_product_to_cart

Timeline

  • February 27, 2017 – Developer notified.
02 Mar

Our Proactive Monitoring Caught a PHP Object Injection Vulnerability in WL Katalogsøk

One of the ways we help to improve the security of WordPress plugins, not just for our customers, but for everyone using them, is the proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities. That again has lead to us catching a vulnerability of a type that hackers are likely to exploit if they know about it. Since the check used to spot this is also included in our Plugin Security Checker (which  is now accessible through a WordPress plugin of its own), it is another of reminder of how that can help to indicate which plugins are in greater need of security review (for which we do as part of our main service as well as separately).

In the plugin WL Katalogsøk, user input is passed through the unserialize() function, which could lead to PHP object injection, when visiting a page using one of its shortcodes.

The plugin makes the function showSingleItem() available through a shortcode:

4
add_shortcode("wl-ils-enkeltpost", array('MBShortcode', "showSingleItem") );

That function, which is located in the file /lib/WL_Shortcode.php, assigns the value of the GET input “enkeltpostinfo” to the variable $info and then unserializes the base64_decoded version of it:

87
88
89
90
91
public static function showSingleItem ($atts) {
  $postout = null;
 
  if ( $info = _is($_GET, 'enkeltpostinfo') ) {
    $item_info = unserialize(base64_decode($info));

Even if the shortcode that causes that function to run is not used on the website, any one logged in to WordPress could access it, like they can shortcodes in general, through WordPress’ AJAX functionality and the vulnerability is also exploitable that way as well.

We notified the developer of the issue a week ago. We haven’t heard back from them and no new version has been released to fix the issue. In line with our disclosure policy, which is based on the need to provide our customers with information on vulnerabilities on a timely basis, we are now disclosing this vulnerability.

Proof of Concept

With our plugin for testing for PHP object injection installed and activated, visiting the following page will cause the message “PHP object injection has occurred.” to be shown.

Make sure to replace “[path to page with enkeltpostinfo shortcode]” with the location of a page with the shortcode “enkeltpostinfo” on it.

http://[path to page with enkeltpostinfo shortcode]?enkeltpostinfo=TzoyMDoicGhwX29iamVjdF9pbmplY3Rpb24iOjA6e30=

Timeline

  • February 22, 2018 – Developer notified.
23 Feb

Our Proactive Monitoring Caught an Authenticated Arbitrary File Upload Vulnerability in Convert Docx2post

One of the ways we help to improve the security of WordPress plugins, not just for our customers, but for everyone using them, is the proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities. That sometimes leads to us catching a vulnerability of a more limited version of one of those serious vulnerability types, which isn’t as much concern for the average website, but could be utilized in a targeted attack. That happened with the authenticated arbitrary file upload vulnerability we found in the plugin Convert Docx2post. This vulnerability could allow someone that has access to a WordPress account with the “publish_posts” capability (which would normally be any user with the Author role and above) to upload a malicious file to the website, which could they use to take additional actions on with the website. It also could allow an attacker that could get a logged in user to visit a URL the attacker controls, to upload a malicious file to the website, which the hacker could then use to take additional actions on their own with the website.

Since the check used to spot this is also included in our Plugin Security Checker (which  is now accessible through a WordPress plugin of its own), it is another of reminder of how that can help to indicate which plugins are in greater need of security review (for which we do as part of our service as well as separately).

In the file /options.php, as of version 1.4, the first code that runs is:

92
93
94
95
96
97
98
if (isset($_POST['create']) && $_FILES['fileToUpload']["tmp_name"][0]) {
 
$target_dir = wp_upload_dir();
 
if (!file_exists($target_dir['basedir'] . '/docx2post')) {
    mkdir($target_dir['basedir'] . '/docx2post', 0775, true);
}
115
116
117
118
119
120
121
122
123
124
if ($_FILES['fileToUpload']) {
    $file_ary = reArrayFiles($_FILES['fileToUpload']);
 
    foreach ($file_ary as $file) {
 
 
 
$target_file = $target_dir['basedir'] ."/docx2post/". basename($file["name"]);
 
move_uploaded_file($file["tmp_name"], $target_file);

That code will save any type of file sent with a request to the directory /wp-content/uploads/docx2post/ as long as the POST input “create” is included with the request. Since there is no check for a valid nonce the code is susceptible to cross-site request forgery (CSRF).

The code in that file runs when the plugin’s admin page is accessed. That page is accessible for users with the “publish_posts” capability:

add_menu_page('convert_docx2post', 'Convert Docx', 'publish_posts', 'convert-docx2post/options.php', '', 'dashicons-media-document', 6);

We notified the developer of the issue a week ago. We haven’t heard back from them and no new version has been released to fix the issue. In line with our disclosure policy, which is based on the need to provide our customers with information on vulnerabilities on a timely basis, we are now disclosing this vulnerability.

Proof of Concept

The following proof of concept will upload the selected file to the directory /wp-content/uploads/docx2post/, when logged in as an Author-level users.

Make sure to replace “[path to WordPress]” with the location of WordPress.

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin.php?page=convert-docx2post%2Foptions.php" method="POST" enctype="multipart/form-data">
<input type="file" name="fileToUpload[]" />
<input type="submit" name="create" value="Submit" />
</form>
</body>
</html>

Timeline

  • February 16, 2018 – Developer notified.
22 Feb

Our Proactive Monitoring Caught a PHP Object Injection Vulnerability in a Another Brand New Plugin

One of the ways we help to improve the security of WordPress plugins, not just for our customers, but for everyone using them, is the proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities. That again has lead to us catching a vulnerability of a type that hackers are likely to exploit if they know about it.

This vulnerability is in a brand new plugin, PWAMP, and should have been something that the security review that is supposed to be done before new plugins can be added to the Plugin Directory should have caught. It is something that would have been flagged by our Plugin Security Checker, so it would make sense to run plugins through that during that security review to avoid this type of situation continuing to happen. That it continues to happen speaks to the continued lack of interest in improving security by the leadership of WordPress (starting at the top with Matt Mullenweg) and the continued role we play in limiting the impact of that for everyone else. We would be happy to provide the Plugin Directory team free access to the upload and developer mode capabilities to facilitate that.

The vulnerability occurred in the function after_setup_theme(), located in the file /pwamp.php, where the value of the cookie “pwamp_args” is passed through the unserialize() function, which can lead to PHP object injection:

309
$args = unserialize(stripslashes($_COOKIE['pwamp_args']));

That function will run after the theme is loaded when the device type is set to mobile, which can be done by setting the value of the cookie “pwamp_style” to mobile:

564
add_action( 'after_setup_theme', array($this, 'after_setup_theme') );

After we notified the developer of the issue they released version 1.0.1, which resolves the vulnerability by replacing use of unserialize() with json_decode() (and replaces related use of serialize() with json_encode()):

309
$args = json_decode(stripslashes($_COOKIE['pwamp_args']));

Proof of Concept

With our plugin for testing for PHP object injection installed and activated, set the value of the cookie “pwamp_args” to “O:20:”php_object_injection”:0:{}” and the value of the cookie “pwamp_style” to “mobile”, and then when you visit a frontend page the message “PHP object injection has occurred.” will be shown.

Timeline

  • February 21, 2018 – Developer notified.
  • February 21, 2018 – Developer responds.
  • February 22, 2018 – Version 1.0.1 released, which fixes vulnerability.
15 Feb

Our Proactive Monitoring Caught a PHP Object Injection Vulnerability in Swift Help Desk Support Software Ticketing System

One of the ways we help to improve the security of WordPress plugins, not just for our customers, but for everyone using them, is the proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities. That again has lead to us catching a vulnerability of a type that hackers are likely to exploit if they know about it. Since the check used to spot this is also included in our Plugin Security Checker (which  is now accessible through a WordPress plugin of its own), it is another of reminder of how that can help to indicate which plugins are in greater need of security review (for which we do as part of our service as well as separately).

In the plugin Swift Help Desk Support Software Ticketing System (Help Desk & Knowledgebase Software) the value of a cookie is passed through the unserialize() function, which could lead to PHP object injection. That occurs in two shortcodes accessed functions in the plugin. One of them being swift_helpdesk_support_callback(), which is located in the file /sections/shd-shortcodes.php. Some ways into the function it checks if the cookie “sc_lead_scoring” exists and then unserializes its value:

164
165
if (isset($_COOKIE['sc_lead_scoring']) && !empty($_COOKIE['sc_lead_scoring'])) {
	$sc_lead_scoring_cookie = unserialize(stripslashes($_COOKIE['sc_lead_scoring']));

Even if the shortcodes that cause those functions to run are not used on the website, any one logged in to WordPress could access them, like they can shortcodes in general, through WordPress AJAX functionality and the vulnerability is also exploitable that way as well.

We notified the developer of the issue a week ago. We haven’t heard back from them and no new version has been released to fix the issue. In line with our disclosure policy, which is based on the need to provide our customers with information on vulnerabilities on a timely basis, we are now disclosing this vulnerability.

The Plugin Security Checker has flagged other possible issues in the plugin, so those using the plugin may want to have someone do a thorough review of the plugin’s security.

Proof of Concept

With our plugin for testing for PHP object injection installed and activated, set the value of the cookie “sc_lead_scoring” to “O:20:”php_object_injection”:0:{}” and then when you visit a page on the website using the “swift_helpdesk_support” shortcode the message “PHP object injection has occurred.” will be shown.

Timeline

  • February 8, 2017 – Developer notified.
15 Feb

Our Proactive Monitoring Caught an Authenticated PHP Object Injection Vulnerability in Autoship Cloud

One of the ways we help to improve the security of WordPress plugins, not just for our customers, but for everyone using them, is the proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities. That sometimes leads to us catching a vulnerability of a more limited version of one of those serious vulnerability types, which isn’t as much concern for the average website, but could be utilized in a targeted attack. That happened with the authenticated PHP object injection vulnerability we found in the plugin Autoship Cloud. This vulnerability could have allowed an attacker that had access to a WordPress account that has access to admin pages, which would normally be Subscriber level users and above, to exploit a PHP object injection vulnerability.

Since the check used to spot this is also included in our Plugin Security Checker (which  is now accessible through a WordPress plugin of its own), it is another of reminder of how that can help to indicate which plugins are in greater need of security review (for which we do as part of our service as well as separately).

The vulnerability occurred in the function autoship_get_messages(). That function passed the base64 decoded value of the cookie “autoship_messages” through the unserialize() function, which could lead to PHP object injection:

3
4
5
6
7
function autoship_get_messages() {
	if ( empty( $_COOKIE['autoship_messages'] ) ) {
		return array();
	}
	$messages = unserialize( base64_decode( $_COOKIE['autoship_messages'] ) );

One of the locations that function gets called is in the function autoship_print_messages():

44
45
46
47
48
49
function autoship_print_messages() {
	if ( defined( 'DOING_AJAX' ) && DOING_AJAX ) {
		return;
	}
 
	$messages = autoship_get_messages();

That function runs when admin notices are shown:

68
add_action( 'admin_notices', 'autoship_print_messages' );

After we notified the developer of the plugin they released version 1.0.14, which fixes the vulnerability. Though in a reminder that you can’t rely on changelogs to let you know if a new version of a plugin includes a security fix, the only changelog entry for that version is “Bug fixes.”. The only change made though was to fix the vulnerability. That was done by replacing the use of unserialize() with json_decode():

7
$messages = json_decode( base64_decode( $_COOKIE['autoship_messages'] ) );

and elsewhere in the same file, replacing related usage of serialize() with json_encode():

39
$messages_cookie = base64_encode( json_encode( $messages ) );

Proof of Concept

With our plugin for testing for PHP object injection installed and activated, set the value of the cookie “autoship_messages” to “TzoyMDoicGhwX29iamVjdF9pbmplY3Rpb24iOjA6e30=” and then when you visit an admin page on the website the message “PHP object injection has occurred.” will be shown.

Timeline

  • February 12, 2018 – Developer notified.
  • February 12, 2018 – Developer responds.
  • February 15, 2018 – Version 1.0.14  released, which fixes vulnerability.