Blog | Plugin Vulnerabilities | A service to protect your site against vulnerabilities in WordPress plugins.

20 Oct

WPScan Vulnerability Database Falsely Claims WP Job Manager Contained Arbitrary File Upload Vulnerability

When it comes to getting data on vulnerabilities in WordPress plugins there are a number of companies that are interested in making it appear they are generating that type of data without having to do the work it takes to provide that. They instead of reuse data from the WPScan Vulnerability Database, sometimes without disclosing that is the source and in every instance we have seen so far, without providing a warning as the low quality of the data. As example here was what Wordfence’s plugin recently sent out to people using the plugin Sermon Browser:

The Plugin “Sermon Browser” has been removed from wordpress.org.
Current Plugin Version: 0.45.19

Severity: Critical

Vulnerability Information:
https://wpvulndb.com/vulnerabilities/6404

Status New

It has unpatched security issues and may have compatibility problems with the current version of WordPress. Get more information.
https://docs.wordfence.com/en/Understanding_scan_results#Plugin_has_been_removed_from_wordpress.org

As we noted previously, the vulnerability being linked there had been fixed six years ago. For whatever reason when it was added to WPScan’s data three years ago it was not listed as being fixed, so when Wordfence reused the data without checking it first they spread inaccurate information. They didn’t include a disclaimer to warn people that they hadn’t checked that data, they even make it sounds like the opposite as they said “It has unpatched security issues”, and therefore didn’t know if it there was any veracity to the claim of a vulnerability in the plugin.

The problem with WPScan’s data isn’t limited fixed vulnerabilities are not correctly labeled as being fixed. Another issue is vulnerabilities that didn’t actually exist being included and labeled as being fixed despite not existing, an example of we just ran across while preparing another post. That could be a problem if you were using WPScan’s data while working on cleaning up a hacked website, since you might believe that you have discovered a likely cause of a hacking, through an outdated plugin, only to later find that wasn’t the case when the website gets hacked again.

This isn’t the first time we have run across this, but what we found notable about this instance is that one of our blog posts is cited despite contradicting their information.

Here is the entry as it is currently:

The claim is that there was an unauthenticated arbitrary file upload vulnerability in the plugin WP Job Manager, which has been fixed. There first reference for that, an entry at Packet Storm from July of last year, makes the claim that there was a remote shell upload/arbitrary file upload vulnerability as of version 1.25. In August of last year we wrote a post detailing why that was false, as the plugin limits what types of files can be uploaded. The plugin did and still does allow anyone to upload files permitted by WordPress.

The third reference cited by WPScan states that:

Fix: Prevents use of Ajax file upload endpoint for visitors who aren’t logged in.

All that indicates is that those not logged in to WordPress can no longer uploads files through WordPress AJAX functionality, but as we already mentioned the plugin did not allow arbitrary files to be uploaded, so the change does not relate to what they said was fixed.

What is the other important part of this is what was mentioned in the post of ours that was cited:

But more importantly we didn’t understand how the change made was supposed to fix the issue since by default those that didn’t already have a WordPress accounts could still upload images through the plugin.

As the title of our post indicates, “Image Upload Capability in WordPress Plugin Being Abused”, the issue with this plugin was that the ability to upload images was being abused. The change made doesn’t actually remove that capability, it just removes the ability to do that through AJAX. You don’t have to take our word from that, here is what one of the developers said:

Hi there! They shouldn’t be prevented from uploading files, just through the use of the Ajax endpoint. The forms should fallback to normal file uploads and work just fine.

So to recap, the vulnerability that WPScan lists didn’t exist, but if there was a security vulnerability in the plugin, it still exists, just the way it was being abused at the time was removed.

While we think that WPScan’s data is good source for a lot of people because it can be accessed for free, you do get what you pay for. Where its use is more problematic is when it is used by security companies without a proper disclaimer as to the sourcing and quality issues, which also extend to have a limited set of new vulnerabilities in it. If those companies were to admit to all of that, it would probably make more people understand that the inflated claims these companies often make about their expertise are far from the truth. (It would also help us, as once people realize the value of such data, getting better quality data would likely be of more interest to some of them.)

20 Oct

Just Because a WordPress Plugin is Popular, It Doesn’t Mean It is Secure

