When it comes to identifying security issues in WordPress plugins we try to be very careful. The vulnerabilities in our service’s data set is based on vulnerabilities that we confirmed existed, which is something of enough value that others lie about having data that is handled that way. For our automated tool for detecting possible security issues, the Plugin Security Checker, we are careful to note that the issues identified are only possible issues and we do a lot to avoid false positives with that. When we become aware of a false positive, we quickly work to fix that. Others in the WordPress security industry do not really seem to be all that concerned about the quality of the results of claimed security issues in WordPress plugins or elsewhere in WordPress websites. The problems though don’t just come directly from the security industry, web hosts also are a reoccurring issue with false claims of security problems in plugins, which is something that came up again in monitoring of the WordPress Support Forum for indications of security issues in WordPress plugins.

A topic was started there in the last day that indicated there might be a security issue with the readme.txt file from the plugin Zendesk Request Form:

Hi,
i just got an email from hosting provider stating this

We have put the following content into quarantine as we believe it contains viruses or other malicious code. If you feel this has been in error and
your file is false-positive (innocent), please submit a ticket to us at https://support.namecheap.com/index.php?/Tickets/Submit or contact
the Live Help at http://www.namecheap.com/support/livesupport.aspx and we will be happy to assist:

‘[RFI Exploit [P1419]]’: /home/…./wp-content/plugins/zendesk-request-form/readme.txt

RFI would usually be short for remote file inclusion, which seems to be an odd issue to be flagging a .txt file for, which normally wouldn’t have any executable code in it. The developer’s response indicates that this isn’t a new issue:

Hi Mian,

I can confirm that the plugin is clean and does not contain any malicious code. We have contacted Namecheap about this several times and they have repeatedly whitelisted the .txt file which is casuing a false-positive. However the same issue keeps repeating. I’d recommend finding a new host, since Namecheap’s exploit scanner is not configured correctly.

You can safely open a ticket with them and ask for the file to be whitelisted. This is the reply we received when we asked that a few weeks ago:

“We’re happy to let you know that the issue has been resolved. We have restored and whitelisted the file. We fixed it and everything is up and running for us.”

We are not sure where the idea that the exploit scanner is not configured correctly would come from, as it could be configured correctly and just produces bad results

The signature for the issue being identified, RFI Exploit [P1419], doesn’t really tell you much as to what it represent. In doing a search on that we only came up with two pages that were relevant and those involved other topics on the WordPress Support Forum. One of those is one we discussed before due to it being an instance of us running in to the terrible moderation of the Support Forum and involved files being uploaded being flagged with the same signature. The other involves a .php in a file from the plugin Pastacode being flagged, which would seem more relevant to the type of issue hinted by the signature. Looking at that file we didn’t see anything that looks like it would match an identification for a remote file inclusion vulnerability.

Based on past experience, something we did notice in that file, which is also true of the readme.txt from the plugin Zendesk Request Form, makes us wonder if it was the cause of this is that the file both include the domain names of several websites, including both including one that seems the most likely cause of an issue, pastebin.com. We say that in part since the companion plugin for our service has been falsely flagged as containing malware due to the website addresses for the details of vulnerabilities listed in the data. One of signatures was similar in format to the one in this instance, “[Hacker Signature Exploit [P0818]]”, and the other didn’t involve signature, but simply involved matching a domain name, “Regular expression match = [1337day\.com]”. Those false positives were apparently caused by ConfigServer eXploit Scanner (cxs). It doesn’t make sense to us that you would flag things as malicious for that sort of thing, but a lot of what is done by the security industry doesn’t make a lot of sense.