Wordfence Security and Wordfence Premium Fail to Provide Protection Against Possibly Exploited Plugin Vulnerability
The Wordfence Security plugin is promoted with the claim that its firewall stops websites from getting hacked:
Powered by the constantly updated Threat Defense Feed, Wordfence Firewall stops you from getting hacked.
The paid Wordfence Premium service connected with the Wordfence Security plugin is promoted with the claim that it provides “real-time protection”:
If your website is mission-critical you can’t afford the downtime, reputation challenges or SEO impact of getting hacked. That’s why so many sites rely on the real-time protection provided by Wordfence Premium.
Yet the plugin and that service have again failed to provide protection which matches those claims. The latest instance of begins with another security company doing a poor job at security as well.
Sucuri Isn’t Looking For the Source of Hack Despite Offering a Service That is Supposed to Stop Hacks
On November 15, GoDaddy’s web security company Sucuri published a confusing post involving a hacked WordPress website.
The post referred to a “bogus” plugin:
It was a simple HTML page generated by this bogus plugin and nothing more.
Yet later in the post, the same plugin is referred to as “legitimate”:
This suggests that the legitimate plugin was already installed on the website and later tampered with by the attackers.
That plugin being Directorist, which is indeed a legitimate plugin.
Seeing as Sucuri is a service that is supposed protect against websites being hacked, you think that determining how the website was hacked would be central to their dealing with the hacked website. Yet the section on determining the source doesn’t match up with that:
Determining the Source
In checking the access logs for the website it was easy enough to determine the IP address responsible. Our client was located in the southern United States, however we saw quite a few requests from a foreign IP address which was interacting with the directorist plugin using the plugin editor feature of wp-admin. This suggests that the legitimate plugin was already installed on the website and later tampered with by the attackers.
Interestingly, the very first request that we saw from the attacker IP address was from the wp-admin panel, suggesting that they had already established administrator access to the website before they began their shenanigans. Whether they had brute forced the admin password using another IP address or had acquired the already-compromised login from the black market is anybody’s guess.
Among the many issue with that, brute force attacks against WordPress admin passwords are not happening, but to the extent there are attacks described as being brute force attacks that do happen, that would show up in the log files, which they should have reviewed. Someone acquiring a compromised login from the black market is theoretically possible, though seems unlikely. Overall, that section reads like a warning to avoid Sucuri, since they don’t seem interested in even trying to do the work needed to provide the protection they claim to offer.
Despite all of that, Sucuri got press coverage for this with an emphasis on the website being hacked running WordPress, despite the lack of claimed causation related to WordPress. That came from the likes of Bleeping Computer, “WordPress sites are being hacked in fake ransomware attacks” and Threatpost, “Fake Ransomware Infection Hits WordPress Sites“.
The Vulnerable Plugin Sucuri Missed
Two days after Sucuri’s post, we were contacted by an anonymous individual with a link to a proof of concept for an authenticated arbitrary file upload vulnerability that had been in Directorist, which posted on pastebin.com. We confirmed the proof of concept with one exception, the vulnerability was claimed to have been fixed in version 7.0.6.2 when it was actually 7.0.6.1.
Version 7.0.6.1 was released the day before Sucuri’s post, so it seems that before their post, someone had realized the plugin was insecure. A reasonable explanation based on the timing is that someone dealing with a website hacked that had been hacked through the plugin realized it was insecure, unlike Sucuri.
While both of our competitors in tracking vulnerabilities in WordPress plugins, the WPScan Vulnerability Database and Patchstack, claim to verify vulnerabilities before adding them. Both of them listed the wrong version this was fixed in:
They also strangely claim the vulnerability requires cross-site request forgery (CSRF), despite that not being the case. They were not the only ones to do that, as Sucuri later updated their post with this:
UPDATE: While the original point of this article was to mention this new malware infection and not locate its source we mentioned it may have been a compromised admin account. Upon further evaluation it was due to a cross-side request forgery vulnerability in the Directorist plugin which has since been patched. Thank you to Plugin Vulnerabilities for reading and paying close attention to our blog posts. Users of this plugin should update immediately!
In addition to the to strange reference to CSRF, their claim to not be focused on locating the source of the hack is odd considering, again, they offer a service that is supposed to protect websites from being hacked.
Wordfence Fails to Protect
Coming back to Wordfence, the Wordfence Security plugin can provide protection either through a rule written for a specific vulnerability or through general protection that would protect against a type of vulnerability more generally. In this case, with the current way that firewall plugins operate, general protection seems to not be possible (though we have something in planning stages that could). So they would need to provide a rule for the vulnerability.
Considering that this type of vulnerable is one that you expect to have exploit attempts and it seems entirely possible it did have those, you would expect Wordfence to have added a rule to protection against.
Wordfence provides new rules for their firewall to their Wordfence Premium customers for the first 30 days, so you can trace back when and if protection was added for customers of that by seeing when and if it was added to their free data. 30 days from November was December 17. So far, no rule has been added to protect against this vulnerability.
Testing we did yesterday confirmed that their plugin still does not stop exploitation of the vulnerability.
Even if it did provide that, it wouldn’t be enough protection on its own, since earlier testing we did showed that another vulnerability fixed in the plugin at the time would have allowed disabling the Wordfence Security plugin.
Plugin Security Scorecard Grade for Patchstack
Checked on March 5, 2025See issues causing the plugin to get less than A+ grade
I confirm, my site was attacked despite having wordfence.
However, Wordfence does not protect you from vulnerabilities but it does protect you from attacks such as logins and allows you to geo-restrict countries.
Using a strong and unique password is the way to protect against login attacks. Wordfence Security will tell they are blocking a lot of those attacks, but they would fail anyway if you do those things. If you don’t do those things, then Wordfence Security’s protection can be bypassed.
While country restriction might be useful depending on the situation, it isn’t a security feature, as attackers use IP addresses from many countries.