Last updated: September 16, 2026.
To check wp_options for malicious WordPress entries, export the database first, identify unusually large or recently introduced options, search values for injected domains or executable code, and trace every suspicious row back to a plugin or theme before changing it. Never delete an unfamiliar option only because its value looks complex.
The wp_options table stores site settings, plugin configuration, transients, scheduled-event data, and sometimes large serialized arrays. Attackers can also use it to preserve redirects, spam, or injected code. A careful audit distinguishes unfamiliar data from malicious data and protects serialized values from accidental corruption.
What is the wp_options table?
The wp_options table is WordPress’s shared key-value store for site and plugin settings. Its actual name uses the database prefix from wp-config.php, so a site may use wp_options, site_options, or another prefix. WordPress Multisite also keeps network-wide settings in a separate sitemeta table.
The official WordPress Options API documentation explains that plugins should read and write these records through functions such as get_option(), add_option(), and update_option(). Values can be plain strings or serialized arrays and objects, which is why editing them directly is risky.
When should you inspect wp_options for malware?
Inspect wp_options when visitors are redirected to unfamiliar domains, spam appears only for search-engine traffic, a removed plugin seems to return, administrator settings change without explanation, or a security scan identifies a suspicious option. Also inspect it during a full post-compromise review, even if infected PHP files have already been replaced.
Database inspection is only one part of incident response. A clean options table does not prove that core files, plugins, themes, uploads, user accounts, or scheduled tasks are clean. Use this guide alongside the WordPress malware cleanup comparison and the rogue administrator account checklist.
How do you back up the database before inspecting it?
Create a database export before running queries or deleting an option. Store the export outside the public web root, record the time, and confirm that the resulting file is not empty. A backup gives you a recovery point if a legitimate setting or serialized value is changed accidentally.
With WP-CLI, run:
wp db export before-options-audit.sql
ls -lh before-options-audit.sqlMove the SQL file to protected storage after confirming it exists. Do not leave database exports in public_html, htdocs, or another web-accessible directory. Database dumps may contain password hashes, email addresses, API settings, and other sensitive material.
How do you find the real options table name?
Use WP-CLI to obtain the configured database prefix instead of assuming it is wp_. The prefix is defined by $table_prefix in wp-config.php, and many security-conscious installations change it.
wp db prefixThe examples below use $(wp db prefix)options, which asks WP-CLI for the prefix and appends options. If your shell or hosting panel does not support command substitution, copy the returned prefix and insert it manually.
Which wp_options entries should you review first?
Review large values, unfamiliar autoloaded rows, options added by recently removed plugins, and values containing unexpected domains or executable-code markers. None of those signals proves malware by itself. Cache plugins, page builders, analytics tools, and e-commerce extensions routinely create large or encoded settings.
List the largest option values:
wp db query "SELECT option_id, option_name, LENGTH(option_value) AS bytes, autoload FROM $(wp db prefix)options ORDER BY bytes DESC LIMIT 40;"Large values deserve explanation because they can hide injected content and can also hurt performance when loaded automatically. Record the option name, owning plugin, size, and reason before deciding whether it should remain.
How do you search wp_options for suspicious strings?
Search for indicators observed in the incident, such as an injected domain, spam phrase, file path, or function name. The official wp db search command searches text columns and can limit the scan to the options table.
Search for a known malicious domain:
wp db search 'bad-domain.example' $(wp db prefix)options --fields=table,column,primary_key_value,match --format=tableSearch for a suspicious PHP function only when it appeared elsewhere in the incident:
wp db search 'base64_decode' $(wp db prefix)options --fields=table,column,primary_key_value,match --format=tablebase64_decode, long encoded strings, JavaScript fragments, and <iframe> tags can all be legitimate. Treat them as leads, not automatic proof. A theme may store custom code, an optimization plugin may encode configuration, and widgets may contain HTML.
How do you review external URLs stored in wp_options?
List options containing HTTP or HTTPS URLs, then investigate domains you do not recognize. Expect to see the site URL, update services, plugin APIs, payment providers, CDNs, webhooks, and license endpoints. A domain becomes more suspicious when it is newly registered, unrelated to installed software, obfuscated, or used in a redirect visitors actually experience.
wp db query "SELECT option_id, option_name, LEFT(option_value, 220) AS preview FROM $(wp db prefix)options WHERE option_value REGEXP 'https?://' ORDER BY option_id;"Do not paste complete option values into a public ticket. They may contain tokens or personal data. Share only the smallest redacted fragment needed for investigation.
How do you trace an option back to a plugin or theme?
Search the installed codebase for the exact option name. Developers usually call get_option(), update_option(), or add_option() with that name. Finding those calls establishes ownership more reliably than guessing from a prefix.
grep -R --line-number --fixed-string "suspicious_option_name" wp-content/plugins wp-content/themesThen verify whether the owning extension is active, whether it came from a trusted source, and whether the stored value matches the feature it supports. If the extension was removed, consult its uninstall documentation before deleting leftovers. Some plugins deliberately retain settings so they can be restored after reinstallation.
Why should you avoid editing serialized options in SQL?
Serialized PHP values record the byte length of each string. Changing a domain, path, or code fragment with a raw SQL replacement can leave those lengths incorrect and make the setting unreadable. JSON values can also fail if quotes or escape characters are changed incorrectly.
Prefer the owning plugin’s settings screen, uninstall routine, or WordPress API. If a confirmed malicious value must be changed programmatically, retrieve it with get_option(), modify the decoded structure, and save it with update_option() in a controlled maintenance script. Test the change on a copy first.
How do you delete a confirmed malicious option safely?
Delete an option only after you have preserved evidence, identified the row, confirmed that no legitimate component owns it, and created a current backup. Record the option ID, name, a hash or redacted sample of the value, and the reason for removal in the incident log.
Use the WordPress API through WP-CLI:
wp option delete confirmed_malicious_optionAvoid broad commands such as deleting every option containing a word. One option value may contain settings for dozens of unrelated features, and a partial match is not sufficient evidence.
What should you check after removing an entry?
Verify the site as both a logged-out visitor and an administrator. Test the original redirect or spam symptom, clear each cache layer, run another database search for the indicator, and check whether the option returns. Reappearance suggests that malicious PHP, a compromised account, a scheduled event, or an external integration is recreating it.
- Clear the page cache, object cache, CDN cache, and browser cache.
- Repeat the exact
wp db searchcommand used before cleanup. - Load several affected URLs from a private window and a mobile connection.
- Review administrator accounts and recent user changes.
- Audit scheduled tasks using the related WP-Cron guide.
- Verify core and plugin files against trusted checksums.
- Rotate WordPress, hosting, database, SFTP, and API credentials as required by the incident.
The existing guide to verify WordPress core files with WP-CLI can confirm whether repository-distributed core files match official checksums. A passing result does not inspect the database, uploads, premium plugins, or stolen credentials.
What evidence suggests the database is still being reinfected?
An option that returns after verified deletion is strong evidence that another component is writing it again. Capture the re-creation time, inspect PHP and web-server logs around that moment, review WP-Cron events, and compare recent file changes. Do not repeatedly delete the symptom while leaving the writer active.
If the value appears only after an administrator login, inspect browser extensions, administrator devices, and dashboard-injected scripts. If it appears on a schedule, examine WordPress cron and the server’s system cron. If it appears immediately on every request, inspect active plugins, must-use plugins, the theme, and drop-ins such as object-cache.php.
Frequently asked questions
Is every encoded wp_options value malicious?
No. WordPress and its plugins legitimately store serialized arrays, JSON, hashes, tokens, compressed data, and Base64-encoded values. An encoded value becomes suspicious when its owner cannot be identified, it matches another incident indicator, it executes or injects code unexpectedly, or it reappears after removal.
Can a security plugin clean wp_options automatically?
Some scanners detect known database malware or SEO spam, but automated detection is not complete. Database settings vary widely across plugins, so a tool may miss a novel payload or flag legitimate custom code. Use scanner results as evidence and verify ownership before deleting any row.
Does changing the database prefix remove malware?
No. Changing the table prefix does not remove malicious rows, files, accounts, or credentials. It may also break a site if done incompletely. Focus on the confirmed persistence mechanism and complete the broader recovery process.
Should you delete expired transients during an audit?
Expired transients are usually maintenance clutter, not evidence of compromise. Cleaning them may simplify review, but keep that task separate from incident remediation. Do not claim that deleting transients removes malware unless a specific malicious transient has been confirmed.
Leave a Reply