Earlier this week we discussed an incorrect belief that WordPress plugins that are monetized will have any discovered security issues quickly fixed, which led to the suggestion that you should only use monetized plugins. That is far from the only time we have seen advice on choosing plugins to use with an emphasis on security that doesn’t hold up to scrutiny. Another one out there is that popular plugins are somehow more secure. The reality is that we haven’t seen any evidence presented that would back up there is a correlation between popularity and security. About the closest we can think of is that it does appear that people looking for vulnerabilities for non-malicious purposes (whether they be security researchers or security companies interested in publicity) are more likely to look at more popular plugins. That seems to be at least partly due to the fact that security journalist are more likely to cover very minor vulnerabilities that have been fixed in popular plugins than unfixed vulnerabilities that are being exploited in less popular plugins, despite the latter being much more important to cover.

That brings us to a very popular plugin we recently took a look into after a vulnerability was vaguely disclosed in it. The plugin Duplicate Page has 300,000+ active installations according to wordpress.org. That plugin allows duplicating pages and posts. Recently the security scanner service Detectify disclosed that the plugin has or had contained an “Authenticated XSS” vulnerability. As we have done with other vulnerabilities they have been vaguely disclosing, but usually not bothering to notify the developer of, we went to try to determine what the issue was and then notify the developer. Once we started looking into this we found five vulnerabilities in the plugin due to multiple security failures, most of which involve failing to do security basics.

In looking at the code we first found the value of the GET or POST input “post” is set to the variable “$post_id ” in the file /duplicatepage.php without being validated or sanitized:

93	$post_id = (isset($_GET['post']) ? $_GET['post'] : $_POST['post']);

Later in the file the value of the variable is output with being escaped:

169	wp_die('Error! Post creation failed, could not find original post: ' . $post_id);

That is a reflected cross-site scripting (XSS) vulnerability and appears to be what Detectify was referring to as it occurs it can be exploited when logged in to WordPress.

A basic rule of security, put a number of different ways, is to not trust user input, but that hasn’t been applied in this plugin based on that.

The value of the variable is also used in the following SQL statement:

143	$post_meta_infos = $wpdb->get_results("SELECT meta_key, meta_value FROM $wpdb->postmeta WHERE post_id=$post_id");

That could lead to SQL injection, which involves additional code running in database query that comes from user input. SQL statements that involve user input should be parametrized to prevent that occurring, which hadn’t been done with this code. Since the value of $post_id should an integer limiting its value to that would have also prevented that as well. That SQL injection vulnerability is exploitable directly by anyone logged in to WordPress and it can also be exploited through the next security failure.

When making a request to duplicate a post or page the URL looks like this:

/wp-admin/admin.php?action=dt_duplicate_post_as_draft&post=1

What is missing from that is a nonce, which is a unique value used to prevent cross-site request forgery (CSRF). CSRF allows an attacker to cause someone that is allowed to take an action to take it when they are not intending to. In this case getting someone logged in to WordPress to click a link to a URL like that would cause a duplication to occur. That doesn’t really seem like a major issue here since the duplicate is saved as a draft. It could be used combined with the SQL injection vulnerability, though the usefulness of that is limited as well.

One of the things that we bring to the table that there probably isn’t another company comes close to with when it comes to vulnerabilities in WordPress, is a store house of knowledge from reviewing well over a thousand vulnerabilities. So when it came to this plugin we had previously looked at the details of a CSRF vulnerability in very similar plugin, Duplicate Post, which has 2+ million active installs. That led us to noticing the final issue with this plugin.

The plugin allows anyone logged in to WordPress to duplicate any post or page. For publicly viewable content that doesn’t really matter, but it could allow a lower level user without access to a password protected post to duplicate it and then view the contents of the post. That could be prevented by checking if a user is allowed to edit the post or page before doing the duplication.

We notified the developer of all but the last issue on October 4 through the contact form on their website. We then sent an email to the email address listed on the plugin’s page on wordpress.org that included all of the issues a week ago. We have yet to receive any response and a new version of the plugin has not been released.

Development Standards

The developer of the plugin, Webdesi9, presents their capabilities with WordPress plugins differently than the security of this plugin would seem to indicate.

They claim to “follow best quality standards”, which seems to not be the case:

