E-Commerce Site Redirected to Gambling for Two Days: How a Hijacked Cloudflare Account Hides Where Malware Scanners Can’t Look

If your website is suddenly redirecting visitors to gambling, scam, or phishing sites — but you’ve checked your WordPress files, your hosting, and your database and they all look clean — your Cloudflare account has likely been hacked. An attacker has logged in and changed something at the DNS or routing layer (most commonly an A record, a Page Rule, or a Redirect Rule) so traffic is sent to their server before it ever reaches yours. The website itself isn’t infected. The “road sign” pointing to it has been swapped. The fix is to log into Cloudflare immediately, check the audit log to find what was changed, restore the correct configuration, lock down the account with password reset and 2FA, and rotate every API token before the attacker can re-enter.

This was one of the most expensive hours of an e-commerce client’s year, and the fix took less than five minutes once we knew where to look.

A small Swiss e-commerce company contacted me in a panic. Their online store had effectively disappeared for customers. For two straight days, visitors had been redirected to gambling websites instead of the real storefront. Orders had collapsed. Marketing spend was burning. Customer complaints were piling up.

The obvious assumption was a WordPress malware infection. That’s almost always the first thing to check, and that’s where they’d already spent two days. But after a full forensic review of the site, server, and database, I had to deliver an unexpected verdict: the website wasn’t hacked at all. The compromise was one layer up — in their Cloudflare account.

This case study walks through how I ruled out a WordPress compromise, traced the redirect to a hijacked Cloudflare A record, restored the correct destination, secured the account, and got the business back online. More importantly, it covers all five places attackers can hide a redirect inside a Cloudflare account — because A records are the most common vector but not the only one, and missing the others is how cleanups fail.

If your site is redirecting visitors unexpectedly and you’ve already cleaned the WordPress files without success, this guide is for you. For urgent help, my WordPress malware removal service covers infrastructure-level investigations like this one, not just file cleanup.

The Business Impact

The company’s situation when they reached out:

• Two full days of visitors being redirected to gambling pages
• No new orders during that window
• Active marketing campaigns spending budget that produced zero conversions
• Customer support inbox filling with confused and angry messages
• Brand damage from regular customers seeing a gambling site under the company’s domain

When an e-commerce site stops converting and visitors report being redirected, every hour matters. The longer it runs, the more compounding the damage: refund requests, social media complaints, reduced trust from search engines, abandoned carts. By hour 48, this company was looking at a five-figure revenue loss and a reputation hit that would take months to rebuild.

The technical fix took five minutes. The two-day delay came entirely from looking in the wrong place.

Why Looking at WordPress First Was the Wrong Move

When visitors are being redirected to spam, the natural assumption is malware in the website. And most of the time, that assumption is correct — file-level redirects are by far the most common cause. I’ve documented several variants of that attack pattern: htaccess redirect malware, JavaScript redirect malware, and mobile-only redirect malware.

But “most of the time” isn’t “every time.” On this case, I started with a full forensic check of the site environment and found:

• File integrity: no recent unauthorized changes in WordPress core, theme files, or plugin files. Modification timestamps were consistent with legitimate update activity
• Database scan: no SQL injection payloads, no malicious content in wp_options, wp_posts, or any custom tables
• Server log analysis: no signs that the website itself was serving the redirect from the origin server. Visitors were being redirected before requests ever reached the WordPress installation
• Direct origin test: bypassing the CDN and connecting straight to the origin server returned the correct, clean website

That last finding was the diagnostic moment. If the site loads correctly when you bypass Cloudflare and hit the origin directly, but visitors using normal DNS see a redirect, the compromise is between Cloudflare and your visitors — not on your server.

The Real Cause: A Hijacked A Record

Once I had Cloudflare access, the cause was visible immediately. The attacker had changed the domain’s A record so it no longer pointed to the company’s real origin server. Instead, it pointed to an attacker-controlled IP address that served the gambling redirects.

In plain language: the website wasn’t gone. The road sign in front of it had been changed.

