Login

Tag Archives: Plugin Directory

14 Jun 2023

Security Review of Brand New WordPress Plugins Still Failing at Basic Level

When new WordPress plugins are submitted to the WordPress Plugin Directory, they are supposed to go through a review first, which includes checking the security of the plugin:

You will get an automated email telling you about the submission immediately. At that point, someone will manually download and review your code. If we find no issues with the security, documentation, or presentation, your plugin will be approved. If we determine there are issues, you will receive a second email with details explaining what needs to be fixed. [Read more]

9 Sep 2019

NinTechnet and WordPress Plugin Directory Team Fail to Make Sure Vulnerability in Search Exclude Was Actually Fixed

Last week we disclosed a settings change vulnerability in the plugin Search Exclude after it had been closed on the WordPress Plugin Directory and noted that wasn’t the only probable issue:

There also appear to be other security issues with the plugin. [Read more]

27 Jun 2017

Pagely Downplays Serious Problems With The Handling of Security Vulnerabilities in WordPress Plugins

Security isn’t in great shape these days and that certainly applies to WordPress plugins as some recent issues we have run across have reminded us. As we see it, one of the causes of this is that real problems with security rarely get discussed. There are probably many factors at play to cause that, but one that we see is that people will criticize you if you say anything they interpret to be negative when it comes to security (the irony of that seems lost on them). That seems to lead to a lack of honesty about what is going on and instead a focus on happy talk that doesn’t resolve the problems, even though many could be fixed without much effort if there was an interest in doing that.

An example of not discussing the real problems comes up with a post we ran across from the blog of WordPress web hosting company Pagely. The post discusses the increasing issue with PHP object injection vulnerabilities in plugins, but hidden below the surface of the post is a couple of problems that writer clearly is aware of, but doesn’t disclose. The relevant section of the post is the following: [Read more]

9 Jun 2017

WordPress Plugin Directory’s Security Review Leads to Putting Public At More Risk

Yesterday we announced we have temporarily ended our notifications to the WordPress Plugin Directory when there are plugins with disclosed vulnerabilities in the current version of the plugin that is in the directory, until they put forward concrete plans to resolve two issues. One of those is finally warning people when they are using plugins that have been removed from the Plugin Directory for security issues. While years ago they claimed they were working on doing this, more recently they have claimed that doing so would put people at more risk. It is truly bizarre position to take just considering that many of these vulnerabilities have been publicly disclosed, so hackers would already have easy access to as much or more information than anyone has proposed including when warning webmasters of the issue. Then you have the fact that plenty of these vulnerabilities are not only known to hackers, but being actively exploited before the plugins were removed from the Plugin Directory (we know this because we have reported many of those to the Plugin Directory).

While that is really a black and white issue, when it comes to security many things are not like that. And in many cases actions do have serious unintended consequences that are not obvious. For example, we wouldn’t have though that the Plugin Directory doing a security review of a plugin after it has been removed for a security vulnerability could lead to putting the public at more risk, but that turned out to be the case as we recently found. [Read more]

8 Jun 2017

Taking a Stand Against the Continued Poor Handling of Security With WordPress

While WordPress handles security fairly well, there are plenty of problems that we have seen in the work have done that ultimately lead to this service and then in doing the work for to this service, including ones that are leading to websites being hacked that shouldn’t be and that make our work to actually get the security of plugins improved unnecessarily harder. Some of these problems are getting worse, so we have decided to stop doing work that people on the WordPress side should have been doing themselves all along until they present concretes plans to fix two of the many issues. In the short term this will leave those not using our service with worse security, but if WordPress chooses to start moving in the right direction then security can be improved from where it is now. We would then love to work with them to improve other issues, as there are lots of areas were small changes would likely lead to significant improvement.

Poor Handling of Security

One of the most glaring recent examples of the poor handling of security is a refusal so far to fix a vulnerability in WordPress that was disclosed to the security team in July 2016 and publicly disclosed a month ago. The explanation for not having fixed it in all that time is underwhelming: [Read more]

17 Feb 2017

WordPress Shutdowns Discussion of Their Refusal to Warn About Unfixed Vulnerable Plugins

Since 2012 we have been trying to get WordPress to start warning webmasters when their websites are using plugins that have been removed from the Plugin Directory due to security issues (and notify people in general that they are using plugins that have been removed from it). In the past WordPress’ position was that they were working on implementing this, but as of the last year the position has changed that they can’t do this because it would cause people to be “MORE at risk“. Not only does this not make sense, as we will come back to in a moment, but they don’t want to even honestly discuss the issue. For example, last July they even deleted a reply of ours on the Support forum pointing out that the handling of vulnerable plugins was not in as good shape as they were portraying it.

