The Myth of Secure Hosting - Only 26% of Vulnerability Attacks Blocked By Hosts

"Secure hosting" is a phrase that's increasingly used, and most hosts offer some level of security as part of their services. This mostly refers to known security suites like Cloudflare or in-house firewall solutions. But most of these solutions are ineffective against WordPress vulnerability exploits.

In 2025 we conducted a limited experiment to see if popular web hosting solutions could prevent attacks against known exploited vulnerabilities.

In the test we used 11 vulnerabilities that were known to be exploited in real-world attacks. We then tested these attacks on hosts using various solutions, from big security suites like Cloudflare to custom firewalls.

The shocking answer was that 88% of attacks we ran resulted in a successful site takeover.

But we wanted to see what would happen if we expanded the scope of the experiment. So for our second test, we decided to include more hosting companies, more different defensive layers, and more vulnerability types.

Our assumption was that the number of successful attacks would decrease as hosts would be better at blocking the more generic, non-WordPress specific vulnerabilities.

The new results show that while hosts overall did a little better against more generic attacks, 74% of all attacks still succeeded. Furthermore, this test also included the same 10 original vulnerabilities we tested in the first experiment. We had expected the hosts to react & mitigate those after our reports, but this was largely not the case.

We know WordPress vulnerabilities are still on the rise, and vibe-coding practices will only exacerbate the problem. Furthermore, Google reported that time-to-exploit metrics hit negative values for the first time in history in 2024, meaning attacks are happening faster than official updates are getting rolled out.

This case study is about looking past the marketing to see how well hosting companies actually defend against vulnerabilities.

Part I - Experiment methodology & setup

About this experiment

After our initial test was published, we were left with a question. We knew hosts weren’t blocking the specific major vulnerabilities we had tested, but we wanted to know what they were blocking.

The second test series meant more hosts, for a better perspective of the industry as a whole, and more tests encompassing a wider variety of vulnerabilities with a wider range of attack methods, so we could get a real idea of what the industry is and isn’t protecting against.

On top of that, we decided early on to bring in a group of industry leaders to provide input on our vulnerability selection, test suite, and testing processes, so we could ensure this experiment was as fair as possible.

Based on our original test, we had some assumptions on how the second series’ results would look. During the original test, multiple hosts showed some amount of protection against common, non-WordPress-specific vulnerabilities, such as SQL injection or directory traversal attacks. We expected to see many hosts block these attacks, and as we included significantly more of these non-WordPress-specific tests, we expected the total number of blocked vulnerabilities to increase.

That said, we also know the reality of protecting against WordPress-specific attacks, vulnerabilities like broken access control, or privilege escalation.

These types of attacks are generally plugin/theme specific; often require specific knowledge of the request only WordPress knows (such as, “does the user trying to do this have the correct privileges to do so?”); and are essentially impossible to block in a generic way, meaning there’s no “standard” rule a firewall could use to block them.

Based on these factors, and on how poorly the industry did during our original test, we assumed most WordPress-specific vulnerabilities would be successfully exploitable.

Experiment setup - choosing vulnerabilities & target hosts

With the goals of understanding the hosting ecosystem’s security better, and seeing if our assumptions held water in a broader evaluation, we built the framework for this experiment. First, we constructed a list of vulnerabilities.

Our original tests consisted almost entirely of major vulnerabilities - ones publicly known to be mass-exploited, or which had impacted huge numbers of users.

For the new experiment, we wanted to go wide rather than focus in on specifics; we selected 20 additional vulnerabilities, all published in either 2025 or 2024, with a goal of covering as many categories as possible, and involving different specific attacks to try and give the hosts we tested the best possible opportunities to block at least some of our attacks.

