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.

Reflected Cross-Site Scripting (XSS) Vulnerability in Shibboleth

The claimed reflected cross-site scripting (XSS) vulnerability that had been in the plugin Shibboleth is good example of why the lack of testing done for claimed security issues can lead to missing important limitations surrounding them. We first came across the claimed vulnerability when the WPScan Vulnerability Database added the claimed vulnerability, which they didn’t verify before adding to their data set. They cited two references, one being a security improvement change made to the plugin in March of 2016 and the other a discussion on the Debian mailing list. That discussion makes mention of waiting for “real world testing”, but there is no mention of it being completed.

When we did just that type testing before adding this vulnerability to our data set we found that reflected cross-site scripting (XSS) wouldn’t occur. In looking at the underlying claims behind the claim of a vulnerability in this plugin, we found that both the WordPress team and the security company Sucuri (which is part of GoDaddy) had failed to note important limitation with the potential security issue at issue here. Sucuri’s posting about the underlying issue is missing even basic technical details, which if included, might have allowed someone point out that they were overstating the issue (they have a history of doing that sort of thing and worse).

WordPress’ posting on this is better as it provides an important detail which gets to the limitation:

Both add_query_arg() and remove_query_arg() have an optional argument to define the base query string to use. If this argument is undefined, it will use $_SERVER['REQUEST_URI'], which is unescaped. When printed out to a page, this could be used as an XSS attack vector.

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.

The change made to plugin makes sense since it makes sure the issue couldn’t be a problem and doing that change in general when using the add_query_arg() and remove_query_arg() make sense since when the result of them is used in a different way than this plugin did, it could cause an exploitable vulnerability.