This is the most common Cloudflare account compromise pattern I see, and it’s well-documented in Cloudflare’s own community forums — site owners log in to find their A records pointing at IPs they don’t recognize, hosting addresses they’ve never used, or known malicious destinations.

That single change explained the entire incident:

• Why the WordPress files looked clean
• Why customers were still being redirected
• Why server-side malware scanners found nothing
• Why the store had effectively vanished without any visible WordPress compromise

How Attackers Get Into Cloudflare Accounts

The Cloudflare hijack itself is straightforward — change a DNS record, traffic flips. The harder question is how the attacker got in. From the cleanups I’ve worked on and patterns documented in the broader security community, the entry points cluster into a few categories:

• Reused passwords. A password leaked from a breach on another site is tried against the Cloudflare login. If 2FA isn’t enabled, the attacker is in.
• Phishing. The attacker sends a convincing “Cloudflare security alert” email that links to a fake login page. The owner enters credentials. The attacker uses them.
• Compromised email account. If the email tied to the Cloudflare account is itself compromised, the attacker resets the Cloudflare password through the recovery flow.
• Leaked or overscoped API tokens. Old API tokens with broad permissions, accidentally committed to public Git repos, or saved in unsecured automation scripts.
• Insider access that wasn’t revoked. A former developer or agency that still has account access months after the engagement ended (similar to the access-control story in how a former developer kept control of a WordPress site).

In this client’s case, the entry point traced back to a reused password that had appeared in a public credential dump. 2FA wasn’t enabled. That single oversight cost them two days of revenue.

The Five Places Attackers Hide Redirects in Cloudflare

This is the part most “WordPress redirect” guides miss completely. If you suspect a Cloudflare-level hijack, you have to check all five of these locations. Attackers know which ones site owners typically forget to look at.

1. DNS Records (Most Common)

Where to look: Cloudflare dashboard → your domain → DNS → Records

Compare every A, AAAA, and CNAME record against what they should be. The most common attack:

• Your @ A record (the apex domain) and www CNAME suddenly point to an unfamiliar IP address
• A new subdomain you didn’t create now exists, pointing somewhere malicious
• An MX record (email routing) has been altered to intercept email — rarer in redirect cases, but worth checking

Restore the correct values from your hosting provider’s documentation. If you don’t know what your origin IP should be, your hosting provider’s support can confirm it in seconds.

2. Page Rules

Where to look: Cloudflare dashboard → your domain → Rules → Page Rules

Page Rules are a legacy redirect/rewrite system that lets you set domain-wide URL behavior. An attacker can drop in a single Page Rule that says “for any URL on this domain, redirect to attacker-site.com/landing” and every visitor gets redirected — even if your DNS records are perfect.

This is the vector that gets missed most often, because site owners check DNS, find it correct, and conclude the Cloudflare side is clean.

3. Redirect Rules / Single Redirects (Newest)

Where to look: Cloudflare dashboard → your domain → Rules → Redirect Rules

Cloudflare introduced Redirect Rules (also called Single Redirects) as a more modern replacement for Page Rule redirects. Many account owners don’t even know this section exists, which makes it ideal hiding ground for attackers.

The pattern documented in multiple Cloudflare Community threads: site owners check DNS, check Page Rules, find nothing, and the redirect persists — because it’s actually a Single Redirect rule the attacker added, and the owner has never opened that section.

4. Workers and Snippets

Where to look: Cloudflare dashboard → Workers & Pages → Overview (and on paid plans, Snippets)

Cloudflare Workers are serverless scripts that can intercept and modify any request. An attacker who knows what they’re doing can deploy a Worker that redirects every request to a malicious destination. Workers are harder to spot than Page Rules because they’re code rather than configuration.

This vector is rarer because it requires more sophistication, but I’ve seen it on cleanups where the attacker wanted persistence that survived obvious DNS audits.

5. Nameservers (Registrar-Level)

Where to look: your domain registrar’s control panel, not Cloudflare itself

