In reviewing reports of vulnerabilities in WordPress plugins to provide our customers with the best data on vulnerabilities in plugins they use 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.

Open Redirect in Google Doc Embedder

A common source of claimed vulnerabilities in these posts for the past few months has been someone with the handle “KingSkrupellos” that the website Packet Storm keeps posting inaccurate reports from. With their claim of an open redirect vulnerability in Google Doc Embedder, the report doesn’t make a whole lot of sense. For example, these are the versions they list as being vulnerable:

1.9.7 – 2.1 – 2.2.3 – 2.4.2 – 2.4.3 – 2.4.6 – 2.5.8 and lower versions is vulnerable

It seems odd to list as the last item there as “2.5.8 and lower versions is vulnerable” after listing specific versions.

The solution listed is:

Update/Upgrade to 2.6.4 Version

As you can probably guess, version 2.6.4 isn’t the version after to 2.5.8.

The file that is supposed to be vulnerable though was removed in version 2.5, making the last vulnerable version and the version you are supposed to upgrade to to not make sense. Version 2.5 was released in December of 2012, so why would be bringing up something that old now?

The other problem with this is that there isn’t an open redirect. Instead, when sending a request to the specified URL you get redirected to docs.google.com/viewer with a URL parameter of “url” attached. That isn’t an open redirect, since an open redirect allows redirect openly. That page will serve up the HTML content of the page specified by the “url”, which isn’t an open redirect either.

Local File Inclusion (LFI) in Anti-Malware Security and Brute-Force Firewall

A false claim of local file inclusion (LFI) vulnerability in Anti-Malware Security and Brute-Force Firewall is based on the reporter not having a good understanding of security and the developer failing to properly secure their code. When we tried the proof of concept provided we got the following message:

//Ajax Scan Error: Invalid or expired Nonce Token!32fd564ad6974510e6bcd22815853f3d !found

Looking at the code that would run when accessing the AJAX function that proof of concept causes to run we found this is the first code to run:

1704
1705
1706
1707

function GOTMLS_ajax_scan() {
	if (GOTMLS_get_nonce()) {
		@error_reporting(0);
		if (isset($_GET["GOTMLS_scan"])) {

There is a check for a valid nonce, but not a capabilities check to restrict what logged in users can access that. With WordPress’ nonces a user can’t use valid nonces for other users, but this plugin generates its own nonces, for which that isn’t true, and that seems to have confused the reporter, who it would seem didn’t look at the underlying code. So what the reporter looks to have been seeing was that once they had valid nonce that they got access to as an Administrator they could take the proof of concept action as any logged in user in their test environment, but they didn’t understand the significance of the nonce and they don’t make any claim that lower level users can gain access to a valid one.

We have emailed the developer of the plugin about the report and the lack of a capabilities check, if they get back to us we might mention the nonce generation might be better handled.