Conferring you with fully functional plugins, our WordPress plugin development follow best quality standards. Get powerful and versatile WordPress plugins developed at Webdesi9.

They also claim to have “expert” WordPress plugin developers, which if true, doesn’t say good things about the handling of security in WordPress plugins in general:

Our experienced and expert set of WordPress Plugin developers provide power packed features and custom plug-ins to augment the performance and productivity of your website.

While the vulnerabilities in Duplicate Page have a limited impact, in another of the developer’s plugins the poor security was more serious. For about the first ten months that their plugin, WP File Manager existed, it would have allowed an attacker to view arbitrary files on a website and also allowed arbitrary files to be uploaded. Those are two of the top types of vulnerabilities in terms of exploit attempts (the vulnerabilities in Duplicate Page are unlikely to be exploited on the average website). When a security change was made that fixed those (but didn’t properly secure things) the developer didn’t change the version for two months, leading to probably 10s of thousands of websites to remain vulnerable. We contacted the developer shortly after the security fix was made to let them know about the incomplete fix and the lack of a version number bump, but we received no response. When the version number was changed you wouldn’t have known there even was security update based on the changelog:

fix some Bug in 1.6 – Minor Update

System Properties Menu – Added(New)

Making Sure the Plugins You are Using Are Secure

While there are a lot of suggestions out there on how to determine if plugins are secure, we can only think of a couple that might be useful. The first is to look at how the developer has handled any previously disclosed vulnerabilities, which could give you some indication of how they handle security of the plugin. Beyond that, the only way to directly check on the security of the plugin is to have a security review done.

For both of this developer’s plugins a good review should have caught most of the issues in them.

With our service you can suggest/vote for plugins to receive a security review from us, so that any issues like in these plugin can be found and fixed or if they don’t get fixed, you are aware that the developer isn’t properly handling security. You can also order a review of plugin separately from the service.

20 Oct

Authenticated Information Disclosure Vulnerability in Duplicate Page

We recently went to a take a look at the details of a reflected cross-site scripting (XSS) vulnerability that had been disclosed in the plugin Duplicate Page we noticed that it also had a cross-site request forgery (CSRF) vulnerability. After that we remember that a similar plugin Duplicate Post had previously had a vulnerability that allowed lower level users to get access to password protected posts by duplicating them that was in part due to a lack of protection against CSRF and we then went to check if that was issue with that plugin as well. We found that it was possible.

With the other plugin its functionality was only intended to be used by Editor and Administrator-level users, while with this one the plugin ads links to do the duplication as long as the user has the “edit_posts” capability (in the file /duplicatepage.php):

178
179
180

if (current_user_can('edit_posts')) {
$actions['duplicate'] = '<a title="Duplicate this as '.$post_status.'" href="admin.php?action=dt_duplicate_post_as_draft&post=' . $post->ID . '" rel="permalink">'.__( "Duplicate This", "duplicate_page" ).'</a>';
}

That normally is available to contributor-level and above users.

The duplication is handled by the function dt_duplicate_post_as_draft(), which is accessible to anyone logged in because it is registered as an admin_action:

23	add_action( 'admin_action_dt_duplicate_post_as_draft', array(&$this,'dt_duplicate_post_as_draft') );

That function doesn’t perform any checks as to who is making the request, so anyone that is logged in can duplicate any post. Normally only contributor-level and above could then view the resulting post since it is stored as a draft by default. Through that they could gain access to the contents of posts they would normally not have access to, including password protected posts.

We notified the developer of other security issues in the plugin through their website on October 4 and planned to mention this once they responded, but they didn’t respond. We then notified them of this through the email address listed on the plugin’s page on wordpress.org on October 13, as well as mentioning the previous issues again. We have yet to hear back from them and a new version has not been released. In line with our disclosure policy, which is based on the need to provide our customers with information on vulnerabilities on a timely basis, we are now disclosing this vulnerability.

Proof of Concept

Log in to WordPress as a contributor-level user and visiting the following URL, with the value of “[path to WordPress]” replaced with the location of WordPress and “[post ID]” replaced with the value of a password protected post on the website:

http://[path to WordPress]/wp-admin/admin.php?action=dt_duplicate_post_as_draft&post=[post ID]

You will now be able to view the contents of the post without having to enter a password.

Timeline

