Login

Plugin Vulnerabilities

A service to protect your site against vulnerabilities in WordPress plugins.

Login
15 Feb

Not Really a WordPress Plugin Vulnerability, Week of February 15

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.

Local File Inclusion Vulnerability in WP Staging

The report of a claimed local file inclusion vulnerability in the plugin WP Staging is the kind of strange report we have never understood what might be the explanation of, as you have someone subtly modifying real code from a plugin to present a very different situation from reality.

The report lists the vulnerable file as /index.php, the actual file is /apps/Backend/views/tools/index.php. The report shows that two lines of code are the cause of this:

30:require_once $this->path . “views/tools/tabs/” . $activeTab . “.php”;
5: $activeTab = $_GET[‘tab’] : “import_export”;

The first of those is largely accurate, as this is how the line actually looks:

30

<?php require_once $this->path . "views/tools/tabs/" . $activeTab . ".php"?>

The second line though is very different:

5

$activeTab  = (isset($_GET["tab"]) &amp;&amp; array_key_exists($_GET["tab"], $tabs)) ? $_GET["tab"] : "import_export";

What they removed is very important since it limits the values of the variable $activeTab, which is used in the previous line, and that prevents local file inclusion. We thought it might be that while the report listed the version impacted as 2.4.8 and they were actually looking at an earlier version of the code when the code was different, but the older versions don’t look like that either and are not vulnerable either.

Cross-Site Request Forgery/File Upload in Jssor Slider

Now in a reoccurring part of these posts we are pointed out that someone going by the handle is “KingSkrupellos” is getting false reports listed with Packet Storm. This time it turned out that they copied a real report of ours from June of 2016 of an arbitrary file upload vulnerability in Jssor Slider that we noted had already been fixed and claimed that it was a cross-site request forgery/file upload vulnerability in the most recent version.

15 Feb

Closures of Very Popular WordPress Plugins, Week of February 15

While we already are far ahead of other companies in keeping up with vulnerabilities in WordPress plugins (amazingly that isn’t an exaggeration), in looking in to how we could get even better we noticed that in a recent instance were a vulnerability was exploited in a plugin, we probably could have warned our customers about the vulnerability even sooner if we had looked at the plugin when it was first closed on the Plugin Directory instead of when the vulnerability was fixed (though as far as we are aware the exploitation started after we had warned our customers of the fix). So we are now monitoring to see if any of the 1,000 most popular plugins are closed on the Plugin Directory and then seeing if it looks like that was due to a vulnerability.

This week one of those plugins was closed and has not been reopened.

PHP Settings

PHP Settings, which has 40,000+ installs, was closed today. No reason has been given for the closure. In looking over the plugin we didn’t find any obvious security issues.

14 Feb

WPCampus and Paul Gilzow Spreading False Information About Claimed Vulnerabilities in WordPress Plugins

One of the striking and telling aspects of the security community that seems to go a long way to explaining why security, whether of WordPress websites or more broadly, is in such bad shape is the lack of concern for providing accurate information. We often find that security companies are telling outright lies (or they are so unfamiliar with the basics of security that they have no idea that they are not telling the truth and shouldn’t be in the security industry). When it comes to security researchers, security professionals, or security journalists we have recently found over and over an apparent complete lack of concern that they might be providing information that isn’t accurate and lack of understanding why that others might take issue with that. That leads to a situation like if you tried to build the foundation of a home on quicksand, as can be seen by news coverage of security breach after security breach.

Along those lines we had recently tried to leave comments to point out that information on WordPress plugin vulnerabilities put out in posts on the website WPCampus and written by Paul Gilzow, who is described as a “Web application security and accessibility evangelist. Software instructor. Conference lecturer and presenter.”, is not accurate. While WPCampus’ code of conduct shown in the footer of their website states “All participants should be able to engage in productive dialogue. “, they don’t seem to be interested in a dialogue at all, as our comments haven’t been shown and the issues raised have not been resolved.

