While we already are far ahead of other companies in keeping up with vulnerabilities in WordPress plugins (amazingly that isn’t an exaggeration), in looking in to how we could get even better we noticed that in an instances where a vulnerability was exploited in a plugin, we probably could have warned our customers about the vulnerability even sooner if we had looked at the plugin when it was first closed on the Plugin Directory instead of when the vulnerability was fixed (though as far as we are aware the exploitation started after we had warned our customers of the fix). So we are now monitoring to see if any of the 1,000 most popular plugins are closed on the Plugin Directory and then seeing if it looks like that was because of a vulnerability.

Today the plugin qTranslate X, which has 100,000+ installs, was closed. No reason has been given for the closure. While we didn’t find any obvious serious security issues in a quick check, what we did find is that the plugin is insecure and some of that insecurity is hard to follow, so it is possible that it has a more serious issue that is difficult to spot.

We would recommend not using the plugin unless it has the code cleaned up, so that it is possible for the security of it to be reasonably checked.

Cross-Site Request Forgery (CSRF)

As an example of the insecurity, take the following code where security code exists, but it turns out that it doesn’t always function when it should, leading to various code being insecure.

The function qtranxf_admin_init() runs during admin_init, so when admin pages are loaded:

211

add_action('admin_init','qtranxf_admin_init',2);

That function in turn will cause the function qtranxf_editConfig() to run when accessing a URL and logged in as an Administrator:

168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183

function qtranxf_admin_init(){
	global $q_config, $pagenow;
	//qtranxf_dbg_log('5.qtranxf_admin_init:');
 
	add_action('admin_notices', 'qtranxf_admin_notices_config');
 
	if ( current_user_can('manage_options')
		&& $pagenow == 'options-general.php'
		&& isset($q_config['url_info']['query'])
		&& strpos($q_config['url_info']['query'], 'page=qtranslate-x') !== false
		//&& !empty($_POST) //todo run this only if one of the forms or actions submitted
	){
		$q_config['url_info']['qtranslate-settings-url'] = admin_url('options-general.php?page=qtranslate-x');
		require_once(QTRANSLATE_DIR.'/admin/qtx_admin_options_update.php');
		//call_user_func('qtranxf_editConfig');
		qtranxf_editConfig();

At the beginning of that function, which is in the file /admin/qtx_admin_options_update.php, it appears to check for a valid nonce to prevent cross-site request forgery (CSRF):

7
8
9

function qtranxf_editConfig(){
	global $q_config;
	if(!qtranxf_verify_nonce('qtranslate-x_configuration_form')) return;

The problem is that it actually only checks for a valid nonce if there is POST input with the request:

902
903
904

function qtranxf_verify_nonce($nonce_name, $nonce_field = '_wpnonce') {
	return empty( $_POST ) || check_admin_referer( $nonce_name, $nonce_field );
}

If you look at the rest of the code in qtranxf_editConfig() there is functionality that should be protected with a nonce that only involves GET input, so the nonce check doesn’t run. Here, for example, is the code to enable one of the plugins languages:

195
196
197
198
199
200
201

		elseif(isset($_GET['enable'])){
		$lang = sanitize_text_field($_GET['enable']);
		// enable validate
		if(!qtranxf_enableLanguage($lang)) {
			$errors[] = __('Language is already enabled or invalid!', 'qtranslate');
		}
	}

WordPress Causes Full Disclosure

Because of the moderators of the WordPress Support Forum’s continued inappropriate behavior we changed from reasonably disclosing to full disclosing vulnerabilities for plugins in the WordPress Plugin Directory in protest, until WordPress gets that situation cleaned up, so we are releasing this post and then leaving a message about that for the developer through the WordPress Support Forum. (For plugins that are also in the ClassicPress Plugin Directory, we will follow our reasonable disclosure policy.) You can notify the developer of this issue on the forum as well. Hopefully, the moderators will finally see the light and clean up their act soon, so these full disclosures will no longer be needed (we hope they end soon). You would think they would have already done that, but considering that they believe that having plugins, which have millions installs, remain in the Plugin Directory despite them knowing they are vulnerable is “appropriate action”, something is very amiss with them (which is even more reason the moderation needs to be cleaned up).

Update: To clear up the confusion where developers claim we hadn’t tried to notify them through the Support Forum (while at the same time moderators are complaining about us doing just that), here is the message we left for this vulnerability:

Is It Fixed?

If you are reading this post down the road the best way to find out if this vulnerability or other WordPress plugin vulnerabilities in plugins you use have been fixed is to sign up for our service, since what we uniquely do when it comes to that type of data is to test to see if vulnerabilities have really been fixed. Relying on the developer’s information can lead you astray, as we often find that they believe they have fixed vulnerabilities, but have failed to do that.

Proof of Concept

The following proof of concept will enable the German language, when logged in as an Administrator.

Replace “[path to WordPress]” with the location of WordPress.

http://[path to WordPress]/wp-admin/options-general.php?page=qtranslate-x&enable=de#languages

Concerned About The Security of the Plugins You Use?

Need Continued Support for a Closed Plugin?