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.
Remote File Upload in Contact Form 7
A claimed remote file upload vulnerability in the plugin in Contact Form 7 is good example of the fact that appearance of credible vulnerability report can be false. While the report has a proof of concept for the claimed issue, which would seem to indicate that the reporter had tested it out, they clearly didn’t. That proof of concept has a request sent directly to a file in the plugin /modules/file.php, but if you sent a request to that file it will cause a fatal error when the first line of code in the file runs:
add_action( 'wpcf7_init', 'wpcf7_add_form_tag_file', 10, 0 );
The referenced code in the file involves a function, wpcf7_file_validation_filter(), which is used to restrict file upload when doing intentional uploads through the plugin.
Cross Site Scripting in Contact Form 7
echo echo esc_attr($_REQUEST['page']);
The actual relevant line of code is this:
<input type="hidden" name="page" value="<?php echo esc_attr( $_REQUEST['page'] ); ?>" />
In either case the user input being output is being escaped esc_attr(), which specifically deals with the potential of cross-site scripting.
The claimed proof of concept doesn’t even get to claimed vulnerable line as a fatal error occurs on line three of the file in question.
Cross Site Scripting in Jetpack
The claimed cross-site scripting (XSS) vulnerability in Jetpack is very similar to the previously mentioned claim of the same type of vulnerability in Contact Form 7 as the supposed vulnerable line restricts user input being output to an integer, so XSS is not possible:
var postId = <?php echo absint( $_GET['post_id'] ); ?>;
Local File Disclosure in Wordfence Security
A claimed local file disclosure vulnerability in Wordfence Security is from the reporter as the first claimed Contact Form 7 vulnerability and very similar in its inaccuracy. The proof of concept has you sending a request to a file /lib/wordfenceClass.php that is not accessible when using the Apache web server due to .htaccess rules. If not using that type server the code referenced won’t run either when accessing the file, so the proof of concept could not work. When the referenced code is actually running there are security restrictions in place.
Local File Inclusion in Ultimate Member
A claimed local file inclusion vulnerability in Ultimate Member from the same reporter as the previously mentioned reports is equally inaccurate. The proof of concept has you send a request to the file /includes/admin/core/class-admin-upgrade.php, where the first code that runs restricts direct access:
if ( ! defined( 'ABSPATH' ) ) exit;
Even without that code the referenced code couldn’t be accessed by directly accessing the file. There are security restrictions in place with the relevant code, though they could be improved, something that would be flagged by the security reviews of plugins we do.
Cross Site Scripting in WP Sitemap Page
With a claimed cross site scripting vulnerability in WP Sitemap Page the proof of concept indicates that there might not be a vulnerability as it involves making a change to the plugin’s settings, which would usually be accessible by users with the capability to do the equivalent of cross-site scripting (XSS). That is the case with this plugin as you need to be an Administrator to access the relevant page:
153 154 155 156
$capability = 'administrator'; $menu_slug = 'wp_sitemap_page'; $function = 'wsp_settings_page'; // function that contain the page add_options_page( $page_title, $menu_title, $capability, $menu_slug, $function );
The page also includes a valid nonce to prevent there being an issue with cross-site request forgery (CSRF).
The plugin’s code could more securely handle this, which we have suggested to the developer.