No Existent Files

To give an example let’s take a look at a few of the entries from their post from last week. On the same day as their post, we had written this about a claimed vulnerability in the plugin Ultimate Member:

They were at it again with a claimed cross site request forgery / shell upload vulnerability in Ultimate Member. In this case they claim that there is vulnerability in the latest version of the plugin involving files that don’t exist in it.

The information provided with WPCampus’ post includes that claimed vulnerability:

The first thing to note there is that for some reason the single cross-site request forgery (CSRF) vulnerability has been broken in two, which is a reoccurring issue with their reporting. A CSRF vulnerability involves causing someone to take an action they didn’t intend to, so the second part of the vulnerability refers to what action can be taken and therefore splitting them up doesn’t really make sense.

We don’t know how someone could think the vulnerability existed in that version of the plugin or is unfixed, seeing as we noted last week, the supposedly vulnerable files don’t exist in it. The “suggested action” given for that is, well, confusing:

I was unable to verify this vulnerability before posting. Researcher has history of misidentifying vulnerabilities. Remove, or see source for temporary fix

They say they are unable to verify it, but they suggest removing it. Considering that plugin has 100,000+ active installations according to wordpress.org and the plugin is likely rather central to many websites using it, that sort of recommendation seems quite problematic. We left a comment noting the report was false, but people visiting the post haven’t had the chance to be warned.

Not Really a Vulnerabilities Either

In the same post that we noted the problem with that report on Ultimate Member we also noted false reports of vulnerabilities disclosed last week in the plugins WP User Manager and Parallax Scroll, those are also incorrectly listed in the WPCampus’ information:

Unfixed

Even with an actual vulnerability they are providing information that is inaccurate and without a good reason for the mistake that we can think of. Last week we disclosed that the plugin Accessibility Suite by Online ADA contained a SQL injection vulnerability. According to their information it has been fixed in version 2.0.10:

That isn’t the case and we don’t what would lead someone to believe that. The changelog entry for that version doesn’t suggest that:

Bug fix: Fixed issue with wordpress installations in subdirectories not comparing properly in the sitemap and CSV download path

There was a change made to code related to the vulnerable functionality in that version, but nothing that should have impacted the vulnerability. It is easy enough to double check that, as we provided a proof of concept for the vulnerability and that continued to work with that version.

Wrong Versions

One final quick example of the problems with their information, though of less concern, unless you need accurate information on vulnerabilities in WordPress plugins. They include an entry for a vulnerability in Quiz And Survey Master, that was re-disclosed last week (we had previously disclosed it in September). While the information provided with their post claims it impacts “all” versions:

It actually only impacts version 4.5.5 and above.

A Change Should Happen

Just based on that anyone relying on those posts is getting a lot inaccurate information. Clearly something should be done about that and hiding comments noting there are problems isn’t a benefit to those reading those posts.

Part of the problem with what is going on here is that people believe that they can get the kind of data that we do a lot of work to provide, but for free, which as this post gives you idea of, you can’t actually. For people that need this kind of data and could afford our service and, the money not going to us means that we can’t do more to improve the security of WordPress plugins than we already do, which makes everyone using WordPress less secure.

13 Feb

The Missing Story About WordPress Plugin Developers’ Failure To Make Sure Their Plugins Are Secure

Coverage of WordPress plugin vulnerabilities is rather poor and coverage of an authenticated option update vulnerability in the plugin Simple Social Buttons disclosed on Monday was no exception. For example, you had a security journalist that frequently spreads false and misleading information, Catalin Cimpanu, make this statement in regards to WordPress:

Some sites are inherently protected against this vulnerability, as their admins have already blocked user registration due to security reasons.

In reality user registration is disabled by default by WordPress, which severely limits the threat posed by authenticated vulnerabilities (since they require someone to be logged in to WordPress to exploit). You have to wonder if he made that claim up himself or someone else told him something that isn’t based in reality, but that sort of inaccurate information could be avoided by getting a second source for stories that is more knowledgeable about WordPress, but security journalist don’t seem too interested in getting things right (including simple factual items like that WordPress isn’t owned by Automattic).

