05 Jan

You Can Now See the Details of Possible Issues Identified by Our Plugin Security Checker

Since we introduced our Plugin Security Checker, which does limited automated security checks of WordPress plugins, in late October we have had a lot of interest in that and it has brought in additional business for both our main service and our separate security reviews. That is good for us, but also for everyone using WordPress as it allows us to do more to improve the security of WordPress plugins (which it looks like we already doing much more than anyone else).

One of the things there has been a lot of interest by users of the tool involves an area of plugin security that we hadn’t really considered in the past, custom plugins. Unlike plugins in the Plugin Directory where they can be checked for a particular issues en masse by anyone (with the ability to handle the results being limited by the amount of time it would take to contact the developers and possibly work with them to fix the issues) or even commercial plugins that can be checked to some extent by outside parties, custom plugins can’t take advantage of that. With our tool, custom plugins can get closer to that kind of checking, while also helping to improve the security of publicly available plugins as the capability to check plugins in the Plugin Directory is freely available, while checking plugins not in it requires using our service.

While the added business gives us additional incentive to further improve the tool, we would have been making the improvements that have been made since its introduction even if that wasn’t the case. Below is an update on what we have been doing recently in that regard.

New and Improved Checks

As we are adding newly disclosed vulnerabilities in plugins to the data set of our main service we have been looking to see if it makes sense to add a check for those issues or to tweak existing checks to spot those issues as well. We also have been looking at how we can incorporate checks for more serious issues found in plugins in the past since those would be among those of the most concern if found in another plugin. As an example of that, after our recent posting about how thousands of websites are still using a plugin with an unfixed option update vulnerability more than a year after it started being targeted, we added a new check for that issue.

At the same time we have been working to reduce the number of instances where the tool produces false positives (which based on our testing are already pretty low) and also to reduce some instances where the tool is correctly identifying something that could lead to a security issue but where we can detect in an automated fashion that the particular usage is harmless.

Developer Mode

Back when we announced the tool we mentioned that we were looking to add to the tool the ability for customers of our service to see the details of what lead to the tool identifying a possible issue. Subsequently, we have had some customer interest in that. As part of work for something else that we will be announcing soon, we have added that and made those accessible as part of what we are calling the Developer Mode for the time being. As the name implies that is focused on things that would useful to developers of plugins, like say those custom plugins, but also would useful to security professionals.  That mode, which requires you to be a customer of the service to access, currently introduces two additional features to the tool.

The first being that you can see the details of possible issues identified by the tool. We are still working on how those are displayed (we are already added syntax highlighting), but that currently looks like this for a possible reflected cross-site scripting (XSS) issue:

Any feedback on further changes to the display of that information is welcome.

The second feature adds additional checks that while they can be useful, also are more likely to flag harmless code, so flagging them for the general public has more downside. The first of those checks is something that was previously included in the standard checks, but based on the results we were seeing, we were considering removing from the tool before coming up with the idea of the Developer Mode. That is a check for usage of variables that can lead host header injection, which has been an issue with the core WordPress software. While it is easy to identify those, a lot of the usage is probably harmless even if they are being used when there is a better option. The second check is for usage of the function create_function(), which is something we discussed before. The final one is a check for instances where the result of a SQL query is passed to the function unserialize(), which can lead to PHP object injection in certain instances and has been claimed to be something hackers are exploiting (though some of the evidence of that seems questionable), so usage should be scrutinized to make sure there is no chance of that and that security has been properly implemented in the code.

More Coming

In continuing to improve the tool we are looking out how we can leverage other things we can do to improve the tool and how the tool can be used to improve other things we do (the breadth of what we do sets us apart from other companies in the field). We have now included checking over any possible issue identified by the tool into our security reviews and we are looking at additions to the tool based on things that can be automated and that have been on the drawing board for future enhancements to those security reviews.

We have a number of new features currently being worked on, including providing information that could assist in more quickly identifying some instances of plugins containing intentionally malicious code.

If you have any ideas for further enhancements you would be interested in please leave a comment below or contact us.

20 Nov

Our Plugin Security Checker Can Now Check WordPress Plugins Not in the Plugin Directory

