Your Host Blocks 12% of WordPress Attacks. Patchstack Measured It.

There is a belief, common among people who pay for good WordPress hosting, that the host handles security. It is not a stupid belief. Good hosts do a great deal: they patch the operating system, they isolate accounts, they run a firewall, they take backups. The belief goes wrong at the point where "the host runs a firewall" becomes "the firewall stops attacks on my site".

Patchstack put a number on that gap this year, and it is smaller than most people would guess.

The test

For its 2026 State of WordPress Security report, Patchstack ran two penetration-testing scenarios against the defences that hosting companies typically deploy: their internal web application firewalls, and Cloudflare in its common configuration. Then it fired real WordPress exploits at them, the kind that were being used in the wild against real sites.

The results:

• Across a broad set of vulnerabilities, hosting defences blocked 26% of exploit attempts.
• Against actively exploited WordPress-specific vulnerabilities, the ones that matter most, they blocked 12%.

So for every eight attacks using a live WordPress exploit, the typical hosting stack stopped one. The other seven reached the site.

Why this is not the host's fault

It is worth being fair to hosts here, because the number invites the wrong conclusion.

A hosting firewall works at the network and HTTP layer. It sees a request come in and decides whether the request looks hostile. That is very good at stopping things that look hostile at that layer: brute-force floods, known malicious IP ranges, requests with SQL injection strings in obvious places, scanners hammering xmlrpc.php.

A WordPress plugin exploit does not look hostile at that layer. The Elementor Pro upload flaw from August was a form submission. The All-in-One WP Migration flaw from the same month was two trackbacks on a blog post. A REST API privilege escalation is a JSON request to an endpoint that is supposed to accept JSON requests. The request is well-formed, it goes to a URL that legitimately exists, and the payload is only dangerous because of what a specific version of a specific plugin does with it. A generic firewall has no way to know that, and the more aggressively it guesses, the more legitimate traffic it breaks, which is why hosts tune them conservatively.

Cloudflare is the same story. Its managed WordPress ruleset is useful and worth having, but it is a set of patterns for known bad requests, and a new plugin vulnerability is by definition not yet a known pattern. Patchstack's own data says the median time from a vulnerability being disclosed to it being exploited is five hours. Nobody's ruleset updates in five hours.

The 12% is not a failure of hosting firewalls. It is what a hosting firewall is for. The mistake is expecting it to be something else.

What that leaves for you

If seven in eight live exploits reach the site, then what happens next is decided by the state of the site, not by the network in front of it. That is the part you own, whatever you pay your host, and it breaks down into three things.

Reduce what can be exploited. The report counted 11,334 new vulnerabilities across the WordPress ecosystem in 2025, up 42% on 2024, and 91% of them were in plugins. Every plugin you do not have installed is a vulnerability you cannot have. Every plugin you keep should be one you would notice going stale: check the last-updated date and the tested-up-to version, and remove anything that has not shipped in a year. This is not glamorous. It is the single largest lever you have, and it costs nothing.

Close the classes, not the instances. You cannot patch within five hours. Nobody can. What you can do is make whole categories of exploit fail regardless of whether you patched. Block PHP execution in the uploads directory and every file-upload flaw becomes a dead file. Make wp-config.php unwritable and a whole family of persistence tricks has nowhere to go. Run PHP as a user that cannot write to the plugins directory and a webshell cannot install itself as a plugin. These are one-time server changes. They do not know or care which plugin had the bug.

Assume something got through, and be able to tell. If the honest expectation is that most live exploits reach the site, then detection matters as much as prevention. File integrity monitoring that tells you when a file appears in uploads or mu-plugins. An alert when a new administrator account is created. A weekly look at the access log for POST requests to files that should not receive them. None of this stops an attack. All of it turns a compromise you would have found in six months into one you find in a day.

The honest version of "my host handles security"

Your host handles the server. That is a real and valuable thing, and a bad host will undo everything else you do. But the moment a request reaches WordPress, the host is out of the picture and the outcome is decided by the plugins you chose, the hardening you applied, and whether anything is watching.

The people who get hurt by this are not the ones who ignore security. They are the ones who did the sensible thing, paid for a reputable host with a firewall, and reasonably assumed that covered it. Patchstack's number says it covers about an eighth of it. The rest was always yours.

Where this fits

Chapter 1 of the Protect My WP handbook is about exactly this boundary: what a host does, what it does not, how to tell a good one from a bad one, and where your responsibility starts. Chapters 2 and 4 are the class-closing rules above. Chapter 10 is the detection layer. The book is written from the hosting side by someone who has watched the firewall let things through, which is why it spends so little time on the firewall.

Get the book for £19.