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.