When it comes to improving the security of WordPress plugins one big problem we see is that it is hard for the community at large to have a good understanding of what the real issues are and therefore push for the needed changes, because security companies put out so much misleading information. We often see security companies discussing vulnerabilities that is of a type that is very unlikely to be exploited, and instead of mentioning the limited threat, they instead only mention the worst case scenario. That isn’t helpful and it does have a negative impact, as we see people thinking that they have been exploited by these types of vulnerabilities when they clearly were not. Another issue we sometimes see is that security companies will exclude important information on the limitations of vulnerabilities, for example we repeatedly spotted Wordfence excluding any mention that vulnerabilities they were discovering were only exploitable when logged in to WordPress, which limits the chance of exploitation by a large degree and is important to mention since it allows many webmasters to immediately know that the vulnerability could not have impacted their websites before it was fixed.
Because press coverage of security is often little more than repeating claims of security companies, who are in turn putting out misleading information, you end with sensationalistic coverage that provides little value.
What we have been seeing more of lately, maybe because of our monitoring of the WordPress support forum to help keep track of what plugin vulnerabilities are out there, is misleading information coming from people on the WordPress side of things as well. One recent example came from someone labeled in the support forum as “Support Representative”, who is also any employee of Automattic, the company closely associated with WordPress. In regards to a question about the security of plugins they responded:
All plugins at https://wordpress.org/plugins/ go through very intense security screening by real human volunteers, so you generally have nothing to worry about.
With that said, no one is psychic. Some enterprising hacker may find a new never-before-seen exploit that one of these plugins is vulnerable to. That’s true for every web software, even WordPress itself. When that happens, the developers are notified, and they generally react quickly to release an update with a fix.
Some more reading for peace of mind:
We were absolutely puzzled by that, as it is so far from the reality of the situation, starting with the fact that plugins do not got through an intense security screening. There is a manual review done before a plugin is allowed into the Plugin Directory, but we can’t find any claim that it includes an intense security screening. One of the documents they linked to in that response specially states that “Inclusion of plugins and themes in the repository is not a guarantee that they are free from security vulnerabilities.”. If this review is intended to be an intensive security screening it is failing at that, as we recently found two plugins that had serious and fairly obvious vulnerability that had existed in them since they were added to the directory five months ago.
When an update of a plugin is submitted it is made available immediately without any sort of review or screening, and seeing as vulnerabilities can be introduced in an update, even if plugins were fully secure when first introduced, they could start getting insecure with the first update.
From the work we do for this service, not only are there vulnerabilities that exist in plugins in the Plugin Directory, but we recently have been finding vulnerabilities that hackers look to have been exploiting for months (or in some case over a year) and the plugins have not been fixed and they have remained in the Plugin Directory (if not for our work, who knows how much longer the plugins might have stayed in that state).
Another glaring problem with what was said is that very few vulnerabilities being discovered are “never-before-seen exploit[s]”. From what see from reviewing publicly disclosed vulnerabilities before adding them to our data set and discovering plenty of vulnerabilities ourselves, is that the vulnerabilities often involve well known issues, that is even the case with the vulnerabilities that are being exploited.
The last problem, which is something that is important to note because it points to an important improvement that could be made, is the claim that developers “generally react quickly to release an update with a fix”. From what we have seen dealing with lots of vulnerabilities, the reality is that while some developers will respond very quickly, others are not responding in what we consider a reasonable time frame. That includes vulnerabilities that are being exploited already, which we have seen take weeks for developers to respond with a fix and in other cases where the developer isn’t around any more, the vulnerabilities never get fixed. The Plugin Directory has the ability to step in to issue a fix for a vulnerability and does sometimes do that, but what the criteria is for that is opaque and it doesn’t happen nearly enough (if they need help in improving the handling of that we would be happy to help).