How to Find and Remove WordPress Database Malware

You scanned your files. You replaced WordPress core. You deleted the suspicious plugins. But your site is still redirecting to spam, showing malicious popups, or ranking for pages you never created.

If that sounds familiar, the infection may still be hiding in your database.

This is one of the most common reasons a hacked WordPress site still behaves as compromised after a file cleanup. The visible malware is gone, but the persistence is still sitting inside tables like wp_options, wp_posts, wp_postmeta, wp_users, or wp_usermeta.

I’ve cleaned 4,500+ hacked WordPress sites , and database malware is one of the patterns I see again and again when a site “looks cleaner” but is still not actually clean.

If you are not sure whether the infection is in files, the database, or both, start with how to detect WordPress malware. If the site is already compromised and you want expert help, see my WordPress malware removal service.

---

Quick Answer: Where WordPress Database Malware Usually Hides

If your hacked site still redirects or shows spam after file cleanup, check these first:

• wp_users and wp_usermeta: hidden admin users and role changes
• wp_options: redirect scripts, injected JavaScript, and suspicious autoloaded data
• wp_posts and wp_postmeta: spam pages, cloaked content, and poisoned SEO metadata
• plugin-specific custom tables: fake settings, stored payloads, or malicious code snippets

That is why a file cleanup alone is often not enough. If you miss the database layer, the malware can come back, keep redirecting traffic, or continue harming your search visibility. I explain that reinfection pattern in more detail here: why WordPress malware keeps coming back.

---

Why Database Malware Is So Dangerous

File-based malware is easier to notice because it usually shows up as a suspicious PHP or JavaScript file in a place where it does not belong. Database malware is harder because it hides inside legitimate-looking rows.

Attackers use the database to:

• Create ghost admin accounts so they can log back in later
• Inject spam links or cloaked content into posts and pages
• Store redirect scripts that load on every request
• Overwrite SEO metadata so Google shows hacked titles or descriptions
• Persist the infection after visible files have already been deleted

This is especially common in SEO spam cases like the Japanese keyword hack and the WordPress pharma hack.

---

Step 0: Back Up the Database First

Do this before touching anything.

There is no easy undo button when you delete rows or run the wrong search-and-replace. Export a full .sql backup in phpMyAdmin or use a trusted backup method before you edit any table.

If you skip the backup and remove the wrong data, you can break the site faster than the malware did.

---

Step 1: Check for Ghost Admin Users in wp_users and wp_usermeta

The first thing many attackers do is create a backup admin account.

Sometimes it looks obvious. Sometimes it uses names like support, admin01, or wp-security so it blends in. And sometimes the visible username is only part of the problem — the real privilege escalation is stored in wp_usermeta.

That is why I do not stop at wp_users. I also verify the matching role and capability records in wp_usermeta.

1. Open phpMyAdmin from your hosting panel.
2. Select the correct WordPress database.
3. Open wp_users and review every user.
4. Look for unknown email addresses, usernames you did not create, or accounts created recently.
5. Then check wp_usermeta for suspicious role assignments tied to those user IDs.

If you want a full walkthrough of this pattern, read how to find and remove hidden admin users in WordPress and how hackers create hidden admin users.

---

Step 2: Check wp_options for Redirects, JavaScript, and Autoloaded Malware

The wp_options table is one of the first places I inspect on a hacked site that still redirects after file cleanup.

Why? Because anything stored there can load globally, especially if it is autoloaded. Attackers know that. They use wp_options to store JavaScript injectors, external script tags, spam payloads, or settings that trigger malicious behavior on every page load.

1. Open the wp_options table.
2. Verify the siteurl and home rows first.
3. Then review suspicious rows with autoload = yes.
4. Look for strange domains, injected scripts, encoded strings, hidden iframes, or long values that clearly do not belong.

If your site is still redirecting after you cleaned the files, there is a good chance the trigger is stored here or in another database table that loads early.

A related real-world example is this case study: failed Google blacklist review caused by hidden database malware.

---

Step 3: Search the Database for Common Malware Patterns

You cannot review every row manually on a hacked site. You need to search intelligently.

In phpMyAdmin, use the Search tab and search the full database for suspicious strings like:

