WordPress Database Malware: SQL Detection & Cleanup Guide

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:

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

Hidden admin users — extra rows in wp_users with admin capabilities in wp_usermeta, sometimes regenerated on every page load by a backdoor file.
Malicious redirects — JavaScript or meta-refresh stored in wp_options (autoloaded), header/footer scripts, or page builder header settings.
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.
Obfuscated payloads — eval(base64_decode(...)), gzinflate, str_rot13, hex-encoded JS, String.fromCharCode chains stored inside option values, postmeta, or even widget settings.
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:

Cleaning files but skipping the database. The reason this guide exists.
Deleting suspicious users via DELETE FROM wp_users. Orphans the meta and breaks content authorship. Use wp user delete.
Using UPDATE ... REPLACE on serialized data. Corrupts plugin settings. Use wp search-replace instead.
Not rotating salts. The attacker’s auth cookies still work. They walk back in.
Restoring an old “clean” backup without scanning it. Most backups are already infected — sites are usually compromised weeks before the owner notices.
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.

WordPress Database Malware: The Complete Detection & Cleanup Guide (with Real SQL Queries)