11 May

Not Really a WordPress Plugin Vulnerability – Week of May 11, 2018

In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we release posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. For those that don’t rise to level of getting their own post we now place them in a weekly post when we come across them.

Cross-Site Scripting (XSS) Vulnerability in CKEditor WYSIWYG for Gravity Forms

The changelog entry for version 1.14.0 of the plugin CKEditor WYSIWYG for Gravity Forms is:

Fix: Upgrade CKEditor to 4.9.2. Includes security patch to resolve XSS vulnerability https://ckeditor.com/blog/CKEditor-4.9.2-with-a-security-patch-released/

Looking at the information in the URL mentioned in that though we found that the vulnerability only impacts usage of CKEditor when the Enhanced Image (image2) plugin is included:

CKEditor 4.9.2 fixes an XSS vulnerability in the Enhanced Image (image2) plugin reported by Kyaw Min Thein. The vulnerability stemmed from the fact that it was possible to execute XSS inside CKEditor using the <img> tag and specially crafted HTML.

Please note that the default presets (Basic/Standard/Full) do not include this plugin, so you are only at risk if you made a custom build and enabled this plugin.

CKEditor WYSIWYG for Gravity Forms doesn’t include that, so there wasn’t a vulnerability previously in the plugin.

04 May

Not Really a WordPress Plugin Vulnerability – Week of May 4, 2018

In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we release posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. For those that don’t rise to level of getting their own post we now place them in a weekly post when we come across them.

Persistent Cross-Site Scripting (XSS) Vulnerability in WF Cookie Consent

Last week we discussed basically the same exact claimed persistent cross-site scripting vulnerability as is now claimed to be in the plugin WF Cookie Consent with a similarly named plugin Cookie Consent. As with that one the first three steps have no connection with the plugin:

1) Access WordPress control panel.
2) Navigate to the ‘Pages’.
3) Add a new page and insert the script you wish to inject into the page title.
4) Now navigate to ‘Settings’ and select ‘WF Cookie Consent’.
5) Your injected script will now be executed.

As with the other claimed vulnerability, what seems to have happened here is that the person behind this doesn’t understand that Administrator level-users (as well as the only other users, Editors, that can create pages by default) normally have the unfiltered_html capability, which allows them to do the equivalent of cross-site scripting (XSS). In this situation if at step four you had instead visited the page created in steps 1-3 the script would also run, so other than this occurring on an admin page the same result would occur without the plugin.

If a user could create new pages and didn’t have the unfiltered_html capability they wouldn’t be able save a script to a page’s title in the first place, so there wouldn’t be an issue when the plugin’s page is accessed.

27 Apr

Not Really a WordPress Plugin Vulnerability – Week of April 27, 2018

In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we release posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. For those that don’t rise to level of getting their own post we now place them in a weekly post when we come across them.

Persistent Cross-Site Scripting (XSS) Vulnerability in Cookie Consent

With a claimed persistent cross-site scripting (XSS) vulnerability in the plugin Cookie Consent the proof of concept didn’t make a lot of sense to us:

1) Access WordPress control panel.
2) Navigate to the ‘Pages’.
3) Add a new page and insert the script you wish to inject into the page title.
4) Now navigate to ‘Settings’ and select ‘Cookie Consent’.
5) Now click on the ‘Content’ tab.
6) Your injected script will now be executed.

It wasn’t at all clear what was supposed to be the connection between the actions in steps 1-3 and the plugin. It turns out there really isn’t any.

What seems to have happened here is that the person behind this doesn’t understand that Administrator level-users (as well as the only other users, Editors, that can create pages by default) normally have the unfiltered_html capability, which allows them to do the equivalent of cross-site scripting (XSS). In this situation if at step four you had instead visited the page created in steps 1-3 the script would also run, so other than this occurring on an admin page the same result would occur without the plugin.

If a user could create new pages and didn’t have the unfiltered_html capability they wouldn’t be able save a script to a page’s title in the first place, so there wouldn’t be an issue when the plugin’s page is accessed.

Persistent Cross-Site Scripting (XSS) Vulnerability in Responsive Cookie Consent

