If, after 19 August 2026, you got a white screen or the message “There has been a critical error on this website”, and you can’t log in to wp-admin either, the chances are it wasn’t your fault. The release of WordPress 7.1 clashed with one of the modules of the WP Rocket caching plugin, and thousands of sites went down overnight.
What happened on 19 August 2026?
That was the day WordPress 7.1 “Mary Lou” was released, the work of more than 800 contributors. A few hours later, after a completely routine update, sites started falling over.
In the early hours of the next morning, WP Media, the developer of WP Rocket, opened an official incident on its status page titled “WP Rocket incompatibility with WordPress 7.1”. According to the timeline, the bug was identified at 05:44, a fix was released at 08:14 and the incident was closed at 10:15. This sentence was added to the official changelog:
“Fixed the Fatal Type Error appearing after update to WordPress Core 7.1 in some configurations” — WP Rocket 3.23.2.2, 20 August 2026.
In other words: the bug is real, the vendor has acknowledged it, and there is a fix. The problem is that by then many sites had already been down for hours — and their owners didn’t know.
How can you tell whether this is the bug affecting you?
Look for just one thing. In your hosting error log, or in the email WordPress sends with the subject “Your Site is Experiencing a Technical Issue”, search for this snippet:
`Cloudflare.php:562`
If it’s there, this is the case you’re dealing with. Typically it looks like this:
| What you are seeing | Does this bug fit? |
|---|---|
| A white screen or “critical error” on the public site and in the admin | Yes — this bug kills every entry point |
| Only wp-admin is slow, but it works | No, that’s a different problem |
| You have WP Rocket on your site and you updated to WordPress 7.1 | Yes, that’s the main suspect |
| You are running WordPress 7.0.x | No — the 7.0 branch was not affected |
| There are also unknown admin accounts or unfamiliar files | Not this — look for signs of a hack instead |
Important: this is not a hack. Many site owners suspect an attack first and panic. This is a programming bug — the plugin received data from WordPress that it wasn’t prepared for, and execution stopped.
Why did your site crash even though you kept everything up to date?
This is the most frustrating part of the story. The affected sites were up to date: the latest WordPress, the latest paid version of WP Rocket. Those who had put off updating got away with it.
Wordify, which carried out the technical analysis, put it this way: nobody did anything wrong. A stable WordPress release, a fully up-to-date premium plugin, a routine update — and the site still went hard down.
Two things make this particularly insidious:
• You don’t need to use Cloudflare for the Cloudflare module to kill your site. This module runs on every request, even if you have nothing to do with the service.
• WP Rocket on its own didn’t crash either. It took a third plugin — in the documented cases, typically Elementor Pro, which is extremely widespread. In other words, the bug came from the *combination* of plugins. Exactly the thing nobody tests in advance.
And here is a detail worth remembering: the bug was reported six weeks earlier, on 6 July 2026, in WP Rocket’s public issue tracker, together with a proposed fix. It still hadn’t been merged by the time 7.1 came out. This was uncovered by the trade publication The Repository, and the vendor has since promised an internal review.
How common is this? It didn’t only happen to you
A few numbers to put it in context:
In one professionally managed hosting fleet, 124 out of 332 sites running WP Rocket hit a fatal error after 7.1 — more than a third of them. And that was in an environment overseen by experts. (The Repository, August 2026)
According to Wordify’s logs, the first fatal error appeared three seconds after the core update. There is no “I’ll notice it later” phase: if the update runs overnight, your site is down until the morning. (Wordify, 20 August 2026)
And WP Rocket is far from a niche plugin. According to wmtips’ technology survey, it holds a 9.1% share of caching solutions worldwide. In other words, a significant proportion of WordPress sites were exposed to this bug.
What not to do until you understand the situation
This section isn’t about the fix, but about how not to permanently ruin what can still be saved. The most common panicked moves:
• Don’t delete the faulty file itself. The vendor explicitly warns against this in its own help docs: the affected class is wired into the plugin’s internal structure, so deleting it just gives you a different fatal error — and it’s harder to find your way back from there.
• Don’t roll WordPress back to an older version. A downgraded core can cause problems at database level that are orders of magnitude more expensive than the original issue.
• Don’t touch anything without a backup. Before you change anything on your hosting, take a snapshot of the current state. If you don’t have a recent, restorable backup, we’ve written about that separately in our article on the 3-2-1 backup rule.
• Don’t ask a friend to “have a quick look over FTP”. In this case the usual recovery routes — including command-line tools — also stop working, because the error occurs earlier than those tools can reach. Anyone who doesn’t know the exact sequence can easily make things worse.
So what’s the lesson? Not that you should stop updating
You may be tempted to leave updates alone in future. That’s the wrong direction, and it would cost you far more.
An unpatched site is the most predictable target: in the case of WordPress 7.0.2, the first attack attempts arrived 90 minutes after the fix was released. Putting off updates isn’t security, just deferred risk. We’ve also covered the quality of plugin choices separately in our article on choosing plugins.
The real difference isn’t whether you update, but under what conditions: is there a staging environment, is there a restorable backup, are updates applied in the right order, and is there someone who will notice at 2 a.m. if the site goes down?
Our maintenance-plan clients didn’t feel any of this
On the sites covered by a WPShield maintenance plan, we dealt with this incident, of course — most of our clients only found out that there had been a problem once we had already fixed it. That is exactly why the service exists: a site isn’t secure because nothing ever happens to it, but because when something does happen, someone notices straight away and deals with it.
If your site is down right now and you don’t know where to start, request our free quick security check. We’ll confirm whether this is really the bug you’re dealing with, look at the state of your site, and tell you what it will take to restore it. Fifteen minutes, and you’ll know where you stand.
*Sources: WordPress.org — WordPress 7.1 “Mary Lou” (19 August 2026); WP Rocket changelog — 3.23.2.2 (20 August 2026); WP Media status page — WP Rocket incompatibility with WordPress 7.1; WP Rocket knowledge base — Fatal error on WordPress 7.1; The Repository (21 August 2026); Wordify technical analysis (20 August 2026); wmtips — WP Rocket usage statistics.*
Frequently asked questions
Why did my site crash after the WordPress 7.1 update?
If your site runs WP Rocket, it’s very likely that a line in the plugin’s Cloudflare module clashed with an internal change in WordPress 7.1. WP Rocket’s vendor acknowledged the bug in an official incident on 20 August 2026 and released version 3.23.2.2 with the fix the same day. WordPress 7.0.x versions were not affected.
How do I know this is really the bug affecting me?
Look for the text Cloudflare.php:562 in your error log or in WordPress’s critical error email. If it’s there, this is the case you’re dealing with. In this situation it isn’t just the admin area that goes down, but the public site, the REST API and scheduled tasks too.
Has my site been hacked?
In this case, almost certainly not. This is a programming bug, not an attack: the plugin received data from WordPress that it didn’t expect, and execution stopped as a result. A hack is indicated by other signs, such as an unknown administrator account or unfamiliar files among your uploads.
So would I have been better off not updating?
No. Postponing updates is a bigger risk in the long run: published but unpatched vulnerabilities start being attacked within days. The answer isn’t to skip updates, but to keep control of the order and the conditions — a staging environment, a backup and a managed schedule.
Why did my site crash even though I don’t use Cloudflare?
Because WP Rocket’s Cloudflare module runs on every request, regardless of whether Cloudflare is switched on. That’s why it caught out people who had nothing to do with the service.
