If a WordPress site is hacked, the wp_options table is often one of the first places attackers hide persistence, redirect code, and backdoor settings.
This guide shows how to clean the wp_options table after hack incidents safely, so you can remove malicious entries without damaging legitimate site configuration.
Why the wp_options Table Is a Common Target
The wp_options table stores core WordPress settings, plugin configuration, theme options, widget data, and cached values.
Because it loads frequently and can contain autoloaded records, attackers often inject malicious data here to make their changes survive updates, logouts, and even partial cleanup efforts.
Common attack goals include:
- Injecting JavaScript or PHP-like payloads into theme and plugin settings
- Changing the site URL or home URL to enable redirects
- Adding rogue administrator-related configuration values
- Storing malicious code in autoloaded options that run on nearly every request
- Planting payloads used by compromised plugins or themes
Before You Edit Anything
Cleaning wp_options is safest when you work from a verified backup and a known-good staging copy.
If possible, put the site in maintenance mode, collect logs, and confirm that the infection is not also present in files, database tables, cron jobs, or user accounts.
Take these preparation steps first:
- Create a full database backup
- Export the wp_options table separately
- Note the current WordPress version, active theme, and active plugins
- Change all passwords, including hosting, database, SFTP, WordPress admin, and salts if needed
- Scan the site files so you are not cleaning the database while leaving the file-based infection intact
How to Identify Suspicious Entries in wp_options
The fastest way to begin is to review rows with unfamiliar names, suspicious values, or unusually large content.
Pay special attention to autoloaded options because these are loaded on most page requests and can hide persistent malware.
What to look for
- Option names that resemble random strings or imitate plugin names
- Serialized data with unexpected base64 blobs or obfuscated code
- Options containing
eval,base64_decode,gzinflate,str_rot13, or long encoded payloads - Strange redirects inside
siteurl,home, or plugin-specific settings - Injected scripts in theme options, widget data, or custom HTML blocks
- Large autoload values that do not match installed plugins or theme features
Useful database queries can help you locate suspicious records, especially if you have direct database access through phpMyAdmin or MySQL client tools.
Useful checks
- Review all autoloaded options sorted by size
- Compare current settings with a clean staging copy
- Search option values for encoded payload markers
- Check recent modifications in your database logs if available
How to Clean wp_options Table After Hack Safely
When you know which row is malicious, remove only the harmful content and preserve the original structure of legitimate options.
This matters because many WordPress settings are serialized arrays; editing them incorrectly can break plugin configuration, widget layouts, or site behavior.
Step 1: Confirm the option is not legitimate
Verify the option name against installed plugins, the active theme, and standard WordPress core settings.
If you are unsure, compare the row with a clean installation or a backup made before the hack.
Step 2: Back up the individual row
Before deleting or editing any suspicious entry, export the row or copy the exact value to a secure text file.
This gives you a rollback point if the option turns out to be necessary for the site.
Step 3: Remove the malicious content
If the row is clearly injected malware, delete it entirely.
If it belongs to a legitimate plugin but contains malicious text, replace only the infected portion and preserve the data structure.
For serialized values, use tools that can safely edit serialized data rather than manually changing the string length.
Step 4: Re-check autoload settings
Look at whether the malicious option is marked as autoloaded.
If so, remove it from the autoload set and ensure no duplicate version remains.
Attackers often rely on autoload so their payload executes early and repeatedly.
Step 5: Flush caches and re-scan
After cleaning, clear page cache, object cache, CDN cache, and browser cache.
Then re-scan the database and files to confirm the payload is gone and that no reinfection remains in a companion table or file.
Which wp_options Rows Deserve Extra Attention?
Some option names are more likely to be abused because they control high-impact behavior.
Inspect these areas carefully during a cleanup.
Site identity and redirect settings
siteurlhomerewrite_rules
Attackers may change these values to send traffic to a malicious domain or alter how WordPress resolves pages.
Theme and widget settings
templatestylesheettheme_mods_*widget_*
Theme-related options can hold injected HTML, JavaScript, or malicious shortcodes that display hidden links and redirects.
Plugin configuration
Any option tied to an installed plugin should be checked, especially security plugins, page builders, backup tools, caching plugins, and forms plugins.
Malicious actors frequently hide code in settings that appear normal at a glance.
How to Remove Malicious Autoloaded Options
Autoloaded options are particularly important because WordPress loads them on nearly every request.
If a suspicious row is autoloaded, deleting or disabling it can immediately reduce risk and stop repeated execution.
- Identify the option name and value
- Confirm it is not required by core, theme, or plugin code
- Delete the row or change autoload to
noif it is valid but oversized - Test the site frontend, login page, and admin dashboard after the change
Be cautious with performance-related options.
Some large rows are not malware, but they may still need optimization if they are bloating the database.
Verify the Cleanup Across the Rest of WordPress
Cleaning wp_options is only part of recovery.
A persistent hack often includes changes in other database tables, file injections, rogue users, or scheduled tasks that restore the infection.
Check these areas next
- wp_users and wp_usermeta: look for unknown administrator accounts or privilege escalation
- wp_posts and wp_postmeta: inspect injected scripts, hidden links, and malicious iframes
- wp_cron: review scheduled events that reinstall malware
- wp-content files: scan themes, plugins, mu-plugins, and uploads for web shells or obfuscated code
- .htaccess and server config: check for redirects or access rules added by the attacker
How to Harden the Site After Cleanup
Once the database is clean, reduce the chance of reinfection by tightening access and monitoring change points.
WordPress hardening is especially important when the compromise originated from weak credentials, outdated plugins, or insecure hosting.
- Update WordPress core, plugins, and themes
- Remove unused plugins and themes
- Use least-privilege database and hosting credentials
- Restrict wp-admin access where appropriate
- Enable file integrity monitoring
- Use a security plugin or server-side malware scanner
- Rotate authentication salts in
wp-config.php - Audit database permissions so only trusted users can modify wp_options
When to Restore Instead of Manually Editing
If the infection is widespread, manual cleanup can miss hidden payloads or break serialized data.
A restore from a clean backup is often faster and safer when you have a verified pre-hack snapshot and the current site state is heavily compromised.
Consider restoration if:
- Multiple unknown options exist across the table
- You find reinfection after repeated cleanup
- Serialized data has been tampered with in several rows
- The site contains web shells, backdoors, or modified core files
- You cannot confidently identify every malicious change
Quick Review Checklist
- Backup the database before editing
- Compare wp_options with a clean reference
- Remove or repair suspicious autoloaded options
- Verify siteurl, home, theme, and plugin settings
- Check related tables, scheduled tasks, and files
- Harden credentials and update all software