The person behind that claim made also made a claim of the same type of vulnerability in the plugin Responsive Cookie Consent, which we found on another data source of plugin vulnerabilities, the WPScan Vulnerability Database, which doesn’t do the same type of checking we do before adding claimed vulnerabilities.

In this case the claimed vulnerability at least was connected directly with the plugin:

1) Access WordPress control panel.
2) Navigate to the Responsive Cookie Consent plugin page.
3) Select one of the input fields. For example, “Cookie Bar Border Bottom Size”.
4) Insert the script you wish to inject.
5) Save the plugin settings.
6) Injected script will run in the victim user’s browser. Depending on which input field you inserted the script, the script may also run everytime you load the Responsive Cookie Consent plugin page.

As we explained with the previous claimed vulnerability, Administrator level-users are normally have the unfiltered_html capability, which allows them to do the equivalent of cross-site scripting (XSS), so if only they have access to it, it wouldn’t really be a vulnerability. Looking at the code that sets up the admin page for the plugin, we could see that it is limited to those with the “manage_options” capability:

4
add_submenu_page('options-general.php', __('RCC Settings', 'responsive-cookie-consent'), 'RCC', 'manage_options', 'rcc-settings', 'rcc_options_page');

Users with the “manage_options” capability would normally only be Administrators (and if others are given the capability they would normally be able to create Administrators accounts).

There still was the possibility have been an issue if there was a lack of protection against cross-site request forgery (CSRF), but we found that is properly protected against.

13 Apr

Not Really a WordPress Plugin Vulnerability – Week of April 13, 2018

In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we release posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. For those that don’t rise to level of getting their own post we now place them in a weekly post when we come across them.

Persistent Cross-Site Scripting (XSS) Vulnerabilities in WordPress File Upload

This week there were a couple of reports of claimed persistent cross-site scripting (XSS) vulnerabilities in WordPress File Upload that were supposed to have been fixed in version 4.3.3 and 4.3.4. For both of them, the proof of concept indicated that the claimed vulnerability would be exploited when logged in to WordPress. In testing things out it looked to us that you would need to be logged in as an Administrator to access them. That was confirmed by looking at the code. The page on which the issues occurred through is only accessible in the admin area of WordPress if the user has the “manage_options” capability:

21
if ( current_user_can( 'manage_options' ) ) $page_hook_suffix = add_options_page('Wordpress File Upload', 'Wordpress File Upload', 'manage_options', 'wordpress_file_upload', 'wordpress_file_upload_manage_dashboard');

Users with the “manage_options” capability would normally only be Administrators (and if others are given the capability they would normally be able to create Administrators accounts). Those users would normally have the “unfiltered_html” capability and therefore could do the equivalent of persistent XSS, so those issues wouldn’t really be vulnerabilities.

There also was already protection against cross-site request forgery (CSRF) in place for both of the issue, so there was not CSRF/XSS vulnerability that had existed either.

05 Apr

Real World Result of RIPS Code Analysis Service Doesn’t Match Hyperbolic Marketing of It

Recently there was claim made that an authenticated SQL injection vulnerability had been fixed in the plugin Custom Permalinks. In looking into that though we found that it was only accessible to Administrators, who would already normally have the capability to do the equivalent of SQL injection, so that wouldn’t really be a vulnerability. What seems notable about this is that the claim of the vulnerability came from the maker of an automated security tool that is marketed out of line with the actual result shown by that vulnerability claim.

The tool is marketed with claims like this:

RIPS code analysis detects critical security issues in your PHP application without false positive noise.

While we wouldn’t describe that issue as a false positive, it also is far from a critical security issue. The reality is that automated tools like that tool or are Plugin Security Checker have serious limits in what they can do (something that the rest of the marketing material for RIPS doesn’t give any hint of) and are best used by knowledgeable professionals that can properly integrate the results in to a larger security process.

The rest of the marketing just on its homepage is rather over the top as well, with phrases like “unique PHP analysis”, “most accurate”, “unmatched bug detection”, “precise detection”, “no other solution can find”, “leading performance”, and “in-depth security analysis”. None of that is linked to pages that attempt to back up the claims, which is less than reassuring about the capabilities of the tool and the people behind it.

What we found when we went to look in to this claim, backs up that concern, as a rather obvious security vulnerability actually exists in the functionality they claimed contained the authenticated SQL injection vulnerability.

