Hacked Despite Cloudflare? How It Happens and What to Fix

By Glenn Lyvers · Updated September 28, 2026 · 7 min read

Cloudflare doesn’t stop every hack because it only sees traffic that goes through it, and most of the ways sites actually get compromised don’t. Stolen passwords, a vulnerable plugin exploited by a logged-in user, a hosting or FTP login, a malicious plugin you installed yourself, or a request sent straight to your server’s real IP all bypass the proxy entirely. Cloudflare is a good front door. The break-in usually came through a window.

What Cloudflare actually protects

Put simply, Cloudflare sits between visitors and your server. It caches pages, absorbs floods of traffic, and on every plan runs a web application firewall: Free plans get the Cloudflare Free Managed Ruleset, a subset of the full managed rules focused on the highest-impact, widely exploited vulnerabilities, while paid plans unlock the broader rulesets and more custom rules. That is genuinely useful. It blocks a lot of automated scanning, rough SQL-injection attempts and DDoS traffic before it ever touches PHP.

But look at what it needs to do that job: the request has to pass through Cloudflare, over HTTP, in a form the rules recognise as malicious. Anything that doesn’t meet all three conditions is outside its reach.

The six ways sites get hacked behind Cloudflare

Route in	Why Cloudflare doesn’t see it
Stolen or guessed admin password	A correct login looks exactly like you logging in.
Hosting panel, FTP, SFTP or SSH	Those connect to your server directly, not through the website proxy.
Origin IP exposed	Attackers skip Cloudflare and send requests straight to the server.
Vulnerable plugin, subtle exploit	New or niche bugs often have no matching WAF rule yet, especially on the Free ruleset.
Malicious or nulled plugin/theme	You installed the malware yourself; there’s nothing to block.
Another site on the same account	An infected neighbour writes to your files on the server.

The first two account for a large share of the cleanups I do on Cloudflare-protected sites. Infostealer malware on a laptop, a reused password, or a web designer’s old FTP account — none of that has anything to do with the website’s traffic. The last row is cross-site contamination, and it is why cleaning one site on a shared account and ignoring the other five rarely holds.

Plugin vulnerabilities sit in the middle. Cloudflare does push emergency rules for the big, widely exploited ones, and those genuinely help. But the long tail of WordPress bugs — an authenticated privilege escalation in a form plugin, an arbitrary file upload in a niche gallery add-on — often arrives as a perfectly ordinary-looking request from a logged-in subscriber. A generic ruleset has no reason to block it. The only reliable protection there is the boring one: update promptly, remove what you don’t use, and don’t let strangers register accounts you don’t need.

The origin IP problem

Cloudflare’s protection assumes nobody knows your server’s real address. In practice it leaks all the time: old DNS records from before you moved to Cloudflare sit in public DNS history databases, a mail. or ftp. subdomain is set to “DNS only” and points at the same server, or WordPress sends email from the server IP and the headers reveal it. Once an attacker has the IP, they talk to your server directly and the WAF never sees a thing.

The fix is on the server, not in Cloudflare: configure the firewall to accept web traffic only from Cloudflare’s published IP ranges, and for a stronger guarantee enable Authenticated Origin Pulls, which is available on all plans and makes the server reject connections that don’t present Cloudflare’s client certificate. On most shared hosting you can’t touch the server firewall at all, which is one of the reasons I move repeat-infection sites to hosting I control.

When Cloudflare serves the malware for you

This one catches people after a successful cleanup. If malicious JavaScript was injected into a page or a static file, Cloudflare may have cached the infected version at its edge. You clean the server, check the site, and it looks fine to you — while visitors in other regions, and the blacklist crawlers reviewing your appeal, keep receiving the cached copy. I have seen Google Safe Browsing reviews fail for exactly this reason.

After any cleanup: go to Caching → Configuration → Purge Everything in the Cloudflare dashboard, clear any page cache on the server as well, then re-check from a device and network you don’t normally use. Only then submit review requests. The same logic applies to any CDN, and it is why “clean” and “still flagged” can both be true at once.

When the Cloudflare account is the problem

Sometimes the site was never touched. An attacker who logs into your Cloudflare account can change DNS records to point your domain elsewhere, add a Worker or a transform rule that injects code into every response, or add page rules that redirect visitors. The server is clean and the site is still serving spam. If your files check out and the problem persists, look at the Cloudflare audit log and at Workers, Rules and DNS — Cloudflare account compromised covers that investigation, and hacked DNS versus hacked website helps you tell the two apart.

What to do now

1. Clean the site properly, including the database and any backdoors — a WAF in front of an infected site just protects the attacker’s foothold. Start with a quick look using the free site scanner.
2. Find the route in. Check the table above against your logs. If it was a password, rotate everything; if it was the hosting account, see hosting account takeover recovery.
3. Lock the origin to Cloudflare’s IP ranges and enable Authenticated Origin Pulls.
4. Purge Cloudflare’s cache, then verify from outside.
5. Secure the Cloudflare login itself with two-factor authentication, and review who else has access.

Keep Cloudflare — just use it well

None of this is an argument for turning Cloudflare off. It is worth having, and on sites I manage it stays on. Add rate limiting on wp-login.php and xmlrpc.php (my brute force guide explains why that belongs at the edge rather than in a plugin), keep the managed rules enabled, and pair it with the things it can’t do: updates, two-factor on every admin, file integrity monitoring and server-side hardening. If the site keeps getting reinfected despite all of that, the answer is almost always something that survived the first cleanup — see why sites keep getting reinfected, or hand it to me and I will find it as part of a full malware cleanup.

Common questions

Why did my site get hacked if I use Cloudflare?

Because Cloudflare only inspects web traffic that passes through its proxy. Stolen passwords, hosting panel and FTP logins, direct requests to an exposed origin IP, malicious plugins you installed, and infections spreading from other sites on the same server all bypass it. Cloudflare reduces automated attacks, but it cannot stop an attacker who comes in another way.

Does Cloudflare remove malware from my website?

No. Cloudflare is a proxy, CDN and firewall; it does not scan or clean the files and database on your server. If your site is infected, the malware has to be removed at the origin. Cloudflare can even keep serving an infected page from its cache after the server is cleaned, so purge its cache once the cleanup is done.

Does the free Cloudflare plan include a WAF?

Yes. Free plans get the Cloudflare Free Managed Ruleset, a subset of the full managed rules aimed at the highest-impact, widely exploited vulnerabilities, deployed by default. Paid plans add the broader Cloudflare Managed Ruleset and more custom and rate-limiting rules. Neither protects against logins with valid stolen credentials.

How do I stop attackers bypassing Cloudflare to my server?

Restrict the server's web ports so they only accept connections from Cloudflare's published IP ranges, and enable Authenticated Origin Pulls so the server rejects requests without Cloudflare's client certificate. Also make sure no DNS-only subdomain, old DNS record or outgoing email header reveals the origin IP address.

My site is clean but still shows malware to visitors. Is it Cloudflare?

It may be. Cloudflare can cache an infected page or script and keep serving it after the origin is clean. Purge the entire cache in the Cloudflare dashboard, clear server-side caches, and recheck from a different network. If the problem continues, check the Cloudflare account for unexpected Workers, rules or DNS changes.