The most aggressive attack: instead of compromising the Cloudflare account, the attacker compromises the domain registrar account (GoDaddy, Namecheap, Google Domains, etc.) and changes the nameservers to point at a Cloudflare account they control. Now they can configure DNS however they want, because they own the domain’s DNS hosting entirely.

Symptoms: your real Cloudflare account looks completely normal. DNS records, Page Rules, Redirect Rules, Workers — all clean. But the domain is no longer using your nameservers at all. Visitors are routed through the attacker’s nameservers.

If you’ve checked all four Cloudflare-side locations and the redirect persists, log into your registrar and verify the nameservers match your real Cloudflare nameservers (something like NAME.ns.cloudflare.com). If they don’t, you have a registrar compromise on top of (or instead of) a Cloudflare compromise.

The Cleanup, Step by Step

Once I’d identified the malicious A record on this client’s site, the fix was procedural. Here’s the exact sequence:

Step 1: Restore the correct DNS

I changed the compromised A record back to the correct origin IP address. Within minutes (Cloudflare DNS propagation is fast), the website began loading normally for visitors again.

This was the most important immediate action — every additional minute of redirect cost money. If the customer hadn’t been able to give me Cloudflare access, the next move would have been to contact the domain registrar to point nameservers away from the compromised Cloudflare account temporarily.

Step 2: Audit every other Cloudflare hijack location

Don’t stop after fixing the visible problem. The attacker may have planted persistence in multiple places. I checked:

• Every other DNS record (in case other subdomains were redirected too)
• Page Rules — none on this account
• Redirect Rules / Single Redirects — none
• Workers and Pages — none deployed
• Email routing settings — unchanged
• SSL/TLS settings — unchanged
• Nameservers at the registrar — verified pointing to the correct Cloudflare nameservers

If any of these had been altered, the redirect could have come back even after the A record was fixed.

Step 3: Lock down the Cloudflare account

The attacker still had credentials. Fixing the DNS without securing the account would have invited a second compromise within hours. The hardening sequence:

1. Changed the account password to a new, unique, strong password not used anywhere else
2. Invalidated all active sessions via Cloudflare’s “Sign out of all devices” option
3. Enabled two-factor authentication using an authenticator app (not SMS — SMS 2FA can be bypassed with SIM swap attacks)
4. Reviewed and revoked all existing API tokens, then created new ones with minimum-necessary scopes
5. Reviewed account members and removed any users who shouldn’t have access
6. Reviewed the audit log in detail to confirm the full scope of what the attacker had done

Step 4: Verify the audit log and identify entry point

Cloudflare’s audit log (Manage Account → Audit Log) shows every change with a timestamp, the actor, and the IP address. I traced:

• The exact moment the malicious DNS change happened
• The IP address the attacker logged in from (allowed me to confirm it wasn’t anyone on the client’s team)
• Whether any other settings had been touched (none, in this case)
• How many times the attacker had logged in (twice, both during the two-day window)

That information also helped narrow down the entry point — the IP address didn’t match any authorized user, the timing didn’t correlate with any legitimate work, and there were no preceding password reset requests. Combined with the credential-dump check we ran on the client’s email, the most likely vector was a reused password.

Step 5: Validate the website itself

Even though the original investigation showed the WordPress files were clean, I did a final verification pass after the DNS fix:

• Confirmed the storefront, product pages, and checkout flow loaded correctly
• Tested order placement end-to-end
• Ran a fresh malware scan on the WordPress installation to rule out anything that might have been planted during the two-day window
• Reviewed admin user accounts, plugin list, and recent file modifications

In some incidents, attackers compromise both the Cloudflare account and the WordPress installation as redundant footholds. This client’s site was clean — the attacker had only used the Cloudflare hijack — but it’s worth verifying.

Results

• ✅ Redirect stopped within minutes of correcting the A record
• ✅ Website loaded normally for all visitors again
• ✅ Cloudflare account locked down with 2FA, fresh credentials, and rotated API tokens
• ✅ All four other Cloudflare hijack locations audited and confirmed clean
• ✅ Registrar nameservers verified correct
• ✅ WordPress site verified clean
• ✅ Audit log reviewed; full scope of attacker activity confirmed
• ✅ Customer journey end-to-end tested before declaring resolution

