Rogue Cloudflare Rules, Workers and Redirects

By Glenn Lyvers · Updated September 20, 2026 · 4 min read

You have rebuilt the site from scratch. New files, new database, fresh install, everything verified. And visitors are still being redirected. If your traffic passes through Cloudflare or a similar service before it reaches your server, there is an entire programmable layer sitting in front of your site, and code running there does not care what you did to your origin.

The layer in front of your site

Services like Cloudflare sit between your visitors and your server. Requests reach them first, and they can cache, modify, redirect or entirely replace the response before your server is ever contacted. That is the point of the service and it is enormously useful.

It also means the account controlling that layer is as security-critical as your hosting account. Someone with access can add redirect rules, inject scripts into every page, route traffic elsewhere, or deploy code that runs on every request — none of which touches your server, appears in your server logs, or shows up in any scan of your files.

Recognizing this is the problem

The pattern is a symptom that survives a clean origin. You have verified files and database are clean, perhaps even rebuilt entirely, and the behaviour persists. Your server access logs show fewer requests than you would expect, or do not show the requests producing the bad behaviour at all, because those are being handled before they reach you.

A decisive test is to bypass the proxy: request your site directly from your origin server's address, or with a local host file entry pointing at your server, and compare. If the direct request gives you clean content and the normal one does not, the problem is in front of your server rather than on it.

Where to look in the account

Go through the configuration methodically. Page rules and any newer rules engine, checking for redirects or transformations you did not create. Workers or edge functions, which are arbitrary code running on every matching request and the most powerful thing an attacker can leave behind here. DNS records in the account, since this is often where DNS is managed too.

Then the rest: transform rules and header modifications, redirect rules, cache rules that might serve altered content, and any app or integration that injects scripts into your pages. Finally check the account itself — additional members you did not invite, API tokens, and the audit log, which records configuration changes with timestamps and is the single most useful thing in the account for reconstructing what happened.

Taking the account back

Change the password and enable two-factor authentication. Then revoke every API token and key, because a token is an independent credential that a password change does nothing about — this is the step people miss, and it is why some accounts get modified again days after being secured.

Remove account members you do not recognize, and review the permissions of the ones you keep. Then remove the malicious rules, workers and records, and read the audit log from before the first bad change to establish when access began.

Then check the origin anyway

Finding the problem at the edge is not a reason to assume the server is fine. The same stolen credentials may have opened both, and a site compromise can lead to an edge compromise if credentials were stored somewhere reachable.

Do the ordinary checks: core file verification, plugin and theme integrity, database sweep, administrator accounts, scheduled tasks, and credential rotation. My guides on checksum verification and identifying website hacks cover that ground.

Keeping it secure

Treat the edge account with the same seriousness as your hosting and registrar accounts: unique password, two-factor authentication, minimal members, and API tokens scoped narrowly and rotated when people leave. An account with full access handed to a contractor three years ago is a live risk today.

Check the audit log occasionally rather than only after something goes wrong, since it makes unauthorized changes visible early. And if you are dealing with a compromise that spans both the edge and the origin and you would rather have the whole chain gone through properly, that is what my malware removal service is for.

Common questions

How can my site be compromised if the server is clean?

Because the service in front of your server can modify responses before they reach visitors. Redirect rules, transform rules and edge workers all run without involving your origin at all. A perfectly clean server delivers perfectly clean content that is then altered on the way out.

How do I test whether the problem is at the edge?

Request your site directly from your origin server's address, bypassing the proxy — either by IP or with a local hosts file entry. If the direct request returns clean content while the normal route does not, the malicious behaviour is being added in front of your server.

Why is changing the password not enough?

Because API tokens are separate credentials that survive a password change. Anyone holding a valid token can keep making configuration changes regardless of your new password. Revoking all tokens and keys is as important as the password itself, and it is the step most commonly skipped.

What is a worker and why does it matter?

An edge function — arbitrary code that runs on every matching request before your server is involved. It is the most powerful thing that can be left behind in one of these accounts, because it can rewrite responses, inject scripts or redirect traffic entirely, with no trace on your origin.

Will the audit log tell me what happened?

Usually a great deal. It records configuration changes with timestamps and the account or token responsible. Reading it from before the first unexplained change is the fastest way to establish when access began and what else was altered while it lasted.