In reviewing reports of vulnerabilities in WordPress plugins to provide our customers with the best data on vulnerabilities in plugins they use 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.

Path Traversal in Ad Inserter

One of the changelog entries for version 2.4.20 of Ad Inserter is “Fix for path traversal vulnerability – credit to Wilfried Bécard of Synacktiv (https://synacktiv.com)”. The relevant change looks to have replacing the following lines:

4768

readfile  (AD_INSERTER_PLUGIN_DIR.'images/'.$_GET ["image"]);

4773

readfile  (AD_INSERTER_PLUGIN_DIR.$_GET ["css"]);

Those would allow viewing the contents of arbitrary files through directory traversal in the user input used to specify a file to be viewed. This doesn’t look like a vulnerability due to the fact those are accessed through the AJAX accessible function ai_ajax_backend, which is only accessible to those logged to WordPress and it checks for a valid nonce:

4647
4648
4649
4650
4651

function ai_ajax_backend () {
  global $preview_name, $preview_alignment, $preview_css;
 
//  check_ajax_referer ("adinserter_data", "ai_check");
  check_admin_referer ("adinserter_data", "ai_check");

As far as we can only Administrators would have access to a valid nonce, so we wouldn’t classify this as a vulnerability, since only Administrators can change that and they can do almost anything.

It looks like there should be a capabilities check in addition to the nonce check at the beginning of the file.

We have improved our Plugin Security Checker and our proactive monitoring to catch code similar that going forward.

Authenticated SQL Injection in File Manager

Earlier this week WebARX claimed that the plugin WP File Manager (File Manager) had contained an authenticated SQL injection vulnerability. That involved this AJAX accessible function in the plugin:

147
148
149
150
151
152
153
154
155
156

public function mk_file_manager_backup_remove_callback(){
	global $wpdb;
	$fmdb = $wpdb->prefix.'wpfm_backup';
	$upload_dir = wp_upload_dir();
	$backup_dirname = $upload_dir['basedir'].'/wp-file-manager-pro/fm_backup/';
	$bkpRids = $_POST['delarr'];
	$isRemoved = false;        
	if(isset($bkpRids)) {
		foreach($bkpRids as $bkRid) {
			$fmbkp = $wpdb->get_row('select * from '.$fmdb.' where id = "'.$bkRid.'"');

They described the issue this way:

Since the $bkRid parameter which is taken from the $_POST[‘delarr’] array is used directly in the SQL query, SQL injection also exists.

They didn’t provide a proof of concept and it would seem they didn’t test this out, which they should have done. While the code is not properly protected against SQL injection, preferably by using a prepared statement, there doesn’t look to be a vulnerability there. That is due to the variable being included in the SQL statement in double quotes, so you would need to be able to include more of those to add additional SQL code, but WordPress escapes quote marks included in user input that is then the value of the variable.

XSS in Ultimate Member

That the plugin Ultimate Member would have a security issue isn’t surprising since the developers are continually doing one off security fixes instead of trying to get the plugin fully secured, but a recent claimed vulnerability seems to not exist, at least as described. The claimed steps to reproduce it are as follows:

1. Create custom role, e.g. student
2. Create “profile” page
3. Put <img src=a onerror=alert(1)> near first name

There may be a language issue there, since among other things the plugin doesn’t have a profile page, but an Account page. But when we tried to recreate this it didn’t work. The reason for that seems to be that WordPress itself sanitizes the first name as defined by these lines in the file /wp-includes/default-filters.php:

16
17
18
19
20

foreach ( array( 'pre_term_name', 'pre_comment_author_name', 'pre_link_name', 'pre_link_target', 'pre_link_rel', 'pre_user_display_name', 'pre_user_first_name', 'pre_user_last_name', 'pre_user_nickname' ) as $filter ) {
	add_filter( $filter, 'sanitize_text_field' );
	add_filter( $filter, 'wp_filter_kses' );
	add_filter( $filter, '_wp_specialchars', 30 );
}

The change made that was supposed to fix this just does similar sanitization, which shouldn’t be needed, but if it is, it doesn’t explain why it would only occur with custom roles. It sounds like the person reporting the issue has something else causing that issue.

Plugin Security Scorecard Grade for Ultimate Member

See issues causing the plugin to get less than A+ grade

Plugin Security Scorecard Grade for WP File Manager

See issues causing the plugin to get less than A+ grade