October 13, 2017 – Developer notified.

20 Oct

Cross-Site Request Forgery (CSRF) Vulnerability in Duplicate Page

While looking into the details of a reflected cross-site scripting (XSS) vulnerability in the plugin Duplicate Page we noticed that there was no protection against cross-site request forgery (CSRF) when using the plugin’s functionality, duplicating a post or page.

As of version 2.3 the URLs for the duplication looks like this:

/wp-admin/admin.php?action=dt_duplicate_post_as_draft&post=1

If there was protection against CSRF there would be a nonce included in that.

We notified the developer of the issue through their website on October 4 and through the email address listed on the plugin’s page on wordpress.org on October 13. We have yet to hear back from them and a new version has not been released. In line with our disclosure policy, which is based on the need to provide our customers with information on vulnerabilities on a timely basis, we are now disclosing this vulnerability.

Proof of Concept

The following proof of concept will duplicate the POST with ID number 1, when logged in to WordPress.

Make sure to replace “[path to WordPress]” with the location of WordPress.

http://[path to WordPress]/wp-admin/admin.php?action=dt_duplicate_post_as_draft&post=1

Timeline

October 4, 2017 – Developer notified.
October 13, 2017 – Developer notified.

20 Oct

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in Duplicate Page

Recently the security scanner service Detectify seems to have disclosed a number of unfixed reflected cross-site scripting (XSS) vulnerabilities in WordPress plugins that the developers may not have been notified of. We are still in the process of going through those, but so far we found that not only had some of the developers not been notified, but also Detectify seems to have claimed that ...

To read the rest of this post you need to have an active account with our service.

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

If you are not currently a customer, when you sign up now you can try the service for free for the first month (there are a lot of other reason that you will want to sign up beyond access to posts like this one).

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

20 Oct

Vulnerability Details: Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in Use Any Font

Recently the web scanner service Detectify has been vaguely disclosing minor vulnerabilities in a number of WordPress plugins. It seems like they are aware that they could notify the developer of these, but usually haven’t been doing it. One of the more recent batch was a cross-site request forgery (CSRF) vulnerability in the plugin Use Any Font.

When we went to look into this ...

To read the rest of this post you need to have an active account with our service.

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

If you are not currently a customer, when you sign up now you can try the service for free for the first month (there are a lot of other reason that you will want to sign up beyond access to posts like this one).

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

19 Oct

Arbitrary File Viewing Vulnerability in Candidate Application Form

Recently in our monitoring of the WordPress Support Forum we ran across a thread about claiming a vulnerability being exploited in a plugin Candidate Application. The vulnerability being referred to there was actually in another plugin. The slug of the plugin being discussed is wp-candidate-application-form and the vulnerability was for a plugin with the slug candidate-application-form. The vulnerability mentioned in thread was disclosed in July of 2015. The author of both of the plugins is the same and it looks like after the first plugin was removed they simply moved to the new one. That seems like something that the Plugin Directory should have noticed at the time the second one was submitted for the Plugin Directory.

Looking at the code of the new plugin we found that it has the same type of vulnerability as the first one, though the code has been changed.

In the new plugin, during init the plugin will run the function DownloadAttachment() (in the file /apply_form.php):

1458	add_action('init', array($this, 'DownloadAttachment'));

That function then will call the function downloadUrlToFile() if the GET or POST input “download-attachment” exists:

function DownloadAttachment()
{
	if (isset($_REQUEST['download-attachment'])) {
		$dir = FILE_UPLOAD_DIR;
		$file = sanitize_text_field($_REQUEST['file']);
		$this-&gt;downloadUrlToFile($dir, $file);
	}
}

In the function downloadUrlToFile() there is code that will output the contents of a file in various ways. The file being to be output is based on combining the value of the $dir and $file variables from the DownloadAttachment() function. The value of $dir would be based on the upload directory of the plugin, /wp-content/uploads/candidate_application_form/. The $file value is based on the value of the GET or POST input “file”. There is no restriction on directory traversal, so that code can be used to view the contents of file outside of the upload directory of the plugin.

We contacted the developer a week ago, but haven’t heard anything back from them and the plugin hasn’t been updated. The plugin was last updated 22 months ago, so it doesn’t seem to be being supported anymore. In line with our disclosure policy, which is based on the need to provide our customers with information on vulnerabilities on a timely basis, we are now disclosing this vulnerability.

