An encoded blob in wp_options is half of a loader. The other half is a file.

The options table is where WordPress and every plugin keep settings, which makes it a good hiding place. It holds hundreds or thousands of rows on a typical site, many of them long serialised arrays nobody reads by hand, and none of them is checked by a file-integrity scan. Reinstalling WordPress core, replacing every plugin from a clean download, even restoring the theme — none of that touches a single row.

Rows flagged for autoload are loaded into memory on every request, so the payload is always one function call away. The loader that makes that call is typically short: read an option, decode it, execute it. Short code is easy to miss in a large theme file and easy to hide in a must-use plugin with an innocent name.

This is a documented pattern, not a theory. In the ClickFix incident covered on this site, base64-encoded script fragments and loader data were stored in options records on affected sites, alongside an unauthorised call in the active theme’s functions.php and a .user.ini directive — four layers, each able to bring the infection back.

$ wp db query "SELECT option_name, autoload, LENGTH(option_value) AS bytes FROM wp_options WHERE option_value LIKE '%base64_decode%' ORDER BY bytes DESC"
+---------------------------+----------+-------+
| option_name               | autoload | bytes |
+---------------------------+----------+-------+
| wp_cache_sys_a91f         | yes      | 48213 |
+---------------------------+----------+-------+
$ grep -rln "wp_cache_sys_a91f" wp-content/
wp-content/mu-plugins/cache-helper.php
# the row is the payload; the file that reads it is the trigger

1. 01

   Search the values for decoding and execution functions

   Every row whose value mentions a function that decodes or executes code, largest first:

   SQL · read-only

   SELECT option_id, option_name, autoload, LENGTH(option_value) AS bytes
   FROM wp_options
   WHERE option_value LIKE '%base64_decode%'
      OR option_value LIKE '%gzinflate%'
      OR option_value LIKE '%str_rot13%'
      OR option_value LIKE '%eval(%'
      OR option_value LIKE '%<script%'
   ORDER BY bytes DESC;

   A match is a lead, not a verdict: security and caching plugins legitimately store strings like these in their own settings and logs. What matters is who owns the row, which the next sections cover.

2. 02

   List the largest autoloaded rows

   Encoded payloads are often large. Since WordPress 6.6 the autoload column can hold on, off, auto, auto-on and auto-off as well as the older yes and no; this covers every value WordPress treats as autoloaded:

   SQL · read-only

   SELECT option_name, autoload, LENGTH(option_value) AS bytes
   FROM wp_options
   WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
   ORDER BY bytes DESC
   LIMIT 25;

   Most of the top 25 will be recognisable plugin settings. A large row with a name that matches no installed plugin, theme or core option deserves a closer read.

3. 03

   Look for long unbroken encoded strings

   A payload with its function names split or encoded will not match the first query. A long run of base64 characters will:

   SQL · read-only

   SELECT option_name, autoload, LENGTH(option_value) AS bytes
   FROM wp_options
   WHERE option_value REGEXP '[A-Za-z0-9+/]{300,}'
   ORDER BY bytes DESC;

   Expect some legitimate hits — embedded images, licence keys, cached API responses. On a large table the regular expression is slow; run it off-peak.

4. 04

   Read one row without executing it

   The database client is the safest way to read a value. With WP-CLI, the db commands load only wp-config.php for the credentials, not plugins or themes:

   WP-CLI

   $ wp db query "SELECT option_value FROM wp_options WHERE option_name = 'OPTION_NAME'"

   Read it as text. Do not paste it into a PHP file, a browser console, or an online “decoder” that runs code. To see what the encoding hides, the decoder linked below works entirely in your browser and executes nothing.

The decisive step is finding what executes the payload. Search the files for the decoding and execution functions the loader needs, and read every match outside a plugin you can name:

$ grep -rlE "base64_decode|gzinflate|str_rot13|eval\(" wp-content/ wp-config.php

Expect noise: many legitimate plugins use base64_decode for ordinary purposes. Narrow it to the places loaders favour — wp-content/mu-plugins, drop-ins such as object-cache.php and advanced-cache.php in wp-content, the active theme’s functions.php and its includes, and any PHP file under uploads, where PHP should not exist at all.

Check the layers above WordPress too. A loader can sit in a .user.ini auto_prepend_file target, in a modified core file, or in wp-config.php itself. The guides on those layers cover what to look for in each.

1. 01

   Preserve the evidence

   Export the whole database to a directory outside the web root, then copy the loader file with its timestamps:

   shell

   $ mkdir -p ~/incident
   $ wp db export ~/incident/before-cleanup.sql
   $ cp -p wp-content/mu-plugins/SUSPECT.php ~/incident/

   Record the SHA-256 of each copy. This export is the only record of what the payload was.

2. 02

   Put the site into maintenance mode or block traffic

   Every request runs the payload while you work. Containment first, if the business can tolerate it; agree what stays online.

3. 03

   Remove the loader

   Delete the rogue file, or remove the injected lines from a theme or core file — replacing core, plugins and themes from official sources is safer than hand-editing.

4. 04

   Then delete the row

   Only once the loader is gone, and only after confirming no installed plugin owns the name:

   WP-CLI

   $ wp option delete OPTION_NAME

   If the value was injected into a legitimate option rather than a new one, restore that option from the plugin’s settings screen instead of deleting it.

5. 05

   Rotate everything the payload could read

   It ran with the site’s full access: database password, WordPress salts and keys, administrator passwords and application passwords, hosting, SFTP and API credentials. Change them from a device that is not part of the incident.

6. 06

   Verify after traffic resumes

   Re-run the queries above the next day and again a few days later. A row that reappears means a loader, a scheduled task or a credential was missed.

Code that can write one option can write any row. When a payload turns up in wp_options, check the neighbouring places an attacker with database access uses: script injections in post content and widgets, a tampered role definition in the user_roles option, an extra administrator in usermeta, and scheduled events in the cron option.