We are currently waiting on several plugins to have security issues identified in part based on the results of our recently introduced tool for doing limited automated security checks of WordPress plugins to be fixed to be able to discuss real world examples of how the tool can be play a useful role in checking on the security of plugins.

One of the plugins we are waiting on shows the kinds of problems that come when trying to get vulnerabilities fixed in WordPress plugins, as the developer responded that the issues we notified them of had been fixed, but when we checked on the new version we found only two issues that we had identified as much less serious had been fixed. We had mainly mentioned those two because they were the issues that we picked up by the tool and we would be mentioning them in our post. For the issue we mentioned first in our message to the developer and identified as the more serious issue, no change was made.

In the meantime, though, we have made several updates to the tool that we though worth mentioning.

Expanded Reflected Cross-Site Scripting (XSS) Checks

For the plugin we mentioned earlier, one of the issues that tool picked up turned out to be unlikely to be exploitable, but provided an indication that the security of the plugin might be in poor shape in general, since it involved direct outputting of user input without it being escaped. When we went to do some more checking on the plugin we found a much more serious issue with the plugin. That seems to be a good indication that checking for fairly obvious security failures could be useful beyond just identifying those vulnerabilities, as it could identify plugins that are in greater need of a more thorough review than an automated tool can provide (like the security reviews we offer as part of our service and that can now be purchased separately as well).

When we went to take a look at what was done in the version that was supposed to fix the vulnerabilities we noticed a slightly more complicated path to reflected XSS also existed in the same file as the less complicated one our tool could already pick up. We have now added a check based on that.

While working on the new check mentioned in the next section of this post we ran across another plugin that had been picked as having the a reflected XSS based on the less complicated check. While looking into the details of that we noticed additional instances of that vulnerability in that plugin that were not yet picked up by that check and modified the check to catch those as well. There are likely a lot of other improvements we can make going forward as we start looking at if newly disclosed vulnerabilities in plugins are able to be picked up by the checks for those types of issues already in the tool.

Our First Third-Party Library Checks

One of the areas we are looking at adding checks for in the tool is insecure versions of third-party libraries. The first addition for that type of issue shows were the breadth of what we can do can help across all of them, as the libraries we added checks for are ones we only found that there was a security issue related to them when we looked into the details of a vulnerability that had been fixed in a plugin, but hadn’t had a public disclosure. That type of investigating is something that we look to be largely alone in doing when it comes to WordPress plugins as most providers of data on them either simply use other’s data (leading to lot of issues) or do little to no investigating into issues. In looking into that we noticed something else that lead to final new addition.

You Can Now Check Plugins Not in the Plugin Directory

In looking into the issue with those libraries we noticed that it looks like some of the plugins that have been using one of those libraries are either paid plugins or custom plugins. Up until now it would not be possible to check those plugins through our tool, since it only allowed checking plugins that are in the Plugin Directory. We have now added the capability for paying customers of our service to upload a ZIP file of a plugin to review, so they can have those plugins checked as well.

Unlike the checks of plugin in the Plugin Directory, we don’t record the identified issues for uploaded plugins since the checking of plugins in the Plugin Directory involves publicly disclosed code and that would not always be the case with uploaded plugins.

Going forward we might integrate the ability for the companion plugin for the service to handle of transmitting of plugins to our tool to make this type of checking easier. For now, there are a couple of plugins available in the Plugin Directory for downloading plugins as ZIP files.

24 Oct

Our New Tool for Doing Limited Automated Security Checks of WordPress Plugins

Last week in discussing a couple of examples of things that are not actually ways you can determine if you should use WordPress plugin from a security perspective, we mentioned that the only good way to determine if a plugin is secure is to have a security review done. While that isn’t something that seems like it could really be automated at this time (or does it seem that it would be any time soon), based on some of the work we do as part of our service we know it is possible to identify the possibility of some security issues in plugins in an automated fashion, which can help to identify if a plugins is in greater need of a proper security review.

Recently we have been working on a tool that provides the public with the results of checks for some possible issues and that can now be found here.