Proof of Concept

The following proof of concept will display the contents of the WordPress configuration file, wp-config.php.

Make sure to replace “[path to WordPress]” with the location of WordPress.

http://[path to WordPress]/?download-attachment=test&file=../../../wp-config.php

Timeline

October 12, 2017 – Developer Notified

19 Oct

This Might Be Why Note Press Was Removed From the WordPress Plugin Directory

When it comes to improving the security of WordPress one the easiest things to do would be to start alerting when websites are using plugins that have been removed from the Plugin Directory for security issues. We have been trying to get that to happen for over five years, but the WordPress team has continued to refuse to do that, while claiming they are “working on it”. Recently the Wordfence Security plugin has started to warn when removed plugins are in use, which has led to more people realizing they are using removed plugins, but leaving them not knowing why the plugin was removed as there are other reasons for removal. That isn’t all the helpful as can be seen by the company behind that plugin touting this feature with a quote from a person that left a plugin with intentionally malicious code in it on their websites after it was removed from the Plugin Directory multiple times. Instead of Wordfence getting behind the effort to get this issue properly resolved, they would rather promote people being reliant on their plugin for incomplete information on removed plugins, while sometimes providing those using their plugin with outright false information about the situation with a removed plugin.

One place people have been looking for answers is the WordPress Support Forum, but unfortunately that is in as bad as shape as the handling of security by the WordPress team. The other day we left a comment correcting a misunderstanding of a comment from someone from the Plugin Directory as to whether a removed plugin contained a security issue and our comment was promptly deleted and the topic closed. So you are not going to be able to rely on getting accurate information there until the moderation of the forum is fixed.

In light all that we thought it would helpful to start putting out post when we become of possible explanation of why plugins were removed. If you are aware of a plugin that has been removed where there isn’t a possible explanation available please get in touch with us, so that we can look in to the situation.

For the second of these posts, it involves a plugin, Note Press, which our monitoring picked up having a security issue fixed recently and when we went look into that we noticed the plugin was removed.

As describe in more detail in our vulnerability details post about that vulnerability, four days ago, a file that had been in the plugin, /admin/mysql.php, was removed. That file would allow connecting to a database and viewing the table names of the database. You would need to know the credentials of the database for that to happen. The file would also expose a couple of other piece of information about the server, though those seem to probably not be a security concern in most instances. That file wasn’t used in the plugin and our best guess is that it was accidentally included in the plugin as opposed to being placed there for malicious purposes.

It seems likely that file is what caused the plugin to be removed from the Plugin Directory.

Since a fixed version has been submitted to the Subversion repository that underlies the Plugin Directory, it is possible to get access to that if you are familiar with how to work with that. For time being you can also delete that file. There were also some other fixes made to the plugin right around the time that it was removed, so you may have errors when using something less than the latest version.

Protecting Yourself Against Known Vulnerable Plugins

At this time, even if you deleted any plugins once it got removed from the Plugin Directory you could still be using plugins that have publicly disclosed vulnerabilities. That is due to the fact the no one on the WordPress team is out there making sure they pull plugins once vulnerabilities are disclosed in them and no one else notifies of them of that situation on a systematic basis. In the past we had been doing that, but we suspended doing that until WordPress finally puts forward a concrete plan to warn people about removed plugins and a concrete plan to reform the moderation of the Support Forum, so that the public can get accurate information on security from there and people trying to get vulnerabilities fixed stop getting harassed.

In the meantime installing the companion plugin for our service will get you alerted if you are using plugin that has a vulnerability that is being exploited. With our service not only will you get alerted about all vulnerabilities that we are aware of (which is many more than other providers), but we are available to assist you in determining what is the best option if you are using a plugin with an unfixed vulnerability. In many cases we can provide you with a temporary workaround so that you can continue to use the plugin until the plugin is fixed for everyone (we always try to work with developer to get their plugins fixed as well) or until you can move to another solution. In a situation like this, were there is a fixed version put out, but that you can’t update to it through the normal process, we can help our customers to apply the update as well.

Our service also allows you suggest/vote for plugins to receive a security review from us, so you can find out if the plugins you are using are secure before someone with bad intentions might find a vulnerability in one of them.