While only Administrators could access that claimed vulnerability directly, it was still possible that there could be a way to exploit it if two conditions were met. The first being that there wasn’t protection against cross-site request forgery (CSRF) and that the request to exploit it was a GET request. The proof of concept provided for it ruled out that possibility since it involved a POST request:

Send authenticated POST request to “URL/wp-admin/admin.php?page=custom-permalinks-post-permalinks” with parameters “action=delete&permalinks[]=1) PAYLOAD — “

But that would seem to indicate that there wasn’t protection against CSRF, which in this case would mean that if an attacker could get a logged in Administrator to visit a URL the attacker controls they could cause permalinks created by the plugin to be deleted.

We first confirmed that was the case in a web browser and then we reviewed the underlying code to see all that was going on behind the scenes.

The plugin’s admin page PostTypes Permalinks is only accessible to those with the “administrator” role and accessing it calls the posttype_permalinks() function (in the file /admin/class-custom-permalinks-admin.php):

add_submenu_page( 'cp-post-permalinks', 'PostTypes Permalinks',
	'PostTypes Permalinks', 'administrator', 'cp-post-permalinks',
	array( $this, 'posttype_permalinks' )
);

Near the top of the function it checks if several POST inputs exists and if they exist it will delete the specified permalinks:

52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
public function posttype_permalinks() {
	global $wpdb;
	$filter_options   = '';
	$filter_permalink = '';
	$search_permalink = '';
	$html             = '';
	$error            = '';
 
	// Handle Bulk Operations
	if ( ( isset( $_POST['action'] ) && $_POST['action'] == 'delete' )
		|| ( isset( $_POST['action2'] ) && $_POST['action2'] == 'delete' )
		&& isset( $_POST['permalink'] ) && ! empty( $_POST['permalink'] ) ) {
		$post_ids = implode( ',', $_POST['permalink'] );
		if ( preg_match( '/^\d+(?:,\d+)*$/', $post_ids ) ) {
			$wpdb->query( "DELETE FROM $wpdb->postmeta WHERE post_id IN ($post_ids) AND meta_key = 'custom_permalink'" );

There is no check for a nonce, which would prevent cross-site request forgery (CSRF), before the deletion happens.

We notified the developer of the plugin of the issue on February 26 and they replied the next day that the issue would be fixed “ASAP”. Earlier today, for the first time since we contacted them a new version was released, but it didn’t make any change related to the vulnerability.

Proof of Concept

The following proof of concept will delete the permalinks with IDs 1 and 2, when logged in as Administrator.

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=cp-post-permalinks" method="POST" >
<input type="hidden" name="action" value="delete" />
<input type="hidden" name="permalink[]" value="1" />
<input type="hidden" name="permalink[]" value="2" />
<input type="submit" value="Submit" />
</form>
</body>
</html>

Timeline

  • February 26, 2018 – Developer notified.
  • February 27, 2018 – Developer responds.
08 Dec

Not Really a WordPress Plugin Vulnerability – Week of December 8, 2017

In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we have been releasing posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. We have been thinking that providing information on why those are not included in our service’s data could be useful, so we are trying out putting a weekly post when that occurs detailing those issues.

Directory Traversal Vulnerability in WooCommerce

A lot of reports of vulnerabilities that turn out to be false at least seem to have a valid basis, but occasionally you have truly strange ones. The claim of a directory traversal vulnerability in WooCommerce falls into the latter category. The claim made is:

Identifying woo commerce theme pluging properly sanitized against Directory Traversal,even the latest version of WordPress with woocommerce can be vulnerable.

Directory traversal refers to the ability to move outside of a specified directory, it isn’t a vulnerability on its own, just something that could be a piece of a vulnerability. An example of where that could come in to play as a vulnerability would be if you had code that allows downloading files from a particular directory and directory traversal could be used to download files outside of it.

The proof of concept included with the claim simply makes a request to the URL /wp-content/plugins/woocommerce/templates/emails/plain/. If you were to take a look at the latest version of WooCommerce you would see that in that directory there is no index file that would be served when requesting that, so there couldn’t be any code running for there to be directory traversal. There isn’t anything in the proof of concept code that shows an attempt to do anything related to directory traversal either.

What looks to be going on here is that the person behind this thinks that seeing a list of the files in the directory, if a server is configured to do that when there isn’t an index file, would be a vulnerability here. On the same vulnerability database we saw their claim of a directory traversal vulnerability they had submitted a Google dork for “intext:/wp-content/plugins/woocommerce/templates/emails/plain/” and wrote:

When you dork with this,it will generate juciy information in parent directory , for best practice filter according to the country .

That isn’t true though. You should already know what the files that are that directory since the directory shouldn’t contain files that don’t come with the plugin (custom template files would be located in theme being used not in the plugins directory structure).

Somehow, despite the issue being claimed here not actually being a vulnerability on in its own, this has been assigned a CVE number.

01 Dec

Not Really a WordPress Plugin Vulnerability – Week of December 1, 2017

In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we have been releasing posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. We have been thinking that providing information on why those are not included in our service’s data could be useful, so we are trying out putting a weekly post when that occurs detailing those issues.

Cross-Site Scripting (XSS) Vulnerability in amtyThumb and amtyThumb posts

The claim of a cross-site scripting (XSS) vulnerability in amtyThumb posts is a bit confusing as it is stated that

amtyThumb posts Plugin is prone to a stored cross-site scripting vulnerability because it fails to sufficiently sanitize user-supplied data.

and

The XSS reflected because the values are not filter correctly:

So they are claiming it is a stored (or as we refer to that type of vulnerability, persistent) XSS, a reflected, or maybe both.

The proof of concept given is:

/wordpress/wp-content/plugins/amty-thumb-recent-post/amtyThumbPostsAdminPg.php?”><script>alert(“XSS”)</script>=1

Looking at the underlying code in the file /amty-thumb-recent-post/amtyThumbPostsAdminPg.php it looks like what they are claiming is the vulnerability are in two instances of the following code:

echo str_replace( '%7E', '~', $_SERVER['REQUEST_URI']);

That could would output the variable $_SERVER[‘REQUEST_URI’] without escaping it, which theoretically could lead to reflected cross-site scripting (XSS). But, as we wrote in another of these series of post, that wouldn’t normally be an issue:

The claim that $_SERVER[‘REQUEST_URI’] is unescaped is partially true. While there isn’t any escaping of that done by PHP or WordPress, the value would normally be encoded due to URLs being encoded when sent from web browsers. That would act as escaping. That would normally mean that reflected cross-site scripting (XSS) could not occur due to this issue.

So there doesn’t appear to be the vulnerability as claimed, though there is a reflected XSS elsewhere in the code that we are in the process of trying to notifying the developer of.

After we wrote up the above details, we ran across a related claim of the vulnerability in the plugin plugin amtyThumb, which confirmed our analysis of what was claimed to be an issue in the other plugin. That issue has been given a CVE, despite really not existing either.

10 Nov

Not Really a WordPress Plugin Vulnerability – Week of November 10, 2017

In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we have been releasing posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. We have been thinking that providing information on why those are not included in our service’s data could be useful, so we are trying out putting a weekly post when that occurs detailing those issues.

SQL Injection Vulnerability in Simple Events Calendar

With a claimed SQL injection vulnerability in the plugin Simple Events Calendar the claim seems shaky before even getting in to the details as it is stated that “Type user acces: administrator user.” If a vulnerability has to be exploited by an Administrator it likely isn’t a vulnerability, since those users normally have the ability to do almost anything (including editing a plugin to remove security code or adding another plugin that can take the action that could be done through the vulnerability).

Where there still could be an issue is with cross-site request forgery (CSRF), which causes a user to take an action they didn’t intend to. The plugin doesn’t include protection against CSRF before the claimed vulnerable code runs, which ends up being part of a real vulnerability we saw while reviewing this claimed vulnerability (and we will disclose that after the developer has had a chance to fix it). With the type of SQL query in claimed vulnerable code that could mean there is a vulnerability if the value of a GET input is involved (which is something we really should have put up a post on by now), but in this case the value involved is from a POST input:

312
313
$edit_event = $_POST['event_id'];
$update = $wpdb->get_results(" SELECT * FROM $table_name WHERE id = $edit_event ", "ARRAY_A");

Since an attacker can’t get back the result of the query in through CSRF in this situation, there isn’t a vulnerability there. While there isn’t a vulnerability, the code could be improved by using a prepared statement and validating the input (since it should only be an integer).

The person behind the claim stated that “Vendor no finded”. We are not sure what that means as the developer’s website is listed both on the plugin’s page on the Plugin Directory and in a couple of place in the WordPress admin area when the plugin is installed. We have notified the developer of the disclosure and the possible improvements.

03 Nov

Not Really a WordPress Plugin Vulnerability – Week of November 3, 2017

In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we have been releasing posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. We have been thinking that providing information on why those are not included in our service’s data could be useful, so we are trying out putting a weekly post when that occurs detailing those issues.

Full Path Disclosure in Inline Image Upload for BBPress

At the end of September we mentioned that the website WPCampus wasn’t properly crediting us when discussing things we had written, but it isn’t just us that is true with us. Last week in their post on plugin vulnerabilities they credited Wordfence for discovering a vulnerability, but for the other claimed issue they discussed they left out any mention of the discoverer:

For this week’s unfixed vulnerabilities, the Full Path Disclosure issue with the Inline Image Upload for BBPress (and it’s Pro version) isn’t a vulnerability by itself, but can be used in combination with other attacks that require knowing the server path. Hopefully the vendor will release a fix soon, but if not, you can mitigate this issue by ensuring display_errors is disabled for php for your site.  The specifics of how you disable it will depend on your hosting set up.  If you’re not sure, contact your hosting provider or system administrator.

In looking at the linked spreadsheet with the details, we immediately noticed it looked like this wasn’t really a vulnerability as it said in the note for it, “Ensure error_reporting/display_errors is turned off/disabled”. As we noted back in May with a claim made by Wordfence if you consider this a vulnerability then WordPress is also vulnerable:

So is that a vulnerability? We would say probably not if it doesn’t display when error reporting isn’t enabled (though the issue in this plugin could easily be fixed), but if it is, there is a much larger issue because the same thing will occur in the core WordPress software. For example, if you were to visit /wp-includes/wp-diff.php with error reporting enabled you would get this:

Warning: require(ABSPATHWPINC/Text/Diff.php): failed to open stream: No such file or directory in [redacted]/public_html/pluginvulnerabilities.com/wp-includes/wp-diff.php on line 13

Fatal error: require(): Failed opening required ‘ABSPATHWPINC/Text/Diff.php’ (include_path=’.:/usr/local/lib/php’) in [redacted]/public_html/pluginvulnerabilities.com/wp-includes/wp-diff.php on line 13

WPCampus isn’t the only source of WordPress plugin vulnerabilities passing along inaccurate information on vulnerabilities that we ran across this week. During our monitoring of the WordPress Support Forum we looked at thread bringing up a claimed vulnerability in the plugin Comment Attachment. The message from the plugin Vulnerable Plugin Checker that uses data from the WPScan Vulnerability Database shown in the thread stated:

Comment Attachment has a known vulnerability that may be affecting this version. Please update this plugin.

Comment Attachment 1.0 – XSS

That isn’t all that helpful to someone trying to figure out what is going on. Looking at the relevant entry in WPScan’s data pointed to the source of the claim. The instructions for exploiting the claimed issue are as follows:

1) Download “Comment Attachment” And Install
2) Go To Sitting Comment Attachment :
Settings > Discussion > Comment Attachment
3) Insert In “Attachment field title” This Code And Save :
“><script>alert(/Arsan/)</script>
4) And Try To See Your Post And Comment; Follow Link :
http://localhost/wp/?p=1