The tool currently contains two parts. The first just checks if the current version of the plugin is listed as containing a vulnerability in our data set. The details of the vulnerability are not provided, since that is major piece of what is provided through our service.

Possible Security Issues

The second part involves doing a number of checks for possible security issues. What is very important to note is that the tool only checks if there is the possibility of the issue and some of the things it will detect in plugins are not always security issues. That is a concern in providing a tool like this because while we see value in it, we also often see people making inaccurate claims about the security of plugins based on misreading information being provided, including instances where we have clearly written a post about a vulnerability having been fixed in a plugin and then someone immediately contacts the developer to find out if they are aware of a claim that the plugin is currently vulnerable.

Correctly used, this tool indicates if there should be further checking to see if there is a vulnerability and only after that should the developer be contacted.

To better explain both the limits of the checks, but also why is makes sense to check for things that are not always an indication of a security issue, let’s take a look at a couple of plugins we recently were checking over.

Unused File

Two weeks ago code in the plugin WCP OpenWeather was flagged during our proactive monitoring of changes made to plugins to try to catch serious vulnerabilities. The line of code that caused that was the following:

$cookie = unserialize(stripslashes($_COOKIE[$this->name]));

In that line you have user input, in the form of a cookie, that is passed through the unserialize() function, which could allow PHP object injection to occur.

That occurs in the function _getCookie(), which is a part of the class Agp_CookieAbstract and is in the file /agp-core/classes/persistence/session/Agp_CookieAbstract.class.php:

