One of the ways we work to make sure we have the best information on vulnerabilities in WordPress plugins for our customers is to monitor the WordPress Support Forum. Through that we came across a couple of threads yesterday that involved exploitation of a vulnerability connected to the plugin Duplicator (and yet another example of the incredibly bad handling of the discussion of security by the moderators of that forum and inability for them to be willing to have a discussion to avoid those problems going forward). In looking closer at the information put out about that we noticed a couple of issues that we thought worth bringing more attention to.

Making it Easier for Hackers to Exploit Vulnerabilities

One issue that we evaluate on an ongoing basis is how we handle disclosure of vulnerabilities, since there isn’t an obvious balance to be struck. On the one hand, more information can make it easier for hackers to exploit vulnerabilities. On the other, we have often found that vulnerabilities are disclosed with a claim that they have been fixed when they only partially been fixed or not fixed at all. In those instances the more information provided makes it easier to determine that there is still an issue and work to get it fixed, before hackers figure that out and take advantage of it.

Sometimes even as a company in the security industry that understands the nuance of the issue it seems as if other security companies are doing things in a way that is intended to make it easier for hackers to exploit websites. A troubling example of that involves a company named Check Point and the Drupal software. Earlier this year there was serious vulnerability that was fixed in the Drupal software and plenty of press coverage of the need to update was provided. For two weeks after the fixed versions were released there was no exploitation of the vulnerability. Exploitation instead started right after Check Point, which was not involved in discovering the vulnerability, had released details on how it could be exploited. Their reason for doing that was explained with the following:

After seeing earlier publications on Twitter and several security blogs, it was apparent that there was much confusion among the community regarding this vulnerability announcement, with some even doubting the severity of it. As a result, we considered it worthwhile to looking deeper into.

The research however was challenging as we were starting from a very large attack surface since the patch blurred the real attack vectors. To expedite our findings, we were fortunate to be joined by experts in the Drupal platform. The final results highlight how easy it is for organization to be exposed through no fault of their own, but rather through the third party platforms they use every day.

What stood out to with that is they claim that it was challenging to figure out how to exploit it, but then how it easy it for someone to be impacted by it, which was due to their own actions, which seems to provide a very different lesson then they claim to be providing.

So why do that? It might be explained by the end of their article:

Check Point customers are protected against such vulnerabilities due to IPS signatures.

When you create a threat without needing to and then tout that you can protect against like that, your intentions seem questionable at best.

Duplicator’s Security Issue Still Exists

With the issue related to Duplicator, what immediately stood out to us in looking at discussion of the issue is by both the discoverers, Synacktiv, and Wordfence, which was released shortly before the wave of exploitations mentioned in the Support Forum and could conceivably have help lead to them, was that they provided a much easier way for hackers to exploit the issue then would be needed for anyone to confirm the issue had existed (and to a large degree still exists).

The vulnerability isn’t too complicated to understand. The plugin generates files for duplicating a WordPress website. After using those files to duplicate the website, files that are part of the duplication are not automatically deleted and those would allow anyone to change the contents of the WordPress configuration file. To us the obvious issue with that would be that someone could set it so that WordPress connects to a remote database and from their hackers could use access to the admin area of WordPress to do almost anything that is possible from the hosting account, say sending spam emails. That isn’t some idea we came up with, that is something that has been publicly discussed at least as far back as 2012.

For some reason though neither Synacktiv or Wordfence stopped with suggesting that was possible, instead they suggested that you could put malicious code right into the WordPress configuration file, which could then easily be run. Synacktiv further provided the exact information needed to do that. That makes it much easier to exploit then if they had just left it at explaining how you could change the database to take control, which would in all likelihood greatly increase the amount of hackers who would have the skills and tools to exploit this.

Making things worse here, the Wordfence post is titled “Duplicator Update Patches Remote Code Execution Flaw”, but that isn’t all that accurate since by default the new set of files generated during duplication still allows changing the database details, it does attempt to limit code execution (though we haven’t tested that out to see if it totally effective), and then use the website to take a variety malicious actions. Strangely the writer of the article portrays it this way:

Even though the user-supplied connection strings are now sanitized before being written to a site’s active wp-config.php file–preventing new code from being introduced and executed–the existing values are still getting replaced by this process. This means if a patched but unprotected installer.php file is found, an attacker has the ability to bring down a site just by supplying incorrect database credentials to the installer.

In reality they can do much worse than bring down the site, it is unclear if the writer didn’t understand the significance despite linking earlier in the post to another Wordfence post describing what actually can be done.