• base64_decode
• eval(
• <script
• iframe
• display:none
• unknown domains
• casino, pharma, or Japanese spam terms

Be careful with interpretation. Context matters. Some legitimate plugins store scripts or encoded values. What you are looking for is not just a keyword — you are looking for a keyword in the wrong context.

Examples of strong warning signs:

• a suspicious external domain inside wp_options
• spam links hidden in wp_posts
• SEO metadata rewritten in wp_postmeta
• random obfuscated code inside a setting that should only contain plain text

---

Step 4: Check wp_posts and wp_postmeta for Spam Injections

If your site has been hit by SEO spam, hacked product pages, or cloaked content, the infection is often stored in wp_posts and sometimes reinforced through wp_postmeta.

This is where I look for:

• Japanese spam pages
• pharma links
• injected script tags
• hidden links
• SEO title and description poisoning

A safe first step is a read-only query like this:

SELECT ID, post_title 
FROM wp_posts 
WHERE post_content LIKE '%<script%'
   OR post_content LIKE '%iframe%'
   OR post_content LIKE '%display:none%';

You can also search by a known bad domain if you already identified it elsewhere.

If the infection is massive, do not start running delete queries blindly. First confirm the exact malicious string, export a backup, and then use a safer method to remove only the injected part. For large cleanups, I often use a controlled search-and-replace workflow after I validate the payload.

If Google is already showing hacked spam under your domain, these are the next best reads:

• How to fix the Japanese keyword hack
• How to stop pharma hack spam in Google
• Google blacklist removal service

---

Step 5: Do Not Forget Plugin-Specific Tables

Not every WordPress infection lives in the default core tables.

Some malware is stored in plugin tables created by page builders, SEO plugins, security plugins, or code snippet tools. If the site is still acting hacked and you cannot find the payload in the obvious places, review custom tables too.

This matters especially on sites where the infection touches SEO settings, custom forms, header/footer scripts, or snippet plugins.

---

Step 6: Clean Up the Cause, Not Just the Database

If you clean the database but do not fix the original entry point, the site can be reinfected quickly.

After the database cleanup, I strongly recommend:

• checking for hidden admin users again
• reviewing suspicious plugins and mu-plugins
• checking .htaccess and redirect rules
• reviewing cron-based persistence
• changing database, FTP, hosting, and WordPress passwords
• rotating WordPress salts

This is the part many site owners skip, which is why the malware comes back. If you have not read it yet, go here next: what to do after fixing a hacked WordPress site.

---

FAQ: WordPress Database Malware

Can WordPress malware live only in the database?

Yes. Some infections are almost entirely database-based, especially spam injections, ghost admin setups, poisoned SEO metadata, and redirect triggers stored in options or postmeta.

Why is my site still redirecting after I cleaned the files?

Because the redirect trigger may still be stored in wp_options, another database table, or a hidden server-side persistence point. File cleanup alone does not always remove the logic that causes the redirect.

Which WordPress tables should I check first for malware?

Start with wp_users, wp_usermeta, wp_options, wp_posts, and wp_postmeta. Then expand to custom plugin tables if the infection is still active.

Can I just delete suspicious rows directly in phpMyAdmin?

Not safely unless you fully understand what they do. Always back up first, confirm the malicious payload, and avoid destructive edits until you are sure you are not deleting legitimate site data.

Why does Google still show spam even after I removed the files?

Because the spam may still exist in the database, or Google may still be processing hacked URLs and metadata that were already indexed. In those cases, you need both malware cleanup and search cleanup.

---

Final Checklist

• [] Back up the database first
• [] Review wp_users and wp_usermeta
• [] Verify siteurl and home in wp_options
• [] Search for suspicious strings across the full database
• [] Inspect wp_posts and wp_postmeta for spam and SEO poisoning
• [] Review custom plugin tables if needed
• [] Change database, hosting, FTP, and WordPress credentials
• [] Rotate salts after cleanup

---

Need Help Cleaning Hidden Database Malware?

If your site still redirects, shows malicious popups, or ranks for spam after you already cleaned the files, the infection may still be living in the database.

I manually clean WordPress malware, remove hidden persistence, and fix hacked sites that scanners and quick cleanups miss.

Get expert WordPress malware removal help