What matters first: Autoloaded options are available on nearly every request, making them attractive for persistence. The option may contain code directly, a remote URL or settings used by a compromised plugin.
Treat wp_options as a persistence surface
Large or suspicious values are clues, but legitimate plugins also store serialized and encoded data. Trace where the option is read and how it affects output.
Preserve option metadata and the code that consumes it
- Export suspicious option names, sizes, autoload flags and values safely.
- Search the codebase for reads of the exact option name.
- Compare creation or modification timing with the incident.
- Inspect transients, site options and multisite tables when relevant.
Encoded and serialized values need context
- Injected script option: Malicious JavaScript or PHP-like payload is rendered by compromised code.
- Remote command setting: An option stores an attacker endpoint or token.
- Modified plugin settings: A legitimate option is changed to load untrusted content.
- Serialized persistence: Nested data hides malicious values from simple text searches.
Remove the writer before removing the stored value
- Create a database backup and preserve the original option row.
- Remove or correct the consuming malicious code before deleting the value.
- Use WordPress-aware tools to update serialized data safely.
- Flush object cache and verify the option does not return from cron or remote sync.
Injected script or remote-control setting?
An injected script option becomes harmful when compromised code reads and renders it; a remote-control setting instead supplies an endpoint, token or command source to another component. Trace reads of the exact option name before editing the value. That tells you whether cleanup must focus on output injection, on the writer, or on both.
Database persistence often works alongside earlier execution paths. Inspect mu-plugins that load on every request and scheduled tasks that can recreate deleted values. Removing only the option is temporary if either writer remains active.
Avoid broad SQL replacements in serialized data
Do not run broad SQL replacements against serialized options without a tested backup. Length metadata can break and damage legitimate configuration.
Verify cache and scheduled tasks do not restore it
- The malicious option and its writer are removed.
- Rendered pages, feeds and REST responses remain clean after cache flush.
- No suspicious autoloaded value reappears.
Close the incident only when the malicious value and the code that writes or consumes it are removed, caches no longer expose the payload, and repeated cron or normal application cycles do not recreate the option.
WP REPAIR INCIDENT STANDARD
How to narrow the fault without guessing
Large or suspicious values are clues, but legitimate plugins also store serialized and encoded data. Trace where the option is read and how it affects output.
Export suspicious option names, sizes, autoload flags and values safely.
Search the codebase for reads of the exact option name.
Compare creation or modification timing with the incident.
Inspect transients, site options and multisite tables when relevant.
What must be verified
- The malicious option and its writer are removed.
- Rendered pages, feeds and REST responses remain clean after cache flush.
- No suspicious autoloaded value reappears.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Does a large or oddly encoded value in wp_options always mean malware?+
No. Legitimate plugins routinely store large serialized or encoded data in options, so size and encoding alone are not proof of compromise. You need to trace where the specific option is read in code and how it affects site output before concluding it is malicious.
Can I just find-and-replace the bad value directly in the database?+
Running broad SQL replacements against serialized PHP data without a tested backup is a common way to break the option, because serialized strings carry length metadata that a text-level edit can corrupt. Use WordPress-aware tools that understand serialization, and always keep a database backup and the original row before changing anything.
Why does the malicious option keep coming back after I delete it?+
If the code that writes the option is still active, deleting the row only removes the current copy while cron jobs, remote sync or the compromised plugin recreate it on the next run. Remove or correct the consuming malicious code first, then delete the value and confirm it does not return after a cache flush.
Where else besides wp_options should I check for the same kind of payload?+
Transients, site options and, on multisite installs, the network-level options tables can hold the same kind of autoloaded payload. These should be inspected alongside wp_options since they share the same attack surface of code executing on nearly every request.