08 Feb

Not Really a WordPress Plugin Vulnerability, Week of February 8

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 Request Forgery / Shell Upload Vulnerability in Ultimate Member

Recently many of the claimed vulnerabilities we have mentioned in these posts have come from someone with the handle “KingSkrupellos” that the website Packet Storm continues to allow to post false reports. They were at it again with a claimed cross site request forgery / shell upload vulnerability in Ultimate Member. In this case they claim that there is vulnerability in the latest version of the plugin involving files that don’t exist in it.

In the older version of the plugin they also mention, which includes those files, they seem to be confusing an error indicating that the file upload code has not run, ‘{“error”:”A theme or plugin compatibility issue”}’, as meaning that a file has been uploaded.

Shell Upload Vulnerability in WP User Manager

The claimed shell upload vulnerability in WP User Manager seemed false based on this based on this part of the proof of concept, “you can upload your shell by adding image extensions to end of your shell. (ex: SHELL.php.png)”. Since the file has an image extension the server shouldn’t see it as type of file that allows code to run, so it wouldn’t be “shell”. The uploading is handled through the WordPress function wp_handle_upload(), so if someone wants to claim there is an issue with allowing dual extensions, then they should be labeling it as a security issue with WordPress.

Cross-Site Scripting (XSS) Vulnerability in Parallax Scroll

With a claimed vulnerability in Parallax Scroll the tip off that something might be amiss came with the claimed vulnerability be listed as a cross-site scripting (XSS) vulnerability, despite usually there being a modifier included (for example a reflected XSS or a persistent XSS). Looking at the changes made that were supposed to fix this, it involved outputting the value of the WordPress function get_the_title(), which returns the title of a post. WordPress shouldn’t be outputting values that lead to unintended XSS and in fact it isn’t. What we found was that this involved a custom post type, where the title allows JavaScript code only if the user has the “unfiltered_html” capability, which permits the equivalent of XSS. To put this another way, even without this plugin installed the users who could create customs posts through it, could do the same thing that was supposed to be a vulnerability, but just by creating a normal post or page.

One thought on “Not Really a WordPress Plugin Vulnerability, Week of February 8

Leave a Reply

Your email address will not be published. Required fields are marked *