It turns out there is something that seems more worthy of coverage related to this vulnerability, though something that didn’t get mentioned by in articles about it or by the discoverer, WebARX. In WebARX’s post about the vulnerability it is only explained in vague detail about how the vulnerability was run across, the post starts with this:

Finding security vulnerabilities is an important part of securing our client’s sites and improving our managed web application firewall. That is why WebARX is analyzing WordPress plugins for security issues and reporting them to competent developers or organizations.

While doing research we found a vulnerability in popular WordPress plugin Simple Social Buttons which allows non-admin users to modify WordPress installation options.

A possible explanation of how they came across this vulnerability is that they previously ran across the same type of issue with another plugin by the same developer. At the end of November they disclosed that the plugin LoginPress had a vulnerability caused by the same issue, a lack of proper security when importing plugin settings through WordPress’ AJAX functionality. That one was more limited since arbitrary options could not be updated, like the more recently disclosed vulnerability.

You would think that the developer would have made sure that their other plugins were then properly after being alerted to that issue in one of the plugins, but that wasn’t the case (we checked their other plugins and the others don’t seem to have that same functionality). That isn’t a one off issue and seems like the kind of thing that is important to understand when trying to understand why the security of WordPress plugins is so poor and what can be done to improve it.

Critical Should Mean Critical

What is also seems worth noting about this situation is the over usage of “critical” when describing vulnerabilities.  For both the less serious variant of the vulnerability in LoginPress and the more serious in Simple Social Buttons the discoverer called them critical in their posts about them, “Multiple Critical Vulnerabilities in LoginPress WordPress Plugin” and “WordPress Plugin ‘Simple Social Buttons’ Critical Security Bug”. We would have a hard time even calling the vulnerability in Simple Social Buttons critical because of the more limited likelihood of exploitation due to being authenticated (though that is increased with the coverage it received). With the LoginPress vulnerabilities we haven’t seen any evidence of exploitation at attempts since they were disclosed, which seems like a good indication that calling critical is overstated.

12 Feb

Vulnerability Details: CSRF/SQL Injection in WP Tabs Responsive horizontal vertical and accordion Tabs

This Vulnerability Details post about a vulnerability in the plugin WP Tabs Responsive horizontal vertical and accordion Tabs provides the details of a vulnerability we didn't discover and access to it is limited to customers of our service, unlike the posts on vulnerabilities we have discovered, which are freely available and give you an idea of what information is provided in the details posts as well.

For existing customers, please log in to your account to view the rest of the post.

If you are not currently a customer, you can sign up here. There are a lot of other reason that you will want to sign up beyond access to posts like this one, including that you would have already been warned about this vulnerability if your website was vulnerable due to it.

If you are a WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.

11 Feb

Vulnerability Details: Reflected Cross-Site Scripting (XSS) in NextScripts: Social Networks Auto-Poster

This Vulnerability Details post about a vulnerability in the plugin NextScripts: Social Networks Auto-Poster provides the details of a vulnerability we didn't discover and access to it is limited to customers of our service, unlike the posts on vulnerabilities we have discovered, which are freely available and give you an idea of what information is provided in the details posts as well.

For existing customers, please log in to your account to view the rest of the post.

If you are not currently a customer, you can sign up here. There are a lot of other reason that you will want to sign up beyond access to posts like this one, including that you would have already been warned about this vulnerability if your website was vulnerable due to it.

If you are a WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.

11 Feb

Vulnerability Details: Security Bypass in Flexible Captcha

This Vulnerability Details post about a vulnerability in the plugin Flexible Captcha provides the details of a vulnerability we didn't discover and access to it is limited to customers of our service, unlike the posts on vulnerabilities we have discovered, which are freely available and give you an idea of what information is provided in the details posts as well.

For existing customers, please log in to your account to view the rest of the post.