To access that page you have to have the “manage_options” capability. Users with the “manage_options” capability would normally only be Administrators (and if others are given the capability they would normally be able to create Administrators accounts), which would normally have the “unfiltered_html” capability and therefore could do the equivalent of this.

13 Oct

Not Really a WordPress Plugin Vulnerability – Week of October 13, 2017

In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we have been releasing posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. We have been thinking that providing information on why those are not included in our service’s data could be useful, so we are trying out putting a weekly post when that occurs detailing those issues.

Directory Traversal Vulnerability in WP Smush

There recently was a report of a directory traversal vulnerability in WP Smush. If you believed the developers (who are also the developer of a security plugin) this is a vulnerability, the changelog for version 2.7.6 is:

  • Security: Fixed path traversal vulnerability. Thanks Ricardo Sánchez(@neorichi) for responsible disclosure.

The report provides a link that is supposed to confirm that it is a vulnerability, that link is to this comment in a thread on the WordPress Support Forum:

@neorichi, Just to update you, we’ve a new security release to fix the bug.

Appreciate your efforts to report this responsibly.

Cheers, Umesh

Looking at the proof of concept it seemed like something might be off about this, as it seemed that you might need a nonce to exploit the issue, but the report doesn’t explain whether a valid nonce is needed or not and if so, where it could be found:

