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 have been releasing 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. We have been thinking that providing information on why those are not included in our service’s data could be useful, so we are trying out putting a weekly post when that occurs detailing those issues.

Cross-Site Scripting (XSS) Vulnerability in amtyThumb and amtyThumb posts

The claim of a cross-site scripting (XSS) vulnerability in amtyThumb posts is a bit confusing as it is stated that

amtyThumb posts Plugin is prone to a stored cross-site scripting vulnerability because it fails to sufficiently sanitize user-supplied data.

and

The XSS reflected because the values are not filter correctly:

So they are claiming it is a stored (or as we refer to that type of vulnerability, persistent) XSS, a reflected, or maybe both.

The proof of concept given is:

/wordpress/wp-content/plugins/amty-thumb-recent-post/amtyThumbPostsAdminPg.php?”><script>alert(“XSS”)</script>=1

Looking at the underlying code in the file /amty-thumb-recent-post/amtyThumbPostsAdminPg.php it looks like what they are claiming is the vulnerability are in two instances of the following code:

echo str_replace( '%7E', '~', $_SERVER['REQUEST_URI']);

That could would output the variable $_SERVER[‘REQUEST_URI’] without escaping it, which theoretically could lead to reflected cross-site scripting (XSS). But, as we wrote in another of these series of post, that wouldn’t normally be an issue:

The claim that $_SERVER[‘REQUEST_URI’] is unescaped is partially true. While there isn’t any escaping of that done by PHP or WordPress, the value would normally be encoded due to URLs being encoded when sent from web browsers. That would act as escaping. That would normally mean that reflected cross-site scripting (XSS) could not occur due to this issue.

So there doesn’t appear to be the vulnerability as claimed, though there is a reflected XSS elsewhere in the code that we are in the process of trying to notifying the developer of.

After we wrote up the above details, we ran across a related claim of the vulnerability in the plugin plugin amtyThumb, which confirmed our analysis of what was claimed to be an issue in the other plugin. That issue has been given a CVE, despite really not existing either.