If you are not currently a customer, you can sign up here. There are a lot of other reason that you will want to sign up beyond access to posts like this one, including that you would have already been warned about this vulnerability if your website was vulnerable due to it.

If you are a WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.

08 Feb

Closures of Very Popular WordPress Plugins, Week of February 8

While we already are far ahead of other companies in keeping up with vulnerabilities in WordPress plugins (amazingly that isn’t an exaggeration), in looking in to how we could get even better we noticed that in a recent instance were a vulnerability was exploited in a plugin, we probably could have warned our customers about the vulnerability even sooner if we had looked at the plugin when it was first closed on the Plugin Directory instead of when the vulnerability was fixed (though as far as we are aware the exploitation started after we had warned our customers of the fix). So we are now monitoring to see if any of the 1,000 most popular plugins are closed on the Plugin Directory and then seeing if it looks like that was due to a vulnerability.

This week one of those plugins was closed and has not been reopened.

Logo Carousel

Logo Carousel, which has 40,000+ installs, was closed on Wednesday. No reason has been given for the closure. In looking over the plugin we found that it contains a cross-site request forgery (CSRF)/ cross-site scripting (XSS) vulnerability.

08 Feb

Not Really a WordPress Plugin Vulnerability, Week of February 8

In reviewing reports of vulnerabilities in WordPress plugins 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.

Cross Site Request Forgery / Shell Upload Vulnerability in Ultimate Member

Recently many of the claimed vulnerabilities we have mentioned in these posts have come from someone with the handle “KingSkrupellos” that the website Packet Storm continues to allow to post false reports. They were at it again with a claimed cross site request forgery / shell upload vulnerability in Ultimate Member. In this case they claim that there is vulnerability in the latest version of the plugin involving files that don’t exist in it.

In the older version of the plugin they also mention, which includes those files, they seem to be confusing an error indicating that the file upload code has not run, ‘{“error”:”A theme or plugin compatibility issue”}’, as meaning that a file has been uploaded.

Shell Upload Vulnerability in WP User Manager

The claimed shell upload vulnerability in WP User Manager seemed false based on this based on this part of the proof of concept, “you can upload your shell by adding image extensions to end of your shell. (ex: SHELL.php.png)”. Since the file has an image extension the server shouldn’t see it as type of file that allows code to run, so it wouldn’t be “shell”. The uploading is handled through the WordPress function wp_handle_upload(), so if someone wants to claim there is an issue with allowing dual extensions, then they should be labeling it as a security issue with WordPress.

Cross-Site Scripting (XSS) Vulnerability in Parallax Scroll

With a claimed vulnerability in Parallax Scroll the tip off that something might be amiss came with the claimed vulnerability be listed as a cross-site scripting (XSS) vulnerability, despite usually there being a modifier included (for example a reflected XSS or a persistent XSS). Looking at the changes made that were supposed to fix this, it involved outputting the value of the WordPress function get_the_title(), which returns the title of a post. WordPress shouldn’t be outputting values that lead to unintended XSS and in fact it isn’t. What we found was that this involved a custom post type, where the title allows JavaScript code only if the user has the “unfiltered_html” capability, which permits the equivalent of XSS. To put this another way, even without this plugin installed the users who could create customs posts through it, could do the same thing that was supposed to be a vulnerability, but just by creating a normal post or page.

08 Feb

Vulnerability Details: Authenticated Settings Change in Launcher

This Vulnerability Details post about a vulnerability in the plugin Launcher provides the details of a vulnerability we didn't discover and access to it is limited to customers of our service, unlike the posts on vulnerabilities we have discovered, which are freely available and give you an idea of what information is provided in the details posts as well.

For existing customers, please log in to your account to view the rest of the post.

If you are not currently a customer, you can sign up here. There are a lot of other reason that you will want to sign up beyond access to posts like this one, including that you would have already been warned about this vulnerability if your website was vulnerable due to it.

If you are a WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.