The total active work was around two hours. Two days of revenue had already been lost — but the bleeding stopped immediately, and the account was significantly more secure afterward than it had been before the incident.

Why This Type of Attack Is So Damaging

A Cloudflare or DNS-level hijack is uniquely painful for a few reasons:

• It bypasses every WordPress security tool. Wordfence, Sucuri, MalCare — none of them can detect a compromise that happens before requests reach your server. Your file scanners will report a perfectly clean site.
• It’s invisible to the site owner on their own connection. If the attacker uses conditional redirects (only for certain countries, only for first-time visitors, only for mobile), the owner viewing their own site may never see the issue.
• It causes maximum business damage in the shortest time. Unlike file-level malware that often runs alongside a working site, DNS hijacking can take an entire site offline for visitors instantly.
• It’s easy to misdiagnose. Owners spend hours scanning WordPress, reinstalling plugins, blaming hosting performance — while the actual problem sits one layer up.
• The attacker can change the destination at any time. Today it redirects to gambling. Tomorrow it could redirect to phishing pages designed to steal customer credentials. The attacker controls the destination as long as they control the Cloudflare account.

This is why account-level security matters as much as application-level security. A perfectly hardened WordPress site sitting behind a compromised Cloudflare account is still a hijacked website.

How to Prevent a Cloudflare Account Compromise

Most Cloudflare hijacks I see trace back to one or more of the same preventable issues. The hardening that actually moves the needle:

• Enable 2FA on Cloudflare immediately. Use an authenticator app, not SMS. This single step would have prevented the case in this post and nearly every other Cloudflare hijack I’ve cleaned.
• Use a unique password for Cloudflare. A password manager is essentially mandatory for any business account. Never reuse passwords across services.
• Audit DNS records weekly on critical domains. Especially e-commerce. A quick monthly check of your zone file catches hijacks within days instead of weeks.
• Use scoped API tokens, not global API keys. The legacy Cloudflare global API key has full account access. Scoped tokens with minimum permissions limit damage if leaked.
• Enable Cloudflare’s login notifications. Email alerts on every login from a new device or IP give you real-time awareness of unauthorized access.
• Audit account members regularly. Remove former employees, agencies, contractors. The case in how a former developer hijacked a WordPress site shows how leftover access leads to incidents.
• Lock your domain at the registrar. Most registrars offer a “domain lock” or “registrar lock” feature that prevents nameserver changes without explicit unlock. Enable it. Combine with registrar-level 2FA.
• Consider DNSSEC. DNSSEC makes DNS hijacking harder by cryptographically signing your DNS records. Cloudflare supports it natively.
• Watch for revenue anomalies. If your traffic looks normal but conversions suddenly drop, the customer journey is the first place to investigate. Conversion drops with stable traffic often signal a redirect issue.
• Secure the entire ecosystem. Cloudflare, registrar, hosting, email, admin accounts — all are part of the attack surface. A weak link anywhere can compromise the whole chain.

FAQ

How do I know if my site is redirecting because of WordPress malware or a Cloudflare hack?

Bypass Cloudflare and connect to your origin server directly (your hosting provider can give you instructions for accessing the origin via IP). If the site loads correctly that way but redirects when accessed normally, the compromise is at the Cloudflare/DNS layer, not in WordPress. If it still redirects even when bypassing Cloudflare, it’s a WordPress or server-side infection.

Why didn’t my malware scanner find anything?

Because there’s nothing to find on your server. Your WordPress files, database, and origin server are all clean. The attacker changed how visitors reach your site, not what your site contains. Standard malware scanners don’t check Cloudflare account integrity.

Can a Cloudflare account get hacked even if I have a strong password?

Yes, in two scenarios: if the password has appeared in any data breach (even from a totally unrelated site, if you reused it), or if the email account tied to your Cloudflare login is compromised — an attacker can reset the password through the recovery flow. This is why 2FA is non-negotiable on Cloudflare and on the email account associated with it.