http://localhost/wordpress/wp-admin/admin-ajax.php?dir=../../../../../../&multiSelect=true&action=smush_get_directory_list&list_nonce=xxxxxxx

That URL indicates that an AJAX accessible function is being accessed. Looking at version 2.7.5 that function is only accessible to those logged in, which is not noted in the report (that would make this an authenticated vulnerability at least):

43
add_action( 'wp_ajax_smush_get_directory_list', array( $this, 'directory_list' ) );

Looking the function being accessed, directory_list(), which is located in the file /lib/class-wp-smush-dir.php, you can see that before it checks for a valid nonce it checks to make sure the user making the request has the “manage_options” capability:

341
342
343
344
345
346
347
function directory_list() {
	//Check For Permission
	if ( ! current_user_can( 'manage_options' ) || ! is_user_logged_in() ) {
		wp_send_json_error( "Unauthorized" );
	}
	//Verify nonce
	check_ajax_referer( 'smush_get_dir_list', 'list_nonce' );

Users with the “manage_options” capability would normally only be Administrators (and if others are given the capability they would normally be able to create Administrators accounts), which would normally have the ability to view the directory structure with their capabilities, so this isn’t really a vulnerability.

If you are going to claim this is a vulnerability (as the folks at ThreatPress,  WPCampus, and the WPScan Vulnerability Database have) we don’t see how it could be claimed that it is fixed as the change just restricts you to accessing directories within in the WordPress directory:

349
350
351
352
353
354
355
356
357
358
359
//Get the Root path for a main site or subsite
$root = realpath( $this-&gt;get_root_path() );
 
$dir     = isset( $_GET['dir'] ) ? ltrim( $_GET['dir'], '/' ) : null;
$postDir = strlen( $dir ) &gt; 1 ? path_join( $root, $dir ) : $root . $dir;
$postDir = realpath( rawurldecode( $postDir ) );
 
//If the final path doesn't contains the root path, bail out.
if ( !$root || $postDir === false || strpos( $postDir, $root ) !== 0 ) {
	wp_send_json_error( "Unauthorized" );
}

Persistent Cross-Site Scripting (XSS) Vulnerability in Contact Widgets

A frequent source of false claims of vulnerabilities in WordPress plugins is a lack of understanding of the WordPress security model. WordPress has a capability “unfiltered_html” that allows users to do the equivalent of cross-site scripting (XSS), which in simply terms is just the ability to use JavaScript code. A claim of a persistent cross-site scripting (XSS) vulnerability in the plugin Contact Widgets  involved adding JavaScript code to a widget that is part of the plugin. Normally only Administrators are allowed to edit widgets, so the testing likely was done with a user who has the ability to do the equivalent of the vulnerability.

In one of the responses to the claim, one of the developers responded:

Then this is not a bug. We explicitly allow Administrators to do whatever they want in the widget via that unfiltered_html permission, just as core does with the Text widget.

Looking at the code here is what he is talking about (in the file /includes/class-contact.php):

201
'sanitizer'     =&gt; function( $value ) { return current_user_can( 'unfiltered_html' ) ? $value : wp_kses_post( stripslashes( $value ) ); },

Just to further confirm things were working correctly, we gave an Author level user, who doesn’t have the “unfiltered_html” capability, the ability to edit widgets by giving them the “edit_theme_options” and then tried the proof of concept. As expected the malicious input was sanitized and there was not exploitation, so there isn’t a vulnerability here at all.