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.
What this symptom actually tells you
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.
Capture evidence before changing anything
- 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.
Most common causes
- 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.
Safe diagnostic and repair sequence
- 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.
How to choose between the likely causes
Do not treat Injected script option and Remote command setting as interchangeable. Malicious JavaScript or PHP-like payload is rendered by compromised code. By contrast, an option stores an attacker endpoint or token. Use two checks to separate them: Export suspicious option names, sizes, autoload flags and values safely; and search the codebase for reads of the exact option name. Those observations usually show whether the next safe move is to create a database backup and preserve the original option row or to preserve the current state and widen the investigation.
On a compromised site, containment and cleanup are separate decisions. Preserve the suspicious artefact and access logs before removing persistence, then rotate credentials only after the active path has been closed. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Do not run broad SQL replacements against serialized options without a tested backup. Length metadata can break and damage legitimate configuration.
How to verify the repair
- The malicious option and its writer are removed.
- Rendered pages, feeds and REST responses remain clean after cache flush.
- No suspicious autoloaded value reappears.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
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.