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 .