So far we have decided not to include this issue in our data set, since it isn’t a vulnerability that exists in the plugin itself, but in something produced by it. Though we are still mulling if it might make sense to, especially in the light that the issue would still exist to a large degree with the latest version of the plugin.

Wordfence Security Doesn’t Stop You from Being Hacked

In the case of Wordfence they went from describing how to exploit this right to advertisement for their services, that advertisement provides a good reminder of their frequent dishonesty and their willingness to combine that with leaving websites vulnerable to being hacked.

From April of 2016 to October of 2017, several sentences in to the description of the Wordfence Security plugin on wordpress.org was an unqualified claim that it would protect websites from being hacked:

Powered by the constantly updated Threat Defense Feed, our Web Application Firewall stops you from getting hacked.

That was then moved to a FAQ question and continues to be there to this day.

That claim is simply a lie, as a WordPress plugin could not possibly stop websites from being hacked in a blanked fashion. It is possible that they could stop some hacks, though curiously Wordfence doesn’t provide evidence, much less from independent testing, that their plugin is effective at protecting against things it should be possible for it to protect against. We actually did just that type of testing, for which the results were not good, and when we presented the results to the head of the company he didn’t exactly provide a compelling response. And before we get somebody responding that people using the plugin wouldn’t believe that it could provide the level of protection claimed there, they do believe that.

At the same time in the description it was also claimed:

Wordfence Security is 100% free and open source.

Beyond the fact that a plugin can’t protect against a lot of threats, there is the issue that Wordfence intentionally leaves websites vulnerable. Here is part of their ad from the Duplicator post:

At the time of this writing, we have identified a number of malicious actors probing sites for the existence of installer.php and installer-backup.php. If you’ve used Duplicator in the past to migrate a WordPress site, take some time to confirm that any leftover files from the process have been properly removed. Wordfence Premium users will begin receiving alerts from their malware scanner if vulnerable versions of these files are detected on new scans. Additionally, a new rule has been deployed to protect Premium WAF users from exploits of the Remote Code Execution vulnerability discussed above as long as Extended Protection has been enabled. Free users will receive these new rules thirty days from today.

Considering that wide exploitation looks to already be going on, protection in thirty days won’t be much good. Wordfence is a business, so they can leave people vulnerable like this, but they have lead people that what they provide is very different from what it is. Including claiming in the past that “We will always put our customers and the community first.” (how you can put them both first seems like an obvious problem with that statement). It doesn’t have to be this way.  We provide data on vulnerabilities in plugins we see being exploited in the free data that comes with our service’s companion plugin and our focus is on providing paid services for websites that need a higher level of security, instead of trying to getting lots of average websites to purchase a low quality service, while leaving other vulnerable. The problem though is that our plugin currently only has 4,000+ active installs versus Wordfence’s 2+ million. The popularity of their plugin ties into something else worth mentioning here.

The second paragraph of Wordfence’s advertisement states:

As always, if you believe your site has fallen victim to the successful exploitation of an attack like this or any other, please don’t hesitate to contact our team of experts to discuss a site cleaning or security audit.

So they leave websites not paying for their service vulnerable and then they can get people to hire them to clean them up afterwards. How they promote that clean up service seems pretty awful:

As the creators of the most popular WordPress security plugin, we have the most expertise in the industry.

If they had the most popular WordPress security plugin it wouldn’t mean they have the most expertise in the industry, just the most popular plugin. They often have shown a fairly extreme lack of expertise. There need to mislead people like this seems also most pathological. But its worse when you consider their popularity is partly based on a false belief that their plugin would stop website from needing a cleanup in the first place.

Wordfence Security Isn’t The Most Popular WordPress Security Plugin

In line with Wordfence’s many falsehoods and outright lies, not surprisingly it isn’t even true the they have the most popular WordPress security plugin. Instead they are tied with the plugin Limit Login Attempts:

In an indication that the popularity of security plugins isn’t a great measure, consider the fact that plugin hasn’t been updated in years:

In addition to that, the plugin is focused on protecting against brute force attacks against admin passwords, which are not even happening. Not only does Wordfence also tout their plugin also protects against those, they put forth evidence that unbeknownst to them ends up showing that they are not happening (which seems like a good example of their lack of expertise).

With Limit Login attempts there is also the little issue that the current version of the plugin contains a vulnerability.

---

Plugin Security Scorecard Grade for Wordfence Security

Checked on June 12, 2025

See issues causing the plugin to get less than A+ grade