If your site keeps getting reinfected after a malware cleanup, the WordPress database may be the hidden source.
This guide explains how to clean WordPress database malware safely, with a focus on the infected tables, suspicious payloads, and the checks that help prevent a repeat compromise.
Why WordPress database malware is harder to spot
Unlike file-based infections, database malware often hides inside content and configuration data that WordPress needs to run.
Attackers use this approach to inject spam links, malicious redirects, JavaScript payloads, rogue admin users, and backdoor code that survives basic file scans.
The database is especially attractive because it can store persistent changes in places such as posts, widgets, options, and user metadata.
Even if you replace core files, a malicious entry in the database can restore the attack as soon as the site loads.
Common places malware appears in a WordPress database
Not every suspicious string means an infection, but certain tables are frequent targets.
Start with the areas most likely to affect site behavior and administrative access.
- wp_options — malicious redirects, injected scripts, altered site URLs, autoloaded payloads.
- wp_posts — spam pages, hidden affiliate links, injected JavaScript in post content, fake drafts.
- wp_postmeta — payloads attached to pages, plugins, or theme builders.
- wp_users and wp_usermeta — rogue administrator accounts and privilege escalation.
- wp_comments — spam content or links used for SEO abuse.
- wp_termmeta and plugin-specific tables — plugin settings, redirects, or tracking code.
Signs your WordPress database is infected
Database malware often leaves behavioral clues before you find the exact payload.
Look for sudden changes that do not match your normal publishing or admin activity.
- Unexpected redirects to unrelated domains.
- Spam links appearing in posts, widgets, or menus.
- New admin users you did not create.
- Search results or pages showing hidden content.
- Sitewide code injections in the header, footer, or scripts area.
- SEO spam pages indexed by Google Search Console.
- Repeated reinfection after cleaning files only.
What you should do before making changes
Before you edit any database records, create a full backup of the database and site files.
A backup gives you a rollback point if you remove legitimate content or break plugin settings during cleanup.
If possible, place the site in maintenance mode and change passwords for WordPress admins, hosting control panel users, SFTP/SSH accounts, and the database user.
This reduces the chance that an active attacker can reintroduce malicious content while you are cleaning.
How to clean WordPress database malware manually
Manual cleanup is the most reliable method when you need precision.
Use phpMyAdmin, Adminer, WP-CLI, or a trusted database client connected to a secure environment.
1. Export a full database backup
Download the entire database before editing.
Keep at least one untouched copy in case you need forensic review or restoration.
2. Search for suspicious patterns
Look for signs commonly associated with database malware:
- Base64-encoded strings such as long blocks starting with
PD9waHAor containing many mixed characters. - JavaScript injections like
<script>,eval(, ordocument.writeinside content fields. - Obfuscated PHP fragments in stored text.
- Unexpected external domains, especially in options or page content.
- Hidden iframes, spam anchors, or encoded redirect URLs.
3. Inspect the wp_options table first
The wp_options table is one of the most commonly abused areas because many plugins and themes store executable settings there.
Review rows with autoload enabled, since they load on nearly every request and can spread the malicious behavior quickly.
Pay special attention to values for site URL, home URL, header scripts, footer scripts, theme settings, and plugin configuration.
Compare suspicious entries with a clean backup or a known-good staging copy if available.
4. Review posts, pages, and widgets
Search wp_posts for injected links, spam text, and unexpected scripts.
Do the same for custom HTML blocks, reusable blocks, and widget content stored in the database.
Attackers often hide code in content that looks normal at a glance.
5. Check users and privileges
Examine wp_users and wp_usermeta for unknown accounts or suspicious role changes.
A compromised admin account can keep restoring malware even after database cleanup, so remove unauthorized users and reset passwords for all legitimate accounts.
6. Look for plugin or theme payloads
Some infections use plugin settings or theme options to store redirects, tracking scripts, or malicious cron behavior.
If a plugin is abandoned or unnecessary, delete it after verifying it is not responsible for a legitimate setting you need.
How to remove malicious entries safely
When you find a malicious row, remove only the infected data, not the entire table.
In many cases, you should replace the value with a clean version rather than deleting the record, especially for important settings like site URLs or plugin configuration.
If a post or page contains injected content, open the record and strip out the malicious code while preserving the valid article text.
For options that store arrays or serialized data, editing manually can break formatting, so use a plugin-aware editor, WP-CLI, or a carefully tested search-and-replace tool.
For serialized values, avoid direct text edits unless you understand how lengths are encoded.
A single character change can corrupt the record and break a plugin or theme feature.
Useful SQL checks for database malware hunting
These queries can help locate suspicious content faster.
Always test queries on a backup or staging copy first.
- Search for script tags in content fields.
- Find references to unfamiliar domains.
- List users with administrator roles.
- Inspect autoloaded options with large or encoded values.
Example patterns to search for include <script, iframe, base64, eval(, document.location, and any domain you do not recognize.
Use WP-CLI for faster detection and cleanup
WP-CLI is often faster and safer than editing raw SQL by hand, especially on production sites with large databases.
You can search tables, inspect options, and replace known malicious strings with more control than a browser-based tool.
WP-CLI is particularly useful when malware appears in multiple posts or in repeated option values.
It also helps when you need to automate checks across staging and production environments.
After cleanup: verify the site is actually clean
Removing malicious rows is only part of the job.
Confirm that the site no longer contains the payload and that no active backdoor can restore it.
- Scan files and the database with a trusted security tool.
- Recheck admin users, scheduled tasks, and plugin settings.
- Clear all caches, including CDN, server, and plugin caches.
- Regenerate WordPress salts and reset passwords.
- Review server logs for suspicious requests or POST activity.
- Submit a reconsideration request if search engines flagged the site.
How to prevent database reinfection
Long-term protection depends on closing the path that allowed the compromise.
Update WordPress core, plugins, and themes promptly, and remove extensions you no longer use.
Keep only trusted plugins from reputable developers with a history of maintenance.
Harden access with strong unique passwords, two-factor authentication for admins, limited user roles, and least-privilege database credentials.
A security plugin, web application firewall, and regular backups add useful layers, but they work best when paired with patching and account hygiene.
Schedule periodic scans of the database for unusual scripts, spam links, and unauthorized admin accounts.
Routine monitoring makes it much easier to catch an infection before it affects SEO, trust, or conversions.
When to call a WordPress security professional
If the malware keeps returning, if you see encrypted or serialized payloads you cannot safely edit, or if business-critical data may be affected, bring in a specialist.
A professional can perform forensic analysis, identify the initial infection vector, and validate that the database, files, and user accounts are all clean.