20 Mar

False Vulnerability Report: Store XSS Vulnerability in WP Markdown Editor

As part of our cataloging the vulnerabilities in WordPress plugins for our service we come across false reports of vulnerabilities from time to time. So that others don’t spend their time looking over these as well, we post our findings on them. The data on these false reports is also included in our service’s data.

When it comes to false reports of vulnerabilities in WordPress plugins some of them don’t set off any red-flags until you start to look closely at them. Others, like a recent report claiming there was persistent cross-site scripting (XSS) in the plugin WP Markdown Editor set off multiple red-flags with the just a quick glance, though they still require being fully checked as some reports of actual vulnerabilities end up being quite of poor quality.

The first red-flag in the report was that there was no code or other detailed information provided; instead the report consisted entirely of a small amount of text and three screenshots. If the person behind the report hadn’t looked at the underlying code, they could have missed important information that would have let them understand if a vulnerability actually existed or not.

That issue is particularly acute in this case because the screenshots showed saving JavaScript code on the page for adding a new post to WordPress and being saved. Normally both Editor and Administrator-level users are allowed to do just that due to having the unfiltered_html capability, so the action being taken is also a red-flag that this might be false.

To test out the vulnerability we first tried taking the actions show in the report logged in as an Author-level user. We entered the code on a new post as suggested in the report and clicked the “Toggle Preview” button and the JavaScript ran, which really isn’t a vulnerability (as we will come back to in a bit). Since this is supposed to be a persistent XSS vulnerability this JavaScript code needs to persist when saving the post, but it didn’t. It didn’t even get displayed when previewing the post normally.

We then tried everything again but with an Administrator-level user. Unlike the previous instance the JavaScript remained when saving the post. That would indicate that the plugin was not actually permitting persistent XSS, as Administrator-level users, unlike Author-level users, should be able to do that and the reporter likely did their testing using a user with the unfiltered_html capability.

As confirmation of that we tried things again with an Editor-level user that had the unfiltered_html capability removed and the JavaScript was not saved.

So there isn’t a persistent XSS vulnerability, but what about the JavaScript code running for the Author-level user when clicking the “Toggle Preview” button. Seeing as the user would be taking the actions to cause that it would probably be classified as self XSS, which isn’t a vulnerability, but a social engineering attack because you would need to trick someone into doing that. Is that a concern? Not really, since the same exact thing could be done by getting them to enter JavaScript code into their web browser’s console.

WPScan Spreads a False Report

While we actually test out vulnerabilities before adding them to our data, so we avoid including false reports like this, other data sources clearly do not. Take the WPScan Vulnerability Database, which is the true source of WordPress plugin vulnerability data for almost any service or plugin other than ours that provides that type of data,  it has this false vulnerability in their data set:

That is despite those major red flags that the vulnerability likely didn’t exist.

Why Was The Plugin Removed From the Plugin Directory?

If you visiting the page for the plugin in the Plugin Directory now you will get this as the plugin has been removed:

As of a couple of weeks ago it was there. Was it removed due to the Plugin Directory incorrectly believing there was vulnerability in it? Maybe, but it could also be something else. Unfortunately the people behind the Plugin Directory continue to keep people in the dark about removed plugins.

Leave a Reply

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