11 Oct

Authenticated Option Deletion Vulnerability in My WP Translate

Recently we went to check on a report of a cross-site scripting (XSS) vulnerability in the plugin My WP Translate and while looking into that we noticed that there were a number AJAX accessible functions that didn’t have the proper protection so that anyone logged in could access them. That is an all too common situation. On a lot of websites that wouldn’t matter much since the only user account is an Administrator, so that if someone gains access to the account they can do whatever they want already, or only trusted individuals have accounts. For websites that do allow untrusted users to have accounts taking extra precautions when it comes to plugins is a good idea. That can include limiting the number of plugins you use and for the highest assurance getting a security review done of them (we do security reviews of plugins suggested/voted for by our customers and also offer a separate service if just want to purchase a review).

Often times the intended functionality of an AJAX accessible function is dangerous for lower level users to have access to, but it is also possible that the code can used to take other action they intended. In the case of this plugin we found that it is possible to use one of those functions to delete WordPress options (settings).  As we discovered with a very similar vulnerability more than a year ago, that can be used to disable a website with a single request.

The plugin made the function ajax_mtswpt_remove_plugin() accessible through WordPress AJAX functionality to only those logged in:

$this->loader->add_action( 'wp_ajax_mtswpt_remove_plugin', $plugin_admin, 'ajax_mtswpt_remove_plugin' );

The function, located in the file /admin/class-my-wp-translate-admin.php, doesn’t perform any check on the capabilities of the user (only users with the “manage_options” capability should be able to access it) or check for protection against cross-site request forgery (CSRF). Instead the first thing it does is the value of the POST input “plugin_tab” to variable “$plugin_tab “:

public function ajax_mtswpt_remove_plugin() {
	$plugin_tab = $_POST['plugin_tab'];

Later in the code it checks if an option with name that matches the variable’s value exists and if it does, the option is deleted:

if ( false !== get_option( $plugin_tab, false ) ) {
	delete_option( $plugin_tab );

If you were to use that to delete “site_url” option, it would cause requests for the frontend of the website to show the message “Error establishing a database connection” instead of the intended page content and requests for the admin area to only have the message “One or more database tables are unavailable. The database may need to be repaired.” If you do try a database repair, the result with be that it won’t fix this, but it will be indicated that the options table, where the deleted option existed, “is okay”, which seems unhelpful.

In version 1.0.4 the function has been renamed and a check for a nonce, to prevent CSRF has been added:

public function ajax_remove_plugin() {
	check_ajax_referer( 'my-wp-translate', 'security' );

No capabilities check was added, but the nonce is only accessible on the plugin’s admin page, so under normal circumstances that would do the equivalent of a capabilities check, though it would better to check for capabilities as it is possible that a nonce could be compromised.

Proof of Concept

The following proof of concept will delete the siteurl option wp_options table, when logged in to WordPress.

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

<form action="http://[path to WordPress]/wp-admin/admin-ajax.php" method="POST">
<input type="hidden" name="action" value="mtswpt_remove_plugin" />
<input type="hidden" name="plugin_tab" value="siteurl" />
<input type="submit" value="Submit" />


  • October 9, 2017 – Developer notified.
  • October 10, 2017 – Developer responds.
  • October 10, 2017 – Version 1.0.4 released, which fixes vulnerability.
11 Oct

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in My WP Translate

From time to time a vulnerability is fixed in a plugin without the discoverer putting out a report on the vulnerability and we will put out a post detailing the vulnerability so that we can provide our customers with more complete information on the vulnerability.

Recently the web scanner service Detectify has been vaguely disclosing minor vulnerabilities in a number of WordPress plugins. It seems ...

Our Vulnerability Details posts provide the details of vulnerabilities we didn't discover and access to them is limited to customers of our service due to other security companies trying to sponge off the work needed to create those instead of doing their own work.

For existing customers, please log in to your account to view the rest of the post.

If you are not currently a customer, you can try the service for free for the first month (there are a lot of other reason that you will want to sign up beyond access to posts like this one).

If you are a WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.