With that background it probably shouldn’t be surprising to see what happened to a recent thread on the wordpress.org Support Forum, which we previously mentioned, that was discussing the lack of notification when plugins are removed from the Plugin Directory. The head of the Plugin Directory decided to close that thread due to it being “non-productive”. It seemed plenty productive to us, as people were discussing better ways to handle things. The closing seems to us to be part of a continued lack of professionalism on part of people on the WordPress side, which really isn’t acceptable considering the widespread and high profile use of the software. Seeing as the person doing the closing is intimately involved in the issue being discussed, it doesn’t seem like they should be making the call to close the thread. [Read more]

15 Dec 2016

When a Security Company Does the Right Thing and The WordPress Plugin Directory Drops the Ball

Due to how bad the security industry is we rarely have the ability to point to a situation where the a security company has done the right thing, but today we have one to discuss.

Yesterday, we discussed how security companies rarely do one of the three basic components of a proper hack cleanup, which is to try to determine how the website was hacked. As we mentioned in that post, in instances where that isn’t done we are frequently brought in to re-clean the websites after they get hacked again. The problem of not determining how the websites are hacked doesn’t always just impact that website, if the vulnerability exploited exists in the current version of software on the website then spotting an early exploitation has the possibility of limiting the amount of additional websites that get hacked due to it. That possibility occurred with an arbitrary file upload vulnerability that exists in the WordPress plugin Delete All Comments. On November 20 the security company NinTechNet was looking into a hacked website and found the website was hacked due to that vulnerability. It wasn’t all that hard to spot with the combination of the logging and the code in the plugin, but since so many security companies don’t even try to determine how the websites they are cleaning up have  been hacked, something like that can easily get missed. [Read more]

6 Sep 2016

Yet Another Very Vulnerable Plugin Returned to The WordPress Plugin Directory Without Actually Being Fixed

When it comes making sure that vulnerabilities in WordPress plugins get fixed we play important role in making that happen, but we are having to play an outsized role because others are not doing their part, which has once again lead to websites remaining vulnerable to being hacked for much longer than they should have been.

One of things that we do to provide the best data on vulnerabilities in WordPress plugins to our customers is that we monitor our websites and some outside data sources for evidence that hackers are targeting plugins. In many case the evidence doesn’t itself give any indication of what the vulnerability the hacker is targeting, just that the hacker is looking for usage of the plugin by requesting a .css or .js files in the plugin’s directory. From there we try to determine if the hackers is targeting a previously known vulnerability or there is a vulnerability that exists in the current version that hacker could be targeting. Through that work we have found numerous vulnerabilities included many that it looks like hackers have known and been exploiting for months and sometimes longer. What we found fairly troubling about this is that we look to be the only security company doing, even though at least one other would certainly like you to think they are. [Read more]

17 Aug 2016

WordPress Doesn’t Fix Severe Vulnerability in Plugin And Doesn’t Want To Have An Honest Discussion About the Issue

Recently we have been having an issue where someone (or someones) that has the ability to edit and delete post on WordPress’ support forum had been doing those things to some of our posts on their support forum. Last week discussed on such instance where that look liked an attempt to cover up the fact that WordPress has an ongoing problem where plugins they know contain a vulnerability that have been removed from the Plugin Directory due to that, then return to it without the vulnerability being fixed. Over at our main blog we discussed that it appears that whomever is doing it doesn’t want the public to know what is going, as in another instance they also deleted a reply to a post of ours that just thankedus for the information we provided, which if it remained, would have made it obvious that a post from us had existed and had been deleted. While preparing to write this post about the issue of WordPress’ handling a vulnerability in a plugin that appears to have been abandoned, we noticed that another such instance of a deletion that looks like an attempt to cover up yet another piece of WordPress’ current poor handling of vulnerabilities in plugins.

On July 17 we saw requests for a .css file from the plugin Form Lightbox across our websites. That is usually an indication that a hacker is probing for usage of the plugin before trying to exploit a vulnerability in it. Seeing as the requests hit all of our websites, that pointed to there probably being a large campaign to exploit something in the plugin. After noticing the request we started trying to figure out if there was a vulnerability so that we could add it to our data and see what we could do about getting it fixed. We quickly found an option update vulnerability in the plugin, which would allow anyone to change WordPress’ options (settings). One possible way that could be exploited is to turn on user registration and set it so that new users had the Administrator role, giving the attacker the ability to do almost anything on the website. Later in the day the plugin was removed from the Plugin Directory, so at least one other person had noticed the issue and notified the Plugin Directory before we had done so. [Read more]