The final vulnerability selection includes 10 of the original vulnerabilities from our v1 tests (#1-9, #20), as well as 20 new vulnerabilities to expand the total scope.

The other major decision made was hosts to test. For this, we again wanted a broad spectrum of coverage. We looked to find both very large and relatively small hosts, as well as a mix of hosts who prominently advertised their security, as well as those who only mentioned it in passing.

To perform our tests, we set up each host with a stock WordPress instance. We used the most recent available WordPress version, and the stock Twenty Twenty-Five theme.

If a host provided their own security-related plugins (e.g., Jetpack), we would enable these. Otherwise, no other plugins were enabled. We would also review the host’s dashboard for security options, and ensure those features were enabled.

Executing the test attacks

After WordPress was installed, we installed the vulnerable versions of each plugin with a vulnerability we were testing, as well as any plugins they required (e.g., WooCommerce). Once installed, we automatically applied a preset configuration to the site and all plugins, ensuring each testing environment was as identical as possible.

Finally we would attempt to exploit each vulnerability using a prebuilt proof of concept (PoC) exploit. We intentionally kept the PoCs identical in each test and used the simplest reasonable PoCs we could produce. We also did not use any obfuscation or advanced bypass techniques in these attempts.

The goal was to simulate real-life conditions by using the simplest attacks possible, thereby giving the hosts a fair chance to block the exploits.

Part II - Results & findings

As we had assumed the hosting defences did better compared to our original test results. On average, hosts managed to block 25.89% of exploit attempts, versus 12.8% in the original study.

However, this means roughly 74% of attacks still succeeded.

In the chart below you can see the breakdown of complete and partial success rates by host and the security setup that was tested:

Vulnerability block rates by host

⚠️ Note: Host names are hidden, but they are known to the external observers.

After reviewing these results and correlating them with the security solutions each host used, we found some interesting notes on the efficacy of some industry solutions.

Hosting defences mostly ineffective against WordPress vulnerabilities

We found that WordPress-specific vulnerabilities were still the least blocked across all hosts.

Of the high-impact vulnerabilities, Privilege Escalation attacks were blocked only 12% of the time.

Privilege Escalation is considered one of the most severe types of attacks - once an attacker has gained Administrator privileges, they can edit any content on your website, see any sensitive data (e.g., customer information on an e-Commerce website), or potentially even upload their own malicious PHP files, often bypassing any protections against PHP upload attacks, using WordPress’ built in tools for plugin/theme management.

Successful attack rates per vulnerability (Patchstack excluded)

“WAF” can mean anything, and nothing

Many hosts advertised a commercial web application firewall, specifically a solution often used for DNS management, anti-DDoS protection, and CDN functionality.

While these services often have a managed ruleset that can block common attack types (e.g., directory traversal, cross-site scripting, or PHP object injection), we did not see consistent results across all hosts using these products, even between different companies using the same product.

Based on this, we believe hosts are often enabling only certain components of these solutions, obfuscating what their WAF solution does and does not protect against, and can’t be evaluated solely because they “use an X brand firewall”.

It is also likely that hosts are limiting the capabilities of firewalls, as stricter rules would result in high volumes of false positives, which in turn would disrupt their normal services.

In-house firewalls more effective than commercial solutions for generic attacks

When looking at generic, non-WordPress specific vulnerability attacks, hosts’ in-house firewall solutions outperformed commercial solutions.

Our results show that the hosts that performed best maintained their own internal firewall solutions.

While seeing a host advertise an in-house firewall isn’t a silver bullet for securing your WordPress websites, it does confirm another assumption we had: the hosts that perform best are the ones investing resources in improving their environments.

The vast majority of successful blocks were from non-WordPress-specific vulnerabilities. The most consistently blocked vulnerability class was Arbitrary File Uploads*, in which all three tested vulnerabilities were blocked 60% of the time.

Arbitrary File Upload attacks involve uploading a malicious PHP file to the website, and once fully exploited, an attacker can immediately gain full control of the hosting environment. We considered the attack blocked when either the file itself was prevented from being uploaded or the hosting environment prevented our execution of it.

A special note on Cross-Site Request Forgery attacks

Cross-Site Request Forgery (CSRF) attacks were the only ones that weren't blocked by any host, or even Patchstack (in fact, we generally don't provide protection rules for CSRF).

This is due to the unique nature of CSRF vulnerabilities. These are usually impossible to exploit at scale, and they require specific targeting and social engineering to succeed. It's also difficult to prevent these exploits using protection rules without severely impacting normal site functionality.

No host can reasonably be expected to cover these vulnerabilities, and the two CSRF cases were selected for the experiment solely to ensure the widest possible coverage of different vulnerability types.

Conclusions

The results of this study support our initial conclusion that WordPress vulnerability mitigation remains a largely unsolved problem.

Hosting companies seem to agree - in their 2025 Web Hosting Trends survey, Cloudlinux reported that 64% of hosting companies cited WordPress vulnerabilities specifically as their biggest security challenge.

In our conversations with hosting industry representatives, we've noticed the biggest problem isn't that hosts don't care about vulnerability attacks - it's that they think their existing solutions have got them covered.

Effective security, however, works in layers. Different threats require different approaches, and as we saw from the test results, one-stop-shop tools & generic WAFs cannot cover vulnerability exploits.

With vibe-coding introducing more security issues both within and outside the WordPress ecosystem, hosts need to rethink how they build their security stacks to provide safe solutions for their customers.

How does your security stack up against vulnerabilities? Let's find out

If you're a hosting company and would like to have your security stack tested using the same framework then get in touch and we'll perform this pentest for you for free.

If you're interested, simply fill out the form on this page and our security team will be in touch.

P.S. your results will be kept confidential. You will also have full transparency into the vulnerabilities and attack methods used.

Special thanks 🙏

We'd like to thank Konrad Keck and Kevin Ohashi for helping us validate the test methods, and also for your questions and feedback throughout this process!