19 Oct

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in WP-Members

_{From time to time a vulnerability is fixed in a plugin without the discoverer putting out a report on the vulnerability and we will put out a post detailing the vulnerability so that we can provide our customers with more complete information on the vulnerability.}

Recently the web scanner service Detectify has been vaguely disclosing minor vulnerabilities in a number of WordPress plugins. It seems ...

To read the rest of this post you need to have an active account with our service.

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

If you are not currently a customer, when you sign up now you can try the service for free for the first month (there are a lot of other reason that you will want to sign up beyond access to posts like this one).

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

18 Oct

This Might Be Why Starbox Was Removed From the WordPress Plugin Directory

When it comes to improving the security of WordPress one the easiest things to do would be to start alerting when websites are using plugins that have been removed from the Plugin Directory for security issues. We have been trying to get that to happen for over five years, but the WordPress team has continued to refuse to do that, while claiming they are “working on it”. Recently the Wordfence Security plugin has started to warn when removed plugins are in use, which has led to more people realizing they are using removed plugins, but leaving them not knowing why the plugin was removed as there are other reasons for removal. That isn’t all the helpful as can be seen by the company behind that plugin touting this feature with a quote from a person that left a plugin with intentionally malicious code in it on their websites after it was removed from the Plugin Directory multiple times. Instead of Wordfence getting behind the effort to get this issue properly resolved, they would rather promote people being reliant on their plugin for incomplete information on removed plugins, while sometimes providing those using their plugin with outright false information about the situation with a removed plugin.

One place people have been looking for answers is the WordPress Support Forum, but unfortunately that is in as bad as shape as the handling of security by the WordPress team. The other day we left a comment correcting a misunderstanding of a comment from someone from the Plugin Directory as to whether a removed plugin contained a security issue and our comment was promptly deleted and the topic closed. So you are not going to be able to rely on getting accurate information there until the moderation of the forum is fixed.

In light all that we thought it would helpful to start putting out post when we become of possible explanation of why plugins were removed. If you are aware of a plugin that has been removed where there isn’t a possible explanation available please get in touch with us, so that we can look in to the situation.

For the first of these posts we will return to the plugin we had tried to help clear up confusion over the other day, Starbox.

As describe in more detail in our vulnerability details post, two weeks ago, which was after the plugin was removed, an authenticated persistent cross-site scripting (XSS) vulnerability that would have allowed logged in users to cause malicious JavaScript code to load on the frontend of the websites and for Administrators in certain instances was fixed. There were several smaller security fixes made, but that seems like it would be what would have gotten the plugin removed.

The vulnerability would be a threat if a website had users with malicious intentions.

Since a fixed version has been submitted to the Subversion repository that underlies the Plugin Directory, it is possible to get access to that if you are familiar with how to work with that. The vulnerability is only exploitable if the plugin is active, so deactivating it would also protect you for now.

Protecting Yourself Against Known Vulnerable Plugins

At this time, even if you deleted any plugins once it got removed from the Plugin Directory you could still be using plugins that have publicly disclosed vulnerabilities. That is due to the fact the no one on the WordPress team is out there making sure they pull plugins once vulnerabilities are disclosed in them and no one else notifies of them of that situation on a systematic basis. In the past we had been doing that, but we suspended doing that until WordPress finally puts forward a concrete plan to warn people about removed plugins and a concrete plan to reform the moderation of the Support Forum, so that the public can get accurate information on security from there and people trying to get vulnerabilities fixed stop getting harassed.

In the meantime installing the companion plugin for our service will get you alerted if you are using plugin that has a vulnerability that is being exploited. With our service not only will you get alerted about all vulnerabilities that we are aware of (which is many more than other providers), but we are available to assist you in determining what is the best option if you are using a plugin with an unfixed vulnerability. In many cases we can provide you with a temporary workaround so that you can continue to use the plugin until the plugin is fixed for everyone (we always try to work with developer to get their plugins fixed as well) or until you can move to another solution. In a situation like this, were there is a fixed version put out, but that you can’t update to it through the normal process, we can help our customers to apply the update as well.

Our service also allows you suggest/vote for plugins to receive a security review from us, so you can find out if the plugins you are using are secure before someone with bad intentions might find a vulnerability in one of them.