WordPress Firewall Plugins Protect Against Vulnerability Without Rule Needed for Wordfence Security To Do That
Last week, we noted that the marketing for the Wordfence Security plugin was promoting its firewall as being the industry leader, despite that not being supported by them with anything whatsoever and objective testing showing that being far from the case. In doing that, we included a screengrab of them making that claim:
Right before the industry leading claim were two things that seem to conflict. They first claim that for free it “Block[s] attacks with the basic tools you need to keep your site safe.” Immediately after that, it says that there is a “30-day delay on firewall rules”. It would seem either those firewall rules are not important or it won’t keep you safe since hackers have 30 days to exploit vulnerabilities before the rules are available. So what is going on there?
To better understand what is going on and to again show that it doesn’t contain the industry leading firewall, let’s look at a recent rule. Recently they added a rule for an authenticated persistent cross-site scripting (XSS) vulnerability in the plugin PowerPress:
if (match('#/wp\-admin/post\.php$#i', server.script_filename) and match(xssRegex,request.body['Powerpress']['podcast']['url'])):
block(id=633, category='xss', score=100, description='PowerPress <= 11.0.10 - Authenticated(Contributor+) Stored Cross-Site Scripting via Media URL', whitelist=0)
That is a vulnerability that was only possible to be exploited by a WordPress user that could create a WordPress post or page, which Wordfence’s rule acknowledges. That makes this a vulnerability that wouldn’t be targeted by hackers in any large-scale way, as it would require a level of access they wouldn’t have. WordPress websites don’t give untrusted individuals the ability to create those things. Why they added a rule in that situation is unclear, considering that is not much of a threat and they don’t add many rules, so it isn’t about being comprehensive.
The rule was added after the vulnerability was fixed, so websites got protection faster by keeping the plugin updated than paying for early access to their firewall rules.
Other Firewall Plugins Provide Protection Without a Rule
What is also notable is that a firewall plugin can protect against this vulnerability without having to write a rule specifically for this particular vulnerability. They can do that because it involves cross-site scripting (XSS), which can be stopped in general way. That means that firewall plugins could have protected against this before not only Wordfence’s paying customers got access to the rule, but even before it was fixed.
As we have noted before, providing protection before vulnerabilities are even publicly known about is where firewall plugins are at there most useful. In our testing of that protection in firewalls against zero-days, vulnerabilities being exploited before the developers of the vulnerable software are aware it, two plugins provide more protection than Wordfence Security. Therefore, it isn’t all that surprising that testing showed that both of them, our own Plugin Vulnerabilities Firewall and NinjaFirewall, protected against this vulnerability despite not having a rule written for it.
Why Does Wordfence Security Need a Rule?
That raises an important question: why does Wordfence Security need a rule written when other firewall plugins don’t? We can’t think of a good reason for that. There is a reason that comes to mind, though. By needing to write rules for vulnerabilities, they have a reason to sell access to those rules. If they provided more general protection, that would reduce the need for rules. This isn’t the first time we have found that other firewall plugins provided protection without a rule when Wordfence Security did. Beyond the issue of providing less protection to sell something, this again shows that their firewall isn’t the industry leader.
Plugin Security Scorecard Grade for NinjaFirewall
Checked on June 12, 2025See issues causing the plugin to get less than A+ grade