private function _getCookie ($key = NULL) {
	if (!empty($_COOKIE[$this->name])) {
		$cookie = unserialize(stripslashes($_COOKIE[$this->name]));

When we went to look to see how that function could be accessed we found that it was utilized in a number of the other functions in that class, but the class appears to not be used in the most recent version of the plugin or older versions, going back to the original version. Since the only thing in the file is that class, it doesn’t appear the file has ever been used in the plugin. We also found that the same file is included in the developer’s two other plugins and also not used. It looks like the developer includes a number of files even if they are not being used in particular plugin, which seems like it isn’t the best idea.  We contacted the developer about this more than a week ago, but we haven’t heard back.

So in this case there isn’t a vulnerability, but at the same time you don’t want vulnerable code in a plugin even it isn’t normally accessible. One of the reason for that is if there was a local file inclusion (LFI) vulnerability somewhere on a website that could be used to load files that are otherwise not used, though in this case that wouldn’t allow exploitation.

Unintended Access

Last week we looked into the details of a recent security fix made to the plugin PluginOps Page Builder. We will be releasing those once the developer of the plugin has a chance to fix a connected vulnerability we noticed still existed in the plugin. Without getting in to all the details of the security fix, part of the change involved adding a check to some functions to check make sure that only users with the Editor and Administrator roles have access to the functions.

One of those is the function ulpb_admin_ajax(), which you can see that in version 1.4.2 the first thing done in the function is that check:

function ulpb_admin_ajax(){
	if( current_user_can('editor') || current_user_can('administrator') ) {

Above that in file /admin/admin.php are the following two lines:

add_action( 'wp_ajax_nopriv_ulpb_admin_data', array( $this,'ulpb_admin_ajax')  );
add_action( 'wp_ajax_ulpb_admin_data', array( $this,'ulpb_admin_ajax') );

The first line there makes the function available through WordPress’ AJAX functionally to those not logged in to WordPress. The second one makes the function available through WordPress’ AJAX functionally to those that are logged in to WordPress. Seeing as the function is actually only intended to be accessed to subset of logged in users, that first line shouldn’t be there and before that role check was added those not logged in had access to the function. That allowed them to access a fairly serious vulnerability, though not one that is likely to be exploited on the average website.

That brings us to one of the checks we do, which is to check if there are AJAX registrations like the one above, that allows access for both those logged in as well as those not logged in. That will identify instance where that is intended and is perfectly safe, but it will also identify situation like this where it isn’t intended and expands the scope of a security vulnerability that would have otherwise only been accessible by to those logged in. Based on how often we see the incorrect usage like has been in this plugin and how easy it is for someone that knows what they are doing to check on this type of situation we feel that it makes sense to be raising this as part of the checking.

Currently we don’t provide the details of what code is the cause of a possible issue being identified as the tool as we see this as a public friendly tool and those that should be doing the further checking shouldn’t have a problem finding the relevant code.


The tool is very much a work in progress at this time and may change significantly as we continue to work on it.

We are continuing to look at more things we can add checks for. One area where we likely to expand it is by adding more the checks that are utilized with our proactive monitoring of changes made to plugins to try to catch serious vulnerabilities.

One of the things we are considering adding is providing the customer of our service the ability to see the details of the underlying code causing us to identify a possible issue. We also are considering the possibility of adding the capability to get results on plugins in WordPress’ admin area through our service’s companion plugin.

If you have suggestions, say any additional check that we should include (you can see what we currently includes checks on the tool’s page), or other feedback please leave a comment below or contact us.

04 Nov

You Now Decide What Plugins We Will Be Doing Security Reviews Of

As part of the work we have been doing for the service we have been steadily increasing our ability to spot security vulnerabilities and lesser security issues in plugins. That is due to a variety of different activity that we do, from our reviewing reports of vulnerabilities discovered by others, when adding them to our data, to finding vulnerabilities that hackers would target in plugin that we see hackers are probing for usage of. In the past we have used some of the knowledge we have gained through that to check for specific issues vulnerabilities in wider sets of plugins and found a number of vulnerabilities. That knowledge could also be used to more thoroughly review a single plugin and check it for a number of security issues, which is something we have decided to start doing.

In doing that though the question is what plugins should we review and what we came up with was allowing our customers to decide that. This provides additional value to service, beyond letting you know what vulnerabilities exist and previously existed in the plugins you use (as well as helping you to best handle it if a vulnerability in the plugin you use hasn’t been fixed). To accomplish that we have set up a new page where customers can suggest plugins to be reviewed and they can vote in favor of plugins already suggested by others.

The process is pretty simple, log in to your account and then visit the voting page. From there you can submit any plugin currently in the Plugin Directory:


For plugins that others have already submitted you get a brief listing of their details and if you want that plugin reviewed, you can add your vote for that to happen:


(If you are wondering what we use to power that, it is the Idea Factory plugin, with a significant amount of fixes (due to support for being lacking at this time) and customizations.)

We are currently planning to do a review of a plugin with the highest vote count every two weeks (based on the time commitment and interest we may increase the number of reviews going forward).

What is Included in the Review?

We are referring to the reviews that we do as basic reviews, as it isn’t a line by line review of the plugin and we are not guaranteeing that the plugin is completely secure after the review. But that doesn’t mean that the review can’t find big issues. One of the items we are going to be looking for is security issues with file upload capabilities, which in some cases can lead to arbitrary file upload vulnerability. That type of vulnerability allows an attacker to upload any type of file to a website, which is frequently exploited by hackers to upload .php files that gives the hacker nearly complete access to the website.

Even in cases we don’t find major security issues, security improvements that we identify, if implemented by the developer could prevent a future security vulnerability. To give you one example of where this could have made a big difference, earlier this week a vulnerability was discovered being exploited in a plugin (the plugin is in the process of being fixed so we won’t mention its name here). In addition to a more obscure security issue that lead to this, it was situation where a recently added function that should have only accessible to Administrator level users was accessible to anyone logged in or logged out, and allowed a hacker to gain full access to the website. While that function was recently added, numerous other function had the same problem, with one of the others allowing any file on the website to be deleted. Once we notified the developer of that larger issue they quickly restricted access. As our basic review would have identified the lack of proper restrictions, it could have prevented the more serious vulnerability from being exploited by anyone other than an Administrator level user (who would normally already have the ability to do the equivalent of what the vulnerability permitted).

Here is the full list of items we are checking for at this time:

  • Insecure file upload handling (this is the cause of the most exploited type of vulnerability, arbitrary file upload)
  • Security issues with functions accessible through WordPress’ AJAX functionality (those are a common source of disclosed vulnerabilities these days)
  • Persistent cross-site scripting (XSS) vulnerabilities in publicly accessible portions of the plugin
  • Cross-site request forgery (CSRF) vulnerabilities in the admin portion of plugins
  • SQL injection vulnerabilities (the code that handles requests to the database)
  • Reflected cross-site scripting (XSS) vulnerabilities
  • Lack of protection against unintended direct access of PHP files

We also have some additional items that we will be taken a look to see if it would make sense to check during the reviews.

If you have question or comments about this new feature feel to get touch with us or leave a comment on this post.

19 Sep

We Now Let You Know How Likely It Is That a WordPress Plugin Vulnerability Will Be Exploited

Recently we have been looking at ways that we can improve the data we provide on WordPress plugin vulnerabilities through our service. Three weeks ago we started including data on false reports of vulnerabilities in the plugins you have installed. Today we have added a rating of the likelihood that a vulnerability will be exploited to the service’s data we present in the plugin and in the email alerts you receive if you the currently installed version of one of your plugins has a vulnerability. Once you have updated the service’s companion plugin to the newly released 2.0.22 you will start getting that.

Before we get into the details of that, we thought it would be useful to explain why we thought this would be a good addition the service. Something we often see is that really minor vulnerabilities, ones that have almost no chance of someone trying to exploit on a website, are instead presented by security companies and the press as being major concerns. The press often makes a big deal of minor vulnerabilities in very popular plugins, that never get exploited, while not covering vulnerabilities in lesser used plugins that leads to thousands of website being hacked. We also sometimes see people immediately removing a plugin with a minor vulnerability, when they could have safely waited for a fix to be put out.

One possible way to better present the actual threat of a vulnerability would be to use a severity score. Those seem to be popular, particularly the CVSS scorring system, but we found that the scores for WordPress for plugins are much to high with that, leading again to overemphasis on vulnerabilities that are not a large threat. That scoring system is also rather complicated, with multiple scores and multiple version of the scoring system.

So we have come with a simpler rating system for the likelihood of a vulnerability being exploited. We give each vulnerability a rating of low, medium, or high based on our estimation of the likelihood of the exploitation. Most vulnerabilities fall into either low or high, with medium being for vulnerabilities for vulnerabilities that would be exploited in more limited circumstances. Take for example this vulnerability that would allow anyone logged into WordPress to upload malicious files. For a lot of websites that only have one WordPress account or only have accounts for few trusted users it really isn’t much concern, but if you allow the public to register for account it could be a threat (hackers did try to target it).

How We Make Our Estimates

To come up with an accurate rating, which is important for them to be useful, we look to three items.

The first is the type of vulnerability. This is by the far the biggest factor as many types of vulnerabilities are either highly likely or unlikely to be exploited.

The second is the specifics of the vulnerability, which can sometimes make a big difference. For example a persistent cross-site scripting vulnerability that causes malicious JavaScript code on the frontend pages of the website is more likely to be exploited than one that places it on a single admin page.

Finally, since we are constantly monitoring what vulnerabilities hackers are targeting, we can see if a vulnerability is getting targeted out out line with what the two other criteria would suggest and change the rating to match that.

All of this depends on us having good understand of those things, so that is where we can provide unique value because we review vulnerabilities, we monitor hacking attempts, and clean up hacked WordPress website. In addition we are continue to look at ways to get a better understanding of what is going on, by doing things like seeing to what extent WordPress security plugins can protect against exploitation of vulnerabilities and seeing what influences the vulnerability that hackers choose to target.

Rating Data Still Being Added

We started including the estimate when adding new vulnerabilities a few weeks ago. In the last week we have adding ratings to a lot of the existing vulnerabilities, but it still we be some time before we include ratings for all of the vulnerabilities that have existed in the data set for some time.


If you have ideas for further improvements to the data we present in the plugin or any similar suggestions please get in touch with us.

29 Aug

False Reports of Vulnerabilities In Installed Plugins Are Now Listed As Well

When adding a new WordPress plugin vulnerability to the data set for our service we test out the vulnerability. That allows us to do several important things for our customers, which you won’t get with other data providers, who don’t do that.

First, we can warn you when the vulnerability hasn’t actually been fixed, despite a claim to the contrary in the advisory. Once the vulnerability has been disclosed the chances of it being exploited increases, so knowing that you are still vulnerable is important in that instance. If you are using a service that doesn’t do this, you would need to check out each vulnerability yourself to insure it has actually been fixed.

Second, we can determine which versions are vulnerable. The biggest use for that is in dealing with hacked websites, since you will actually know if the version that has been in use was vulnerable and could have been the source of the hack. Other data sources will just list that all version below a certain versions are vulnerable, despite it often being far fewer than that. For example, one widely exploited vulnerability earlier this year existed in only in one version of the plugin. Doing that also allows us to only send you a notification if you are actually using a version that is vulnerable.

Third, we are able to exclude false reports of vulnerabilities from out data. Warning you about a vulnerability that doesn’t exist obviously isn’t helpful.

While it doesn’t make sense to warn you about vulnerabilities that don’t exist as if they exist, knowing that false reports of vulnerabilities exist can be useful. One of the odd things we have noticed in monitoring hacking attempts on our websites is that hackers will sometimes try to exploit vulnerabilities that don’t exist. So if you can see that there is false report that matches hacking attempts on your website, then can stop worrying about that.

When we come across false reports of vulnerabilities in plugin we usually write up a post about the issue, that way we can let others know that it isn’t real and it also allows us to double check that we are correct in determining that the report is false. Up until now if you used our service you would have to search our website to see if there were any false reports for the vulnerabilities you use, which isn’t all that convenient. That changed today with the release of version 2.0.21 of companion plugin for the service, which now lists any false reports of vulnerabilities we have posted about in installed plugins in section below the existing sections for vulnerabilities that have and have existed in the plugins you have installed.


If you have ideas for further improvements to the data we present in the plugin or any similar suggestions please get in touch with us.

11 Mar

Get Alerted When WordPress Plugin Developers Are Not Taking Security Seriously

With our service you get alerted if any of the WordPress plugins you have installed have a vulnerability in the installed version. You can also see what vulnerabilities they have had in other versions, which is something you might use to determine if you should continue you using it. The problem with trying to do that is that isn’t always easy. If you are not dealing with this type of thing on a regular basis there is good chance you wouldn’t have the knowledge as to what security issues are of little concern and what ones are a major concern going forward. You also would have dig in to see if the developer has a pattern of not responding in a timely fashion when a vulnerability is discovered, which can have a significant impact on whether the vulnerability will get exploited. Since we already come in contact with that type of information, we thought it would be useful to start using the knowledge we are collecting to make it easier to find out if security practices of plugin developers are lacking by putting out advisories for developers that have serious issues.

The idea for this also came up because unfortunately we are seeing developers who are doing a really bad job at making sure their plugins are secure. The first advisories we released involves a company that has not been taking basic security measures, had a really serious vulnerability in one their plugins,  doesn’t respond in a timely manner when contacted about security issues, and takes weeks to fix them. The subject of the second one has repeatedly only fixed part of the security issues reported to them.

You can view all of our advisories here and follow the RSS feed of them here. Having to check our website to see if a plugin developer is the subject of a security advisory obviously isn’t very convenient, so that is why we have rolled out a couple of updates to our software to allow those notices to be seamlessly shown when you are looking at new plugins:

Advisories in WordPress

Today we released a new version of the Plugin Vulnerabilities plugin that adds a warning message with a link to these advisories to the details page of plugins in the Add New plugins section of WordPress:


For already install plugins you can click the “View details” link on the Installed Plugins page to see if there is an advisory as well.

This feature is built in to the plugin, so it works even if you haven’t signed up for our service (though you really should do that).

Advisories on WordPress.org

But what about if you are taking a look at plugins on the Plugin Directory on WordPress.org? If you are doing that in the Chrome web browser you are in luck. We also have released an update to our Plugin Vulnerabilities extension that adds the advisories to the website:


The extension also adds notices to the URL of plugins that have been removed from the Plugin Directory due to security issues:


If we see increased interest in the extension we plan to release versions for other web browser, so if you want it for ones of those, please let us know which one in the comments so that we can properly prioritize the order of which browsers to bring it to in the future.