Are hosting companies’ standard network and server defenses enough to prevent exploits of WordPress vulnerabilities?
The world of open-source is fraught with misconceptions, particularly when it comes to cybersecurity. It’s not uncommon to hear even technical stakeholders claim that having a firewall and basic server-layer defenses is enough to protect users from WordPress vulnerability exploits.
Additionally, in the past few years, we’ve seen an increase in third-party providers who claim to offer virtual patching.
At Patchstack, virtual patching (vPatching) is part of the RapidMitigate system that combines:
- A web application firewall (WAF)
- Software composition analysis (SCA)
- Industry-leading threat intelligence (TI), and
- Context-aware prioritization (based on KEV)
… all to identify vulnerabilities and trigger virtual patches, AKA highly-targeted, dynamic mitigation rules that protect websites until site owners can safely resolve the vulnerabilities.
However, hosting companies often claim to offer secure WordPress hosting by including network firewalls such as Cloudflare or using server security solutions such as Imunify and Monarx. Today, we are putting these claims to the test to see if, besides network and server protection, applications like WordPress sites are secured as well.
Earlier this year, we released our annual security report in collaboration with Sucuri (security company owned by GoDaddy) where they shared statistics about 500,000 hacked websites in 2024. How is this possible when we see most hosting companies claim to provide "secure WordPress hosting"?
With this case study, we’ve tested the effectiveness of standard hosting environments, as well as two other providers of “virtual patching” to provide a definitive answer once and for all: which solution is the most qualified to block attacks against WordPress-specific vulnerabilities?
Hosting security failed: 87.8% of threats bypassed hosting defenses.
As we tested 11 vulnerabilities across five distinct hosting environments, we found that the attacks bypassed hosting companies’ existing security solutions in 87.8% of the cases, before reaching Patchstack’s application-layer solution, which successfully blocked them.
In this case study, we’ll go deeper into our methodology and the types of hosting environments tested.
Methodology and the testing process
As a baseline, we have decided to host test sites (sites against which we will perform controlled pentesting with a set of 11 WordPress-specific vulnerabilities) with 5 distinct hosting providers, some of which have ingrained features marketed as helping with security.
In addition to the hosting provider’s security measures and third-party providers for additional measures like robust WAFs or other patching providers, we have also installed Patchstack on every site, with our test question being:
How many of these threats will bypass firewalls and other third-party security tools providers to ultimately reach Patchstack? And will Patchstack be able to block them all successfully?
Vulnerabilities tested
For our test, we chose 11 vulnerabilities. The criteria for selection were a combination of the affected component’s popularity, the severity of the vulnerability, public visibility, and whether the vulnerability was known to be exploited. Our guiding principle was to choose vulnerabilities that any reasonably good security solution could catch.
During selection, we expected that many traditional web application firewalls (WAFs) would be able to catch non-WordPress-specific vulnerabilities, such as Cross-Site Scripting (XSS) and SQL Injection (SQLi) vulnerabilities.
Therefore, the test placed heavy emphasis on PHP or WordPress-specific vulnerabilities, such as Broken Access Control (BAC) vulnerabilities, especially those resulting in Privilege Escalation.
Three of the chosen vulnerabilities were new and were included to see if behaviour-based firewalls would detect fresh threats.
For the sake of completeness, we have also included a selection of vulnerabilities not only specific to WordPress (e.g., PHP object injection, XSS, and SQL injection), as well as a broader range of application logic errors (e.g., Privilege Escalation).
PSID
Plugin
Version
Vulnerability type
Prerequisite
Testing process
Each website was configured identically (same plugins on the same versions, same configuration options, etc). For this study, we built an exploitation testing toolkit, which ensured the same tests were applied in the same order to each site.
Final results were both automatically and manually reviewed to determine if the threats were blocked and whether they were blocked by the host's environment or by Patchstack. We also checked whether the claimed security solutions were active on that site.
Straightforward attacks, no evasion
Pattern based WAFs are known to be easily bypassed by different evasion techniques. In our testing, we wanted to make sure that we’ll be using the most obvious exploits without any evasion techniques.
As an example, we include the POC of the WooCommerce Payments vulnerability which is known to be widely exploited and published 2 years ago. In this test, only Patchstack RapidMitigate blocked this vulnerability.
POST /wp-json/wp/v2/users HTTP/1.1
Host: <WP HOST>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36
Accept-Encoding: gzip, deflate
Accept: application/json
Connection: keep-alive
Content-Type: application/json
X-Wcpay-Platform-Checkout-User: 1
Content-Length: 114
{"username": "honeypot", "email": "wafdemo@patch.stack", "password": "demo", "roles": ["administrator"]}Results: Hosting providers vs vulnerabilities
Hosting environment defenses failed: Patchstack blocked the remaining 87.8% of vulnerability attacks.
Traditional network and server layer defenses (as well as other providers claiming to offer vulnerability mitigation) failed to detect the exploitation attempts in time.
Previous lines of defense failed, leaving Patchstack to address them at the application layer. These were WordPress-specific vulnerabilities in popular categories that can have a significant impact on sites, as explained in our State of WordPress Security 2025 report.
In particular, we found that:
- 2 out of the 5 hosts and their solutions failed to block any vulnerabilities at the network and server levels.
- 1 host blocked 1 vulnerability out of 11.
- 1 host blocked 2 vulnerabilities out of 11.
- 1 host blocked 4 vulnerabilities out of 11.
Hosting providers and security tools vs vulnerabilities
These results reaffirm the Swiss Cheese approach used by cybersecurity professionals, which states that each layer is best equipped to deal with threats specific to its layer.
For example, you shouldn’t rely on a generic WAF to try to block vulnerabilities, but it will do a great job of blocking bot traffic.
In this case, the network and server layers did not perform well against WordPress vulnerabilities, which are best mitigated by application-layer solutions like Patchstack.
However, our most surprising finding was related to the third-party patching providers. While both providers tested claimed to offer patching to mitigate vulnerabilities effectively, neither provider would prevent the exploits from occurring.
With just these solutions, the sites of these hosting companies’ users would have been compromised. Before enabling Patchstack’s protection, in every environment we tested, we were able to gain full administrative access to the target website.
1. Hosting Provider A + Cloudflare WAF
The test site we registered with hosting provider A had the hosting provider’s ingrained security measures (SSL, anti-DDoS protection, anti-virus and anti-spam, and daily backups). We also installed Cloudflare’s WAF.
As an edge WAF, Cloudflare intercepts and examines all traffic destined for a web application, including requests and responses, using techniques such as rulesets and request scoring, to identify malicious traffic patterns and suspicious behavior.
Cloudflare claims that, based on its analysis, its WAF can block or mitigate attacks such as SQL injection, cross-site scripting (XSS), and cross-site request forgery (CSRF).
Our particular area of interest was that this type of WAF operates at the application layer, which is presumed to be the most effective at vulnerability mitigation.
How many vulnerabilities did Hosting Provider A’s Cloudflare block?
Out of 11 plugin vulnerabilities we tested, this hosting provider’s Cloudflare WAF blocked 4 exploits (36.36%), which were:
- GiveWP plugin vulnerability: Unauthenticated PHP Object Injection
- TI WooCommerce Wishlist plugin vulnerability: Unauthenticated Arbitrary File Upload
- TI WooCommerce Wishlist plugin vulnerability: Unauthenticated SQL Injection
- LiteSpeed Cache plugin vulnerability: Unauthenticated Stored XSS
These are the best results we’ve seen in the test.
However, the remaining 63,64% of vulnerabilities still reached Patchstack, meaning that Cloudflare did not block all the threats.
2. Hosting Provider B + In-house firewall + Monarx
The next test site we registered with the hosting provider B.
Hosting provider B claims to offer secure and speedy website hosting, which includes:
- In-house WAF
- Automatic malware removal
- DDoS mitigation
- A third-party patching provider, Monarx, which specializes in on-disk patching for major WordPress CVEs, behavior-based detections, and automatic major CVE patching.
Initially, we assumed their solution would be as effective as Patchstack at blocking vulnerabilities (CVEs).
How many vulnerabilities did Hosting Provider B (with firewall and Monarx) block?
This provider’s in-house WAF and Monarx blocked 0 vulnerabilities.
100% of attacks reached Patchstack’s real-time mitigation, which successfully stopped them.
3. Hosting Provider C + Firewall + Imunify
Hosting provider C has a set of its in-house security measures:
- ModSecurity WAF, which Provider C claims can protect from SQL injections, XSS attacks, known zero-day vulnerabilities, local file includes, remote file includes, and unauthorized file uploads.
- DNS and DDoS protection
- Account isolation
- Daily backups
- Anti-spam email security
Provider C also uses a third-party server security provider, Imunify360, which offers an artificial intelligence firewall for traffic monitoring (botnets blocked, IP reputation filtering, CAPTCHA), website monitoring (application-level DoS protection, request rate limit protection, and whitelist/blocklist filtering), and virtual patching.
Again, we took an interest in the effectiveness of their firewalls and Imunify’s patching, presuming it would block threats before they could reach Patchstack.
How many vulnerabilities did Hosting Provider C (with firewall and Imunify) block?
Provider C, with its firewall and Imunify, blocked only 1 vulnerability:
- TI WooCommerce Wishlist plugin vulnerability: Unauthenticated Arbitrary File Upload
Other vulnerabilities passed the hosting defenses undetected and finally reached Patchstack, which successfully blocked them.
4. Hosting Provider D + ConfigServer
Hosting provider D offers “uncompromising security” with general measures, such as:
- SSL
- Automatic updates
- ConfigServer firewall that provides services such as locking down public access to services to only allow certain connections, monitoring excessive login failures and blocking brute force attacks, and automatic and manual IP whitelists/blocklists.
How many vulnerabilities did Hosting Provider D (with ConfigServer) block?
Upon setting up our site and running the pentesting against the 11 vulnerabilities, Hosting provider D, with its ConfigServer firewall, allowed all 11 vulnerability exploits to bypass the server and network layer protections.
Patchstack ultimately blocked all the vulnerabilities.
5. Hosting Provider E + Mod Security
Finally, we decided to test a barebones hosting offer from a well-known company (Hosting Provider E) and their Mod Security ruleset to protect against DDoS attacks.
How many vulnerabilities did Hosting Provider E block?
This hosting provider blocked 2 out of 11 vulnerabilities:
- CSS & JavaScript Toolbox plugin vulnerability: Authenticated (Subscriber) Local File Inclusion
- TI WooCommerce Wishlist plugin vulnerability: Unauthenticated SQL Injection
The rest bypassed all of their previous server and network layer security measures and reached Patchstack, which efficiently blocked them.
Analysis
While some hosting environments did better with vulnerabilities not specific to the application layer (e.g., PHP object injection, XSS, SQLi), no hosting company, firewall, or patching platform other than Patchstack was equipped to handle WordPress and plugin-specific vulnerabilities.
Plugin
Provider A
Provider B
Provider C
Provider D
Provider E
DB Backup
PS
PS
PS
PS
PS
CSS & JavaScript Toolbox
PS
PS
PS
PS
WAF
GiveWP
WAF
PS
PS
PS
PS
Login and Logout Redirect
PS
PS
PS
PS
PS
Post SMTP
PS
PS
PS
PS
PS
Simple File List
PS
PS
PS
PS
PS
OttoKit
PS
PS
PS
PS
PS
TI WooCommerce Wishlist (Arbitrary File Upload)
WAF
PS
WAF
PS
PS
TI WooCommerce Wishlist (SQL Injection)
WAF
PS
PS
PS
WAF
WooCommerce Payments
PS
PS
PS
PS
PS
LiteSpeed Cache
WAF
PS
PS
PS
PS
PS - blocked by Patchstack
WAF - blocked by the provider
While regular hosting environment protection is adequate against broad threats, it often fails to detect vulnerabilities that are:
- Application-specific: tied to the logic or functionality of a particular plugin or theme.
- Unique to WordPress’s architecture: including authentication bypasses, privilege escalation paths, and shortcode misuse.
- Rapidly weaponized: with publicly available proof-of-concept (PoC) exploits circulating within hours of disclosure.
Because these vulnerabilities do not match generic WAF signatures or rulesets, they often slip past traditional defenses entirely, leaving hosting companies and their users with a false sense of security.
Other mitigation providers
While solutions like Monarx and Imunify market patching or virtual patching as part of their offering, our testing revealed that these protections did not extend to WordPress and plugin-specific vulnerabilities.
One platform failed to block even the most generic exploits, while the other only stopped one. They left sites just as exposed as if the hosting providers had no protective measures in place.
This gap highlights the difference between broad, signature-based blocking and true application-specific mitigation, as offered by Patchstack.
Disclaimer: We tested the hosts as regular customers would use it. We didn't have access to change settings of the security products directly so we can't say if they would perform differently based on how they are set up in different environments. We did however ensure that these products were active in the hosting environment where the website was hosted.
Conclusion
With WordPress powering 40% of the web and 99% of security vulnerabilities stemming from plugins and themes, it’s the single most attractive target for cybercriminals. The speed and scale of modern attacks mean that traditional security is no longer enough.
Security solutions must not only detect and block generic threats but also proactively apply vulnerability-specific mitigation rules even before the site owner updates the software. The number of mitigation rules available also plays a significant role. With the most extensive collection of mitigation rules in the market, Patchstack provides the most robust protection.
You can't protect against what you don't know about. RapidMitigate, which is the system we've built to provide fast mitigation to vulnerabilities has by far the biggest vulnerability coverage in the WordPress ecosystem.
Without this specialized capability, hosting companies and site administrators remain exposed to the very class of attacks most frequently targeting WordPress sites today.
Don’t rely on generic defenses for WordPress. Patchstack is built to detect and block these threats in real-time, applying mitigation rules before attackers can exploit them.
Want us to test this on your hosting environment?
If you're a host and want us to run the same test in your environment, then reach out to us using this form here 📋
Until the end of September, we'll perform free tests to every host wishing to test their current setup against WordPress core/plugin/theme vulnerabilities.
Learn more about Patchstack
Don’t rely on generic defenses for WordPress. Patchstack is built to detect and block these threats in real-time, applying mitigation rules before attackers can exploit them.
Talk to our team today