How fast can a Cloudflare DNS hijack be fixed once I find it?

The DNS change itself takes seconds. Cloudflare’s edge propagation is fast — minutes for most visitors to start seeing the corrected destination. The full incident response (account lockdown, audit, full hijack-vector audit, verification) takes 1–2 hours of careful work.

What’s the difference between checking DNS and checking the audit log?

DNS shows you the current state. The audit log shows you every change ever made — including the moment the attacker made the malicious change, what IP they did it from, and whether they touched anything else. Always check the audit log, not just current settings, because it tells you the full scope of compromise.

Should I delete my Cloudflare account and start over after a hijack?

Usually not necessary, and creating a new account has its own complications (you’d need to reconfigure DNS, re-issue SSL certificates, redo all your rules). A thorough cleanup — password reset, all sessions invalidated, 2FA enabled, all API tokens rotated, audit log reviewed end-to-end — is sufficient in most cases. Only consider a fresh account if you have evidence the attacker still has persistent access despite the lockdown.

What if the attacker changed my registrar nameservers, not just my Cloudflare DNS?

That’s a more severe incident, because the entire DNS hosting has been moved out of your control. You’ll need to log into your registrar (where the domain is registered, separate from Cloudflare) and change the nameservers back to your real ones. Then secure the registrar account with 2FA and a strong password — a registrar compromise is just as serious as a Cloudflare compromise, and often the actual root cause when “Cloudflare-level” hijacks affect multiple Cloudflare accounts simultaneously.

Could this kind of attack also be used to steal customer data?

Yes — and this is the underrated risk. The same hijack mechanism that’s currently redirecting to gambling can be repointed at a phishing clone of your real site. Customers attempting to log in or check out enter their credentials and payment details into the attacker’s clone. The site looks identical because the attacker can also forge the SSL certificate using their own DNS control. If your site has been redirected for any length of time, audit recent customer support tickets for credential or payment fraud reports — this is the silent escalation pattern.

What Site Owners Should Take Away From This Case

The patterns from this cleanup that apply to almost every business running a website behind Cloudflare:

• A redirect problem doesn’t always mean the website files are infected. The most expensive misdiagnosis in WordPress security is assuming every redirect is a file-level malware problem.
• Cloudflare account security is part of website security. If your account credentials are weak, your domain is vulnerable regardless of how clean your WordPress installation is.
• One changed DNS record can take an entire store offline without touching WordPress. This case proved it: two days of business loss from a single configuration change.
• Always check all five hijack locations, not just DNS. Page Rules, Redirect Rules, Workers, and registrar-level nameservers each give attackers another place to hide.
• The audit log is your best forensic tool. It shows you exactly what was changed, when, and from where — better than any malware scanner for this attack class.
• Speed of investigation matters because every hour of misdirected customer traffic causes real, measurable financial damage. An e-commerce site offline for two days is materially different from a blog offline for two days.

Related Reading

• WordPress Malware Removal Service
• How to detect WordPress malware
• WordPress site redirecting to spam — htaccess redirect malware
• The complete guide to JavaScript redirect malware
• Fix WordPress mobile-only redirects
• How a former developer hijacked a WordPress site
• What to do after fixing a hacked WordPress site

Need Help With a Cloudflare or DNS Hijack?

I work on urgent WordPress security and recovery cases, including infrastructure-level hijacks that look like website hacks but are actually happening in DNS, CDN, or third-party accounts. If your site is redirecting visitors and your WordPress malware scans are coming up clean, the problem may be sitting one layer up — in Cloudflare, your registrar, or another part of your DNS chain.

I’ve recovered more than 4,500 hacked WordPress sites since 2018, including DNS hijacks, malicious redirects, account compromises, blacklist incidents, and same-day emergency cleanups. If you need help diagnosing whether the issue is in WordPress or somewhere upstream, that’s exactly the kind of investigation I do.

Get Expert WordPress Security Help — or contact me directly via the hire me page.