22 Dec

The Problem With Relying On Wordfence For Security Information

A month ago we discussed how Wordfence’s idea of keeping “site owners safe from exploitation” actually puts them at risk. Part of what we mentioned in that was that relying on security companies to tell if you plugins should be updated due to vulnerabilities being fixed is a bad idea for a number of reasons. One of them being that, as was shown with Wordfence’s post, they may be doing that well after a vulnerability was fixed, and in the case of that post, also well after it was publicly disclosed that the vulnerability was being exploited.

Along those lines it was only on December 19th that Wordfence put out a post warning about the plugin Captcha, something we did back on December 8th. That post does add some more information beyond what we identified back then, but the main point has been out there for some time before they got around to mentioning that.

When we went to look at that post we also noticed another post of theirs that is a reminder that Wordfence seems less interested providing accurate and timely information, and more interested in promoting themselves, even if that comes at the expense of people’s view of the security of WordPress.

This is Not a Brute Force Attack

The day before that post about Captcha, they had another one titled “Breaking: Aggressive WordPress Brute Force Attack Campaign Started Today, 3am UTC”, which like their previous claims along these line, isn’t true.

That can be seen starting with the last sentence of the first paragraph:

This is the most aggressive campaign we have seen to date, peaking at over 14 million attacks per hour.

A brute force attack involves trying every possible password combination to log in to a website. To give some idea of what kind of numbers that would involve, here is something we wrote on our main blog a while back:

To give you an idea how many login attempts that would take, let’s use the example of a password made up of numbers and letters (upper case and lower case), but no special characters. Below are the number of possible passwords with passwords of various lengths:

  • 6 characters long: Over 56 billion possible combinations (or exactly 56,800,235,584)
  • 8 characters long: Over 218 trillion possible combinations (218,340,105,584,896)
  • 10 characters long: Over 839 quadrillion possible combinations  (839,299,365,868,340,224)
  • 12 characters long: Over 3 sextillion possible combinations  (3,226,266,762,397,899,821,056)

For a 6 character long password, trying half of the possible combinations at 14 million an hour would take 2,000 hours or over 83 days. So that would take a while to possibly succeed.

In this case though the numbers would be much worse since Wordfence wasn’t claiming that 14 million attempts per hour for one website, but for up to 190,000

  • We are seeing up to 190,000 WordPress sites targeted per hour.

That works out to about 74 attempts per hour per website, so this clearly isn’t a brute force attack. If they lead with that number, people would be lot less concerned, but Wordfence seems more interested in creating unnecessary fear to push their plugin:

If you have not already done so, install Wordfence immediately on your site.

And their paid service:

We strongly recommend that you upgrade to Wordfence Premium to benefit from the real-time blacklist feature which blocks any traffic from these malicious IPs.

In this case, Wordfence actually indicates what they are talking about isn’t a brute force attack, as they write:

A possible explanation for this new massive increase in brute force attacks
On December 5th, a massive database of hacked credentials emerged. It contains over 1.4 billion username/password pairs. Approximately 14% of the database contains credentials that have not been seen before. The database is also searchable and easy to use.

When we bring up the repeated false claims of brute force attacks against WordPress admin password, people have repeatedly claimed that this is simply a semantic issue, but the reality is how you handle different types of attacks is different, so you need to first need to know what is really going on.

In a case where someone is trying to login in using shared credentials the best protection against that is to not use the same username/password across websites and yet in Wordfence’s list of 8 of actions to protect against this, the relevant one is all the way at the end:

8. Do not reuse a password on multiple services. That way if you have a password from a data breach in this new database, it won’t be the same as your WordPress admin password. You can use a password manager like 1password to manage many passwords across services.

Before you get to that, five of the entries are promoting their plugin or service, for example number one is:

1. Install a firewall like Wordfence that intelligently blocks brute force attacks.

If you use the same username and password across websites and that is breached the website could be breached with as little as one login attempt and firewall is going to be able provide limited protection at best, so that shouldn’t be the number one thing to do. Two factor authentication would be a better option, but that only comes in at number 5.

Number 2 shows that they will even promote their product over mentioning where WordPress does a good job on security:

2. Ensure that you have strong passwords on all user accounts, especially admin. Wordfence Premium provides password auditing capability.

You don’t need password auditing capability as WordPress already provides a good measure of the security of passwords and by default it generates secure ones. If you wanted to improve things then it might make sense to limit passwords to strong ones, instead of trying to auditing them after the fact.

There is another problem with these types of claims, it is causing people to take the wrong lesson from them. There are several comments on Wordfence’s posts about not using WordPress because of things like this. Here is one:

Thanks for the support and heads up Mark.
This rubbish is exactly why I will no longer use WordPress.
Just this week I have already shifted my sites across to another platform.
I feel for everyone who has no idea on the simplest security measures, including the free level of Word Fence let alone paying for the Premium version.
It’s not what it costs up front, but the cost to repair, replace or fix what has been lost.

The reality is this type of attack isn’t in some way connected to WordPress or unique to it, but Wordfence presents thing in way to that leads people to believe otherwise. Probably because they are most interested in promoting their WordPress security products, even when they are not the best solution to the problem.

22 Dec

Is This What a Hacker Might Be Interested in the Pretty Links Plugin For?

Last week we had requests from the IP address to our website that looked like they might be a hacker probing for usage of the plugins SendinBlue Subscribe Form And WP SMTP and Table Maker. After seeing that, we checked over the plugins to try find if there was a vulnerability in them that a hacker would be interested in.

With SendinBlue we found a SQL injection vulnerability that might be able to be used to cause PHP object injection to occur. PHP object injection is a type of issue that is highly likely to be exploited if it exists. That vulnerability has yet to be fixed.

With Table Maker we found multiple vulnerabilities, including a SQL injection vulnerability that we confirmed could lead to PHP object injection. Those have now been fixed.

The other day we had a couple of requests from the same IP address for the file /wp-content/plugins/pretty-link/readme.txt, which is a file from the plugin Pretty Links.

In looking into that IP address we found that we are not the only ones receiving the requests for a file in those three plugins, as someone reported to abuseipdb.com that they had received the same requests.

When it comes to Pretty Links, we were already aware of two publicly disclosed reflected cross-site scripting (XSS) vulnerabilities that exist in the most recent version of the plugin. For one of those we notified the developer of the plugin about the disclosure at the beginning of October. They responded shortly after that “This will be fixed very soon.”, but it hasn’t so far. (For the other vulnerability we don’t know if the discloser notified the developer and we were planning to notify the developer about it if when they put out version that fixed the vulnerability we had notified them, the other had not been fixed as well.) That the vulnerability still hasn’t been fixed raises the possibility that there may be other vulnerabilities that the developer has been informed about, but they have yet to fix. That type of vulnerability is not likely to be exploited on the average website, so it seems unlikely one of those vulnerabilities would be what a hacker might be interested in the plugin for.

After noticing the probing for the plugin we started looking over the plugin to see if we could find some security issue that a hacker might be interested in exploiting. Seeing as the other two plugins had security issues connected to PHP object injection that was obviously an issue to check for, but it would be anyway due to how often type of vulnerability is being exploited in plugins these days.

We found one instance of the unserialize() function, which is a critical piece of PHP object injection, in the plugin. In the file /app/models/PrliOptions.ph the function get_options() will pass the value of the WordPress option “prli_options” through that function:

public static function get_options() {
  $prli_options = get_option('prli_options');
  if($prli_options) {
      $prli_options = unserialize($prli_options);

In looking over the plugin we couldn’t find any way for an attacker to get a value need to cause PHP object injection in to that option. Maybe someone else will see something we missed, though.

As we were looking into how saving of the plugin’s options was handled, as that is what is stored in the WordPress option “prli_options”, we found that plugin had multiple security issues. The protection against cross-site request forgery (CSRF), which allows an attacker from causing someone to take an action they didn’t intend, is only partially implemented in some locations. On at least the Options page and Add Pretty Link pages in the admin area of the plugin there is nonce included with requests to make changes, but the code that makes the changes doesn’t check if it is included or that it is valid. That makes it appear the protection is in place without actually doing anything. We also found that the Options page has a reflected cross-site scripting (XSS) vulnerability that is separate from the two previously disclosed ones.

While those things sound concerning, the threat from them on the average website is likely very small to non-existent, so they would be highly unlikely to be what a hacker might be interested in exploiting.

A problem caused by a plugin being so inseucres is that it makes it harder to zero in what a hacker might be interested in, since there so many paths you could follow looking for that.

One of the other areas we took a look at, since it frequently a source of security issues, is handling of plugin functions accessible through WordPress’ AJAX functionality. Not surprisingly there are security issues with those as well, starting with the fact that a number of them don’t included restriction on who can access them beyond limiting access to them to those logged in WordPress.

Normally the popularity of a plugin makes little difference in whether a hacker will target a vulnerability in it, instead what seems to be the main determination is the type of vulnerability. We suspect that some of that might be due to not all hackers being aware that you can see how popular plugins that are in the Plugin Directory are. An exception to lack of importance of the popularity of plugins is for vulnerabilities that require the attacker to be logged in to WordPress to exploit, often referred to as authenticated vulnerabilities. It isn’t clear what level of usage would be enough for hackers to try to exploit that type of issue, but last year that occurred with a plugin with 100,000+ active installations at the time. This plugin has 200,000+ active installations, so it would seem to be reasonable to believe that a hacker might target a vulnerability that is only accessible to those logged in.

Popularity Doesn’t Equal Security

Before we get to into AJAX accessible functionality that hackers might be interested in targeting, it’s worth taking a moment to take in the fact that a plugin with 200,000+ active installations contain numerous security vulnerabilities. That is out of line what you likely would believe if you were to listen to security advice on WordPress plugins, even from security companies. For example, just last month Wordfence wrote a post titled “Ask Wordfence: How to Limit Security Risks From Plugins” with this information on choosing “reputable plugins”:

Choose Reputable Plugins

The WordPress.org plugin directory makes it really easy to evaluate plugins by providing a nice summary that gives you almost everything you need. Here’s what we suggest you pay attention to:

  • The more recent the last update, the better.
  • Check the number of active installs the plugin has. Some reliable and useful plugins have low install numbers, but you should still examine a plugin carefully if it has a low install base (below 1,000 active installs). It may not be maintained.
  • It should be compatible with the current version of WordPress, though please note that immediately after a WordPress core release, a lot of reputable plugins will show a “Test up to:” value that is behind, as authors finish testing their plugin with the latest WordPress version.
  • The average plugin rating should be high enough to instill confidence. The higher the rating, the better, obviously.

You should also periodically review your installed plugins to make sure they have maintained their good standing.

The number of active installs just indicates that something is popular, not that is reputable or otherwise secure (considering that Wordfence Security is the most popular WordPress security plugin, the company behind may have a vested interested in believing that popularity is an indication of things it isn’t). In the case of Pretty Links, it would seem to fit all of Wordfence’s criteria:

Those criteria are just not all that meaningful from a security perspective, something you would hope the maker the maker of the most popular WordPress plugin to know. That they are handing out advice on something that they don’t understand speaks the really poor state of security surrounding WordPress, especially the poor state of security companies.

Authenticated Short Link Creation

In looking over the functions available through AJAX, one immediately stood out to us a something that a hacker might be interested in. That being the function to create a pretty link, which is the plugin’s name for a short link:

add_action('wp_ajax_prli_create_pretty_link', array($this, 'create_pretty_link'));

That function, located in the file /app/controllers/PrliPostsController.php, doesn’t contain any restrictions on who can create those new short links:

public function create_pretty_link() {
  $valid_vars = array('target', 'slug', 'redirect', 'nofollow', 'tracking');
  if(!isset($_POST) || !($valid_vars == array_intersect($valid_vars, array_keys($_POST)))) {
    echo "invalid_inputs";
  //Using the local API Yo
  $id = prli_create_pretty_link(
          '', //Name
          '', //Desc
          0, //Group ID
          (int)($_POST['tracking'] == 'enabled'),
          (int)($_POST['nofollow'] == 'enabled'),
  if((int)$id > 0) {
    echo "true";
  echo "link_failed_to_create";

By comparison, the admin page for creating a new one is restricted to Administrator users (in the file /app/controllers/PrliAppController.php):

$role = 'administrator';
$prli_add_links_menu_hook = add_submenu_page(
  __('Pretty Links | Add New Link', 'pretty-link'),
  __('Add New Link', 'pretty-link'),
  $role, 'add-new-pretty-link',

What access to that function means in simpler terms is that if a website allows public to create WordPress accounts, whether directly through WordPress or through a plugin, they can then create new short links. As an example of that, if your website was example.com and someone used the proof of concept at the end of the post, visiting http://example.com/pluginvulns would redirect to our website’s homepage.

So what would a hacker be interested in that for? A quick perusal of the Google search results for “spammers abuse URL shorteners” shows that they use those with spam since the website being linked to disguises the final destination.

Due to the fact that the developer still hasn’t fixed the previous issue we notified of them in the plugin we are not notifying them of this issue or the other issues we ran across at this time. Someone else is welcome to do that, though.

We would say that this plugin is really in need of a security review, but considering the developer isn’t addressing in a timely manner previously disclosed security issues, it seems like the time, effort, and or cost of doing that might be wasted.

If you see some other issue that hacker would target in this plugin, we would love to hear about it.

Wider Warning

Due to the fact that this issue or something else might be being targeted by hackers we are adding the vulnerability to the free data that comes with our service’s companion plugin, so that even those not using our service yet can be warned if they are using the plugin.

Proof of Concept

The following proof of concept will create a short link that redirects from /pluginvulns to our website’s homepage, when logged in to WordPress.

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

<form action="http://[path to WordPress]/wp-admin/admin-ajax.php" method="POST">
<input type="hidden" name="action" value="prli_create_pretty_link" />
<input type="hidden" name="target" value="https://www.pluginvulnerabilities.com" />
<input type="hidden" name="slug" value="pluginvulns" />
<input type="hidden" name="tracking" value="true" />
<input type="hidden" name="nofollow" value="true" />
<input type="hidden" name="redirect" value="301" />
<input type="submit" value="Submit" />
17 Nov

Wordfence’s Idea of Keeping “site owners safe from exploitation” Actually Puts Them At Risk

When it comes to improving the poor state of security, what can be seen over and over is that the focus needs to be on the basics. Take for instance the widely covered breach of Equifax, which was a situation where simply keeping their software up to date would have prevented the breach from happening. But the security industry isn’t focused on that and doesn’t seem to ever consider that what they are doing is far too often part of the problem, even when it impacts them.

That type of issue applies with WordPress plugins, where many hacks involve exploitation of vulnerabilities that have already been fixed. So what is probably going to provide you better protection then any security product or service would be to simply keep your plugins update at all times (many of the security plugins don’t seem to provide any protection against those vulnerabilities), which can be done with things like our Automatic Plugin Updates plugin. But telling you that doesn’t help the security industry to sell their products and services, so you don’t often here that from them.

As example let’s take a look at a post from yesterday from Wordfence about vulnerabilities in several plugins, which ends:

We encourage you to share these vulnerabilities with the larger WordPress community to help keep site owners safe from exploitation.

If you read through the rest of the post they don’t ever say that you should be keeping your plugins up to date at all times, which is actually the best advice when it comes to the vulnerabilities mentioned there. Instead they tell you the plugins they are mentioning now should be updated “immediately”, which for one of the plugins is well after a hacker had started trying to exploit one of the vulnerabilities that had been in it. The three plugins they mention are far from the only recent updated plugins that had updates that fixed security vulnerabilities, so only mentioning that people should update those isn’t all that helpful.

The rest of the post is like so much from Wordfence, mainly an ad for their services, which seems to be the real reason they want people to share it. As well get to in a moment one of the vulnerabilities in the plugins they mention is an example of the poor quality of what Wordfence paid service provides over doing the basics and the post shows again that Wordfence has very limited security knowledge, despite claims to the contrary.

A Week Behind

A week ago Thursday we discussed the details of a vulnerability that had been fixed in Formidable Forms, after Robert Mathews disclosure that it was being used to exploit vulnerability in another plugin (it is probably worth another post discussing how it was being exploited after it was fixed but before the discoverer had disclosed it). Since it was being exploited, we also added the vulnerability to the free data that comes with the companion plugin for our service, so that anyone that hadn’t updated the plugin already could have been warned about the issue last Thursday if they used our plugin. The update that fixed the vulnerability had been released a couple weeks before all that happened.

According Wordfence’s post they only got around to adding to protection against that to their paid service yesterday:

We released a firewall rule today, protecting Wordfence Premium customers from attempts to exploit this vulnerability.

That paid service is promoted by the claim that Wordfence has “unmatched access to information about how hackers compromise sites”. We would love to hear how Wordfence would try to justify that claim when they are a week behind the information that someone simply following our blog would have. That is far from the first time they have been well behind our blog, in another instances they only became aware of a vulnerability that was already being exploited because we were “making some noise about it” on this blog.

That was not the only thing that points to Wordfence not having the expertise they promote themselves as having (they claim to have a “large team dedicated exclusively to WordPress security”), take their mention of the vulnerability:

  • A preview function allowed unauthenticated users to execute an arbitrary shortcode. Normally, the use of shortcodes is restricted to site authors or administrators, as many of them could be used to exploit a site.

If they had simply read another recent post of ours they would have known that normally any one logged in to WordPress can access shortcodes, not just “site authors or administrators”:

In that access had not been there, then the vulnerability wouldn’t have existed, as those logged in to WordPress are already allowed to execute shortcodes through AJAX.

A Lack of Due Diligence or Worse

For another one of the vulnerabilities mentioned by Wordfence, they either didn’t do any due diligence or they don’t understand an even more basics element of web security:

WPVulnDB also reports that the Duplicator, running on over 1 million active sites, fixed a stored cross site scripting vulnerability affecting versions 1.2.28 and older. This report also included the code changes.

For some reason Wordfence didn’t actually link to the report on the vulnerability or credit the discoverer Ricardo Sanchez (though they managed to link to another page on their own website in that). If you look at that report you would not see any mention that this is a stored (or as we refer to them, persistent) cross-site scripting (XSS) issue, instead it indicates that it is a reflected XSS:

The XSS reflected because the values are not filter correctly:

The security implications of those two types of vulnerabilities are very different, so you would hope anyone in the security industry that provides a service related to dealing with them understands the difference.

It is possible that Wordfence doesn’t understand what they are talking about here (considering they link to changes in the code that don’t show the vulnerability they claimed), but a simpler explanation is that they just repeated the labeling of it by the WPScan Vulnerability Database:

That would be a bad idea as their data is well known to have accuracy issues, one of them lead to Wordfence recently falsely claim that the current version of a plugin contained a vulnerability that had been fixed six years ago. Does Wordfence with their “large team dedicated exclusively to WordPress security” not know this or do they not care enough to make sure they are presenting accurate information to their customers and the wider public?

A Paid Service That Really Helps

While Wordfence just got around to mentioning to people about Duplicator’s vulnerability yesterday we started notifying our customers about the issue last week when it was originally disclosed and before it was fixed. We also notified the developer that this unfixed vulnerability had been disclosed. That type of notification is something that we frequently do (we seem to be about the only ones) and can lead to unfixed vulnerabilities getting fixed within hours, which helps to protect everyone, not just our customers.

That is far from the only thing we do that others don’t, that helps everyone, one of the other things that we do that we have seen no evidence that anyone else does is that we monitor changes being made to plugins in the Plugin Directory to detect serious vulnerabilities.

Help Site Owners by Getting the Word out on Wordfence

This isn’t the first time Wordfence has put out type of post that is less focused on helping protect websites, than on marketing Wordfence. In other cases their posts are worse because they lie about what are security threats against WordPress and lead people believe that WordPress is insecure in ways it isn’t or they focus on making people reliant on them instead of actually improving WordPress, which would lead to  everyone being better protected then they would be by Wordfence.

Even worse they falsely promote their plugin with an unqualified claim that it “stops you from getting hacked”, despite them knowing this isn’t true. If the WordPress community would get involved in warning others about security companies that are so obviously dishonest, we think it would go a long way to helping to protect the public from companies like Wordfence that have shown they don’t have even their own customers best interest at heart, much less that of the larger WordPress community.

10 Nov

Don’t Assume Wordfence Premium (or Similar Services) Will Protect Your Website

We were recently looking back at some of our messages on the WordPress Support Forum in relation to some posts we have been writing related to the terrible moderation of that forum. In one of the topics we had started, there were a few things that we noticed that we thought were worth discussing as they relate to other things we have been looking at recently.

Eight months ago we had created a topic on the forum of a plugin, letting people know that there were some unfixed minor security issues in the plugin:

This plugin was recently selected by our customers to have a security review done by us. While there were no issues that were likely to lead to the average website being hacked found, we did find a couple of security issues with the plugin. We notified the developer of those, but as of yet they have not been resolved. Seeing as the plugin hasn’t been updated in 10 months, they might not be resolved any time soon.

After a moderator told us that we should email the Plugin Directory about this, we explained that the issues didn’t rise to the level that they would take action and therefore there wasn’t a use for doing that. In a reply to that, the head of the Plugin Directory responded:

I’m not sure what the issue is here, but we have always read, reviewed, and replied to your very welcome reports of plugin issues.

We clearly have a different view of what should be the focus of the people running the Plugin Directory, as we have never notified them in hopes they would do any of those things, but to take the action only they can take, removing the plugin until it is fixed (though we would expect they would we read and review the details of the issue before doing that). As removing unfixed plugins prevents anyone else from starting to use a known vulnerable plugin.

Due to WordPress’ continued poor handling of security we suspended notifying of them of vulnerable plugins in the Plugin Directory back in June, which has lead to there currently being plugins with over 2.3 million active installations that are known to be vulnerable that have remained in the Plugin Directory (if you were using our service and one of those plugins you would already been notified that your website contains a vulnerable plugin).

The most recent reply in the topic gets to something we have recently been thinking about more, which is when information about security issues, whether confirmed or possible, in plugins are being inaccurately cited. That is a concern with our new tool for check possible security issue in plugins, as based on past experience, we could easily see misuse of the results and we don’t want plugin developers having to deal with more inaccurate information on the security of their plugins.

Here is all but the last sentence of the reply (we will get to that sentence in a moment):

I can verify that there are serious problems with this plug-in. My hosting provider recently suspended my account temporarily because I was generating spam. We traced the problem to this particular plug-in.

We had not claimed there were serious problems with the plugin and the issues we found don’t seem like they could have lead to the issue this person had (or really had any chance of being exploited on the average website). Based on our past experience we would guess that the hacker just happened to place the malicious code in a file in the plugin’s directory, as we mentioned recently web hosts often incorrectly claim that wherever they find a malicious file is the source of the hack.

Unsupported Belief of Protection Provided by Wordfence

The final sentence of the reply is:

This problem occurred despite the fact that I had WordFence premium installed on the site.

It easy to understand why this person would have assumed that the Wordfence Premium paid service should have protected them, since Wordfence claims that just their free plugin Wordfence Security “stops you from getting hacked”. Until a week ago that claim was the second sentence in the description of the plugin in the Plugin Directory and it now exist in a FAQ answer on the page:

How does Wordfence Security protect sites from attackers?

The WordPress security plugin provides the best protection available for your website. Powered by the constantly updated Threat Defense Feed, WordFence Firewall stops you from getting hacked. Wordfence Scan leverages the same proprietary feed, alerting you quickly in the event your site is compromised. The Live Traffic view gives you real-time visibility into traffic and hack attempts on your website. A deep set of additional tools round out the most comprehensive WordPress security solution available.

That unqualified claim is a lie and Wordfence knows it (and the lie is something the public does believe, contrary to people trying to excuse Wordfence’s behavior will tell you). The reality is that a WordPress plugin cannot stop certain types of hacks from happening, including server level breaches and compromise of FTP logins. That the most popular WordPress security plugin has been prominently promoted with a blatant lie, is a good indication how bad things are currently when it comes to the WordPress security industry. Though it certainly isn’t alone, as the second most popular uses a false claim to collect users’ email addresses and one of the developers of third most popular thinks it is normal for security plugins to be insecure.

Considering that trust is an important part of security, any dishonesty from a security company seems like it should be something that leads to people avoiding doing business with them. So far it hasn’t though, but if it did, it would impact many more companies than just Wordfence.

Wordfence plugin and service can’t stop a lot of hacks for basic technical reasons, but even for the types of things that they should be able to protect against they don’t present evidence, much less evidence from independent testing, that they are effective against those hacks. The testing we have done in the past showed their plugin either didn’t protect against threats or the protection was easily evaded (that was one of the best results among the plugins we tested). So results from independent testing really are necessary before any claims are made as to the protection it provides (whether coming from Wordfence or from others).

We have had plenty of people come to us after using services that claimed to protect websites that failed to do that and everything we have seen about those services is that the claims being made are unlikely to match what the companies have the capability to provide. So you really should avoid any service that makes claims like that unless they are presenting evidence from independent testing that they are effective at protecting websites. We have yet to see any that provide that, which also probably is a good indication of those services limited ability to provide protection, as either the providers don’t know if they effective or not, or they know they are not.

You Can See What We Are Doing

With our service we don’t claim that we are going to stop your website from being hacked, only that we will help to protect you from security vulnerabilities in WordPress plugins. Being honest isn’t great for business, since so many security companies have no qualms about outright lying, but we actually care about security and being honest.

With our service you don’t have to guess if we are really providing you with anything of value as we currently put out a monthly post detailing most of what we have done during the month. That way people can compare what we are doing versus other providers, and we even sometimes provide public comparisons. We don’t just do that type of comparison for marketing purposes, but so that we can make sure that we are providing the best service possible.

One of the areas that we provide you better protection than services that make overstated claims about what they provides is that instead of simply trying to stop a vulnerability from being exploited we proactively monitor changes made to plugins to try to catch serious vulnerabilities as they are added to plugins (something we could expand to less serious issues if we had more customers) and we provide the ability for paying customers to suggest/vote for plugins to get reviews, so you can get a determination if a plugin is secure or not (and hopefully we can then work with the developers to fix any issues), before a hacker might start exploiting it. We also continue look at ways to improve the detection of vulnerabilities, including our recently introduced tool for doing some limited automated security checks of plugins and our plugin for making it easier to confirm the existence of the very serious PHP object injection vulnerabilities, which has been cited in the discovery of a couple of those vulnerabilities by others.

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:

Status New

It has unpatched security issues and may have compatibility problems with the current version of WordPress. Get more information.

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.)

06 Oct

Wordfence Doesn’t Want You to Know We Discovered the Vulnerability in Postman SMTP

We have seen a lot sleazy stuff out of the WordPress focused security company Wordfence, including claiming that they care more about security than the WordPress team as justification for creating a fake threat, so it shouldn’t be surprising to find their post about the removal of the plugin Postman SMTP from the Plugin Directory, which people assume is due to a reflected cross-site scripting (XSS) vulnerability we discovered, doesn’t mention us or link to our post despite being about the only substantive thing mentioned in their post. They clearly are aware of who the source was as the second paragraph clearly references our post:

On June 29, an unnamed security researcher published the details of the vulnerability, including a proof of concept. A proof of concept is a demonstration that shows the plugin author (and in this case the entire internet, including potential attackers) how to exploit the security vulnerability. The security researcher had apparently attempted to reach the author but had been unable to.

It is worth noting that here that this type of vulnerability is highly unlikely to be exploited on the average website (contrary to a recent claim by Wordfence that this type of  vulnerability “will be exploited by attackers“) and the proof of concept included just reiterates what is already mentioned in detailing the vulnerability, so someone that would be exploiting this type of vulnerability shouldn’t have a problem without it. Someone looking to do a targeted attack against a website using this plugin, likely could have easily found this vulnerability on their own (and who knows, they might already have).

One of the reasons we include a proof of concept on how to exploit vulnerabilities is so that others can double check our work, as among other things we often find that vulnerabilities that are being disclosed and claimed to be fixed, haven’t actually been. If there is a proof of concept it is easier to catch that vulnerability hasn’t been fixed and then we can work with the developer to get it fixed (and usually in that situation it can be fixed very fast). It also helps to check if there are other related vulnerabilities that have been missed, as has been the case with Wordfence’s discovered vulnerabilities in the past (or more recently them missing that vulnerable code still was in a plugin, though not accessible). There also was the situation where they told people to update the plugin despite the vulnerability having existed in the most recent version of it.

It is also important to note that all major web browsers other than Firefox have XSS filtering to protect against this type of vulnerability for years, which is likely plays an important role in it not being likely to be exploited.

When we have discussed things that Wordfence has written we have properly credited them.

Advertising Over Improving Security

We wouldn’t mind them not mentioning us if they had finally decided to actually help the effort to get WordPress to properly handle removed plugins, since that is so important. Instead their post is mostly just an ad for their plugin and service, which both leave people not knowing why plugins are removed.

Wordfence clearly understands there is an issue with people not knowing why plugins are removed as the first paragraph of their posts states:

We have received a number of questions regarding the Postman SMTP plugin which was removed from the WordPress.org directory this week.

We assume it was removed because it contains a publicly known reflected cross-site scripting (XSS) vulnerability that has not been fixed.

And later they write:

Since they don’t publicly announce that plugins have been removed, nor why, it is prudent for site owners to treat the plugin as a potential security risk and take reasonable precautions.

They didn’t write anything about doing anything to resolve that situation, which is easily resolvable if WordPress wanted to take action, but here is all the advertising they had time to include in the post instead:

Both Wordfence Free and Premium users who have the firewall enabled have been protected against attempts to exploit this vulnerability from day one. In addition, we alerted all Wordfence users who have the plugin installed when it was removed from the plugin directory.

It should be noted they didn’t provide any evidence that their plugin actually can protect against this type of vulnerability (or for that matter do they provide evidence that it does for other types and our testing hasn’t shown it to provide much protection). As we mentioned before the major web browsers other than Firefox provide protection against this type of vulnerability as well, something Wordfence didn’t note.

Wordfence Firewall Includes Robust XSS Protection

The Wordfence firewall includes protection against new and emerging XSS attacks. Both Wordfence free and Premium users have been protected against this attack since (and before) it was made public. This is a great example of why using a firewall to protect your website is so important: you are immediately protected against most new threats.

In cases where we don’t already protect against a new threat, we develop a new firewall rule, deploying it to our Premium customers in real-time and free customers 30 days later. This ‘virtual patching’ by our security analysts and developers keeps your sites safe.

Wordfence Alerts You When Plugins Are Removed From WordPress.org

When plugins you have installed on your site are removed from WordPress.org, Wordfence alerts you. There is a long list of reasons why the plugin team at WordPress.org might remove a plugin from the directory. One common reason is that someone has discovered a security vulnerability that has not yet been fixed. Since they don’t publicly announce that plugins have been removed, nor why, it is prudent for site owners to treat the plugin as a potential security risk and take reasonable precautions.


If you haven’t already, we suggest that you install Wordfence on all of your WordPress websites. It will alert you when your plugins have been abandoned or removed from the the WordPress directory. Its firewall will also protect you against new and emerging attacks.

Finally, consider upgrading to Wordfence Premium if you haven’t already. The real-time firewall rule updates will protect you from the latest threats. In addition, the real-time IP blacklist will stop all attacks from the most malicious IPs, regardless of what they’re up to.

Our Advertising

Since Wordfence is going to use a vulnerability we discovered to advertise their service so garishly, we will quickly plug our service, which would have not only warned you about the vulnerability in you were using the plugin back when it was disclosed in June, but we would have also have been available to help you make the best decision as to deal with.

The more customers we have the more we are able to improve the security of WordPress plugins for everyone using them. While this vulnerability has gone unfixed, this week we help get vulnerabilities fixed in plugins with 140,200+ active installs and we have contacted developers of plugins with another 500,000+ active installs about vulnerabilities in them that need to be fixed.

Fixing the Vulnerability

As we said before the vulnerability isn’t something that is a big concern, so it wouldn’t be a big risk to keep using the plugin in its current form, but fixing the vulnerability is easy.

On line 346 of the file /Postman/Postman-Email-Log/PostmanEmailLogController.php in the plugin replace this line:

value="<?php echo $_REQUEST['page'] ?>" />


value="<?php echo esc_attr($_REQUEST['page']) ?>" />

The esc_attr() added will escaping the value, which prevents the possibility of reflected cross-site scripting (XSS).

03 Oct

Wordfence Still Being Irresponsible When It Comes To Disclosing Vulnerabilities

On September 22, we discussed a PHP object injection vulnerability that had been fixed in the plugin Appointments, which we had spotted being fixed due to the proactive monitoring of changes made to plugins to try to catch serious vulnerabilities. What was somewhat concerning about the handling of the vulnerability was that the vulnerable code still was in the plugin, though not accessible through it anymore. What had happened is the code originally was contained in one file and then that file’s contents were split among several files, but the old file was never removed. After we notified the developer, that file was removed, but the version number wasn’t changed so those already running 2.2.2 still have the code.

Two companies with a security focus had missed the code was still in the plugin, the developer of the plugin, WPMU DEV, and the discoverer of the vulnerability, Wordfence. That is a good reminder of why providing the details of vulnerabilities that has been fixed is important because even security companies can miss issues related to a vulnerability. That has been the case in multiple instances with the few vulnerabilities that Wordfence has disclosed in the past, including a situation where they told people to update the plugin despite the vulnerability having existed in the most recent version of it. Making those instances more problematic was that Wordfence failed to provide the details that would have easily allowed someone else to check to make sure everything had been properly resolved. Only because we did the work to figure details of those vulnerabilities were we able to spot and help get some additional related vulnerabilities fixed in some of the plugins.

In the post on that vulnerability in Appointments we wondered if Wordfence would handle the situation better, if and when they mentioned that vulnerability:

 If they release information on this vulnerability, it will be interesting to see if they handle things better than they did last year.

We now have the answer, they didn’t. They release a post on it and couple of apparent PHP object injection vulnerabilities yesterday and it lacks the details that would have allowed someone to easily see that the same code existed elsewhere in the plugin. Since a PHP object injection vulnerability requires more than just knowing about the vulnerability (you need to be aware of code that can be accessed through the vulnerability), providing more details wouldn’t likely to have done little to increase the risk from disclosing more details.

Considering they are claiming all three vulnerabilities are zero-day vulnerabilities, which are vulnerabilities being exploited before the developer becomes aware of them, some hackers would already be aware of how to exploit them, further reducing the additional risk caused by doing that.

In that past Wordfence has referred to any vulnerability they discovered as a zero-day vulnerability and the post lacks details that would make it clear these all were really zero-day vulnerabilities, so the claim of them all being zero-days seem a bit questionable (though PHP object injection vulnerability are highly likely to be exploited).

The Missing Details Could Be Useful

For one of the other vulnerabilities, in the plugin Flickr Gallery, we also spotted it being fixed through our proactive monitoring. What isn’t mentioned in Wordfence’s post or further discussion of that post is a note added to that plugin alongside the fix for the vulnerability:

This plugin is deprecated, please remove it from your WordPress install.

With the third plugin we didn’t notice a PHP object injection being fixed in it at the time and in looking at the changes so far we haven’t figured out where there would have been a PHP object injection fixed. That vulnerability is supposed to have been fixed in version of the plugin RegistrationMagic-Custom Registration Forms.

In looking over the changes made in that version the only change that directly involves code that could be involved in PHP object injection looks like this in version (in the file /includes/class_rm_dbmanager.php):

$result = maybe_unserialize($wpdb-&gt;get_var("Select form_options FROM `$table_name` where `$primary_key` = $form_id"));

In the code has been changed to use a prepared statement in the SQL query in it:

$result = maybe_unserialize($wpdb-&gt;get_var($wpdb-&gt;prepare("Select form_options FROM `$table_name` where `$primary_key` = %d",$form_id)));

There isn’t an obvious way that would prevent a PHP object injection vulnerability.

The rest of the changes mainly involve using prepared statements for SQL queries and adding a missing function.

As of version there look to be 61 usage of the maybe_unserialize(), so it could be the change made in that version impacts code elsewhere that would have lead to PHP object injection. We are going to have to look closer at the rest of the code to try to figure out what is going on. If you have figured it out, please let us know.

Knowing where a PHP object injection would have been fixed there is important because it could help to get other vulnerabilities fixed, since it would make it more likely that others could spot similar vulnerabilities. For example, the way we noticed the other two vulnerabilities being fixed also led to us identifying 9 unfixed vulnerabilities related to PHP object injection that we disclosed just last month (we noticed additional ones through other methods):

26 Sep

Wordfence Falsely Claims Current Version of Removed Plugin Contains Vulnerability That Was Fixed Over Six Years Ago

A couple of weeks ago we noted that Wordfence was trying to make people reliant on their plugin instead of helping everyone in the WordPress community by getting behind the effort for WordPress to start alerting when websites are using plugins that have been removed from the Plugin Directory. One of the reasons we noted as to why what they were doing was problematic even for those using their plugins, is that the people on the WordPress side of things know why plugins are removed and could let people know why, while Wordfence can’t. It turns out though that Wordfence will present things in way that leads to people to believe otherwise, while in the case of at least one plugin, presenting incredibly inaccurate information about the security of it.

Through monitoring of the WordPress Support Forum we do to keep track of vulnerabilities in WordPress plugins, we came across the thread about the plugin Sermon Browser, which has been removed from the Plugin Directory. The original poster in thread wrote:

I just received a “Critical” security notice from my website last week. It stated that the plugin was removed from the WordPress repository because of critical security issue. Apparently a SQL injection vulnerability has been identified.

I am sure the owner was notified of the removal. But I would expect a “sticky” post or an update or something. Has anybody else heard of any response to this?

Below that was the message from Wordfence:

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

Severity: Critical

Vulnerability Information:

Status New

It has unpatched security issues and may have compatibility problems with the current version of WordPress. Get more information.

Following the link to the entry on the WPScan Vulnerability Database in that message brings up this page:

The most important things to note in that is the vulnerability is not labeled as being fixed and the dates, the listing was added on “2014-08-01″ and last updated ” 2015-05-15″. From that page you can get the actual information on the vulnerability.

In looking over things we found that the vulnerability was actually fixed the same day it was disclosed, back on April 26, 2011.

That the information in the WPScan Vulnerability Database isn’t accurate isn’t a surprise. It was just back in June that we discussed their inaccurately label an unfixed vulnerability as being fixed. In April we noted another instance where they labeled fixed plugins as not being fixed. We could go because there are plenty of instances we have discussed on this blog, which certainly are not all of them.

WPScan’s accuracy issues are only part of the problem here, as Wordfence is choosing to further spread the inaccurate information. Either they haven’t done any due diligence at all on their data source on plugin vulnerabilities, which would not put them in a good light, or what seems more likely, they know and don’t care. It’s not like no one has pointed out the problem with Wordfence using that data before, we did that back in May. The other option Wordfence could use is to check the information to make sure it is correct before passing it along to those using their plugin, but what we have seen repeatedly is they either don’t have the skills to do that sort of thing or are too lazy to do that.

If you are a customer of Wordfence’s you might want stop that since you are giving money to a company that doesn’t seem to have interest in really improving security, but you should at least contact them and let them know they should get behind the effort to get WordPress to properly handle alerting for removed plugins.

If you want accurate data on vulnerabilities in WordPress plugins you can get that with our service or in more limited form with the free data on vulnerabilities that are already being exploited that comes with the companion plugin for our service.

If you are using a plugin that isn’t being supported by the developer anymore, over at our main website we offer a service for taking over abandoned WordPress plugins, which includes doing a security review of it.

22 Sep

Vulnerability Details: PHP Object Injection Vulnerability in Appointments

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.

Since June we have been doing proactive monitoring of changes made to plugins to try to catch serious vulnerabilities. So far that has lead to identifying a couple of dozen vulnerabilities. For the third time it has lead to identifying a PHP object injection vulnerability being fixed in a plugin, this time in the plugin Appointments.

In this instance though what we also noticed was that the new version of the plugin put out to fix the vulnerability still contained the vulnerable code, though it is not accessible through the plugin. What makes that situation stand out is that two companies that put out WordPress security plugins were involved in fixing this vulnerability and appear to have missed that remaining vulnerable code.

In version 2.2.2 of the plugin, two lines that pass the value of cookies to the maybe_unserialize() function, which would have permitted to PHP objection to occur, were removed. They are the following lines in the file /includes/class-app-sessions.php:

$apps = maybe_unserialize( stripslashes( $_COOKIE['wpmudev_appointments'] ) );
$data = maybe_unserialize( stripslashes( $_COOKIE['wpmudev_appointments_userdata'] ) );

Our monitoring picked up their removal, but at the same time that picked up the following two lines in the file being included in the file /includes/class_app_shortcodes.php in that version:

$apps = unserialize( stripslashes( $_COOKIE["wpmudev_appointments"] ) );
$data = unserialize( stripslashes( $_COOKIE["wpmudev_appointments_userdata"] ) );

Those are almost exactly the same as the first two. With the only difference being use of the WordPress function maybe_unserialize() versus the PHP function unserialize() and single quotes versus double quotes.

In looking over the situation we found that the file /includes/class_app_shortcodes.php wasn’t being used, what looks to have happened is that the contents of that file were split in to different files and then that file was never removed.

This risk of that vulnerable code is limited since on its own the file can’t do anything. The risks we could think of is if someone was able to use some other code to cause this file to be loaded or that someone might reuse the vulnerable code from this file. The latter is something we recently saw happen with another plugin, though in that case the code was being utilized in the plugin it was copied from.

When the vulnerability existed in the plugin it was exploitable through several locations, including on pages using several shortcodes.

Security Companies Missed the Remaining Vulnerable Code

Normally a developer missing other instances where vulnerable code is still in the plugin isn’t something that we would be too concerned about, but in this case the developer is WPMU DEV, which also makes the Defender security plugin. We would expect that a company that provides a security plugin to be more careful about the security of their plugins.

In a look over how they promote that security plugin we didn’t get the feeling that they really have the level of concern for security that they should have when producing a security plugin. No where do they present any evidence of the effectiveness of the plugin overall or the effectiveness of its various features. One area where we know that what they are providing has limitations, is their checking for known vulnerabilities in plugins, as the source of plugin vulnerability data is WPScan Vulnerability Database, which has serious limitations, as we have discussed in previous posts. They really should be disclosing the source of the data in the marketing material and making it clear that the data they provide has serious limitations.

Something else that stuck out to us in how the plugin is promoted is this:

Brute force attacks are no match for Defender. Limit login attempts to stop users trying to guess passwords. Permanently ban IPs or trigger a timed lockout after a set number of failed login attempts.

Brute force attacks against WordPress admin passwords are not happening, what is happening, dictionary attacks, can be prevented by simply using a strong password, which WordPress does a good job of helping to people use. Protections meant to protect against brute force attacks would not always be effective against dictionary attacks and can lead to unnecessary complications.

In the changelog for version 2.2.2, one the entries seemed to be possibly referring to this vulnerability:

  • Fixed security issue (vulnerability) with data stored on a browser. Thanks to Matt Barry @ Wordfence

When we contacted the developer of the plugin about the remaining vulnerable code, they confirmed that did in fact refer to this vulnerability.

That Wordfence missed the remaining vulnerable code isn’t all that surprising based on their track record. Last year they disclosed several vulnerabilities in plugins and we found that three related vulnerabilities had not been fixed. The problem then wasn’t as much that they missed them, but that they were not providing the normal level of detail on the vulnerabilities they found that would have allowed someone to check things over and spot those related issues easily. Their providing limited details was not due to a concern about that being misused, but so they could market that they provided protection against the vulnerabilities that other firewall providers did not. In explaining why they were handling things they way they did they claimed that “At Wordfence the security of our customers and the greater WordPress community is of paramount importance to us.”,  which seems untrue when you consider that it was only because we figured out the details they didn’t provide that we could work to get the other vulnerabilities fixed. If they release information on this vulnerability, it will be interesting to see if they handle things better than they did last year.

File Removed

After we notified the developer of the remaining issue, the file /includes/class_app_shortcodes.php was removed. If you already updated to version 2.2.2 though you will still have the file. In normal circumstances that is harmless, but if you want to be extra careful you could delete the file or reinstall the plugin to get rid of the file.

Proof of Concept

With our plugin for testing for PHP object injection installed and activated, set the value of the cookie “wpmudev_appointments_userdata” to “O:20:”php_object_injection”:0:{}” and then when you visit a page with the shortcode “app_confirmation” (with a “title” attribute) the message “PHP object injection has occurred.” will be shown.

15 Sep

Wordfence Security Causing Full Path Disclosure Security Issue on Some Websites

Earlier this week we mentioned our concern over Wordfence promoting being reliant on their plugin instead of getting behind an effort to make WordPress more secure for everyone that uses it. We also noted that the average WordPress website shouldn’t even need a security plugin if security of WordPress was being handled properly, which should be the goal. The most important reason that the average WordPress websites shouldn’t need a security plugin is because WordPress should be secure out of the box for most usage of it, but there are additional reasons. One other reason is that security plugins, as is true of any plugin, can introduce security issues of their own, so if you add one (or more than one) you are introducing additional risk.

That isn’t a theoretical threat, last year we found that a security vulnerability in the current version of security plugin was being exploited. We recently disclosed that there is a PHP object injection vulnerability, which is a type of vulnerability that has been widely exploited in WordPress plugins, in the current version of another security plugin.

As part of our monitoring the WordPress Support Forum for information on vulnerabilities in plugins we came across a mention of a less serious issue that involves the most popular security plugin, Wordfence Security.

A forum poster by the name of David wrote:

See: https://www.exploit-db.com/ghdb/4544/

By default a user.ini file is created and contains the root path of the site on the server. This could allow hackers to more easily attempt a directory traversal type attack.

We checked and confirmed that there are websites where the full path for the website is disclosed in that file in a line added it to by Wordfence Security. The linked page includes a Google Dork for searching for impacted websites. Using that we got 13 pages of results (with up to 10 results per page) and with omitted results included 24 pages. Since Google could only show files where they somehow found a link to the file, there are probably many more websites where this file is viewable.

The full path alone won’t allow you to hack a website, but it could assist in some types of attacks. For example, certain vulnerabilities require knowing the full path to a file to take an action with the file, so the full path would assist in exploiting that. Also, for cPanel based websites the path contains the cPanel username, which could assist an attacker in certain instances, say if someone uses the same password across various websites.

What concerned us more was part of the response from a WordPress Wordfence representative:

The .user.ini file is created during the Firewall Optimization process. At the same time as the .user.ini is created code is added in .htaccess which prevents access to the .user.ini.

WordPress is supported on web servers that don’t use .htaccess files, which is something a company focused on WordPress security should know. But in reviewing things we found that Wordfence is aware of this. Looking over the plugin’s code, it has a warning for NGINX users that they should add code to the nginx.conf file to prevent the file in question from being viewable. We didn’t see anything similar for IIS in the code, but that is not officially supported by Wordfence.

In looking over the first 20 results in Google for the Google Dork provided in the link in the first message, we found that 11 of the websites were on NGINX servers, 7 on Apache HTTP servers, and 2 were on servers that were not accessible. Considering that NGINX is used on less websites than Apache HTTP server that seems to indicate that some of the issue is caused by people not adding the code to the nginx.conf file.

If you are using Wordfence Security you can easily check if you are impacted by this by requesting the file .user.ini at the root of your WordPress installation. So for example, if the homepage of your WordPress installation was at http://www.example.com, you would request http://www.example.com/.user.ini .