A WP-Cron event is only a name and a time. The danger is the code that answers to it.

Everything WP-Cron knows lives in a single option called cron. It is a serialised array keyed by Unix timestamp; under each timestamp sit the hooks due then, their arguments, and the schedule they repeat on. WordPress core keeps its own housekeeping there — update checks, trash emptying, expired transients — and plugins add theirs.

An event does not contain code. When it falls due, WordPress fires the hook by name, and whatever callbacks are registered for that name run. That splits a malicious event into two parts: the schedule entry in the database, and the add_action call in a file that connects the hook to real code. Malware often does both in the same file: it registers the callback and, if the event is missing, schedules it again.

Because WP-Cron runs from page views, it gives an attacker a timer on hosting where they have no shell access and no server crontab — which is why “the malware comes back every few minutes” on shared hosting so often traces back here.

$ wp cron event list --fields=hook,next_run_relative,recurrence --skip-plugins --skip-themes
+--------------------------------------+-------------------+------------+
| hook                                 | next_run_relative | recurrence |
+--------------------------------------+-------------------+------------+
| wp_privacy_delete_old_export_files   | 38 minutes        | 1 hour     |
| wp_version_check                     | 4 hours 2 minutes | 12 hours   |
| wp_scheduled_delete                  | 9 hours           | 1 day      |
| wp_maintenance_sync_7c1e             | now               | 1 minute   |
+--------------------------------------+-------------------+------------+
$ grep -rn "wp_maintenance_sync_7c1e" wp-content/
wp-content/uploads/2026/09/.thumbs.php:4:add_action( 'wp_maintenance_sync_7c1e', 'wpms_run' );

1. 01

   List the events and their schedules

   Hook, time to the next run, and how often it repeats:

   WP-CLI

   $ wp cron event list --fields=hook,next_run_relative,recurrence --skip-plugins --skip-themes

   Core hooks have names beginning wp_ or describing housekeeping, on schedules from hourly to weekly. Plugin hooks usually carry the plugin’s prefix. A hook that matches nothing installed, or one repeating every minute or so, is the lead.

2. 02

   List the schedules that exist

   A one-minute recurrence needs a custom schedule, and custom schedules are registered in code:

   WP-CLI

   $ wp cron schedule list

   This one loads plugins on purpose, because custom schedules only exist while the code that registers them is loaded. An interval no installed plugin explains points at the file that defines it.

3. 03

   Keep the raw option, with arguments

   The list hides each event’s arguments, which can carry URLs or encoded data. Save the whole option outside the web root:

   shell

   $ mkdir -p ~/incident
   $ wp option get cron --format=json --skip-plugins --skip-themes > ~/incident/cron-option.json

   This is the evidence of what was scheduled, and when. Take it before deleting anything.

4. 04

   Or read it straight from the database

   Without loading WordPress at all; substitute your table prefix:

   SQL · read-only

   SELECT option_value
   FROM wp_options
   WHERE option_name = 'cron';

   The value is serialised; read it as text and do not edit it by hand.

1. 01

   Search for the hook name

   Everywhere code can live, not only plugins:

   shell

   $ grep -rn "HOOK_NAME" wp-content/ wp-config.php

   A match inside a plugin you installed and can name usually explains the event. A match in mu-plugins, a drop-in, the uploads directory, or a theme file nobody edited is the callback.

2. 02

   Read the callback, do not run it

   Open the file in a text editor and follow the function named in add_action. Record its path, size, timestamps and SHA-256. Do not trigger the event to see what happens.

3. 03

   If nothing matches, widen the search

   Malware builds hook names from encoded pieces so they never appear as plain text. Search for scheduling calls instead, and read every match outside known plugins:

   shell

   $ grep -rnE "wp_schedule_event|wp_schedule_single_event|cron_schedules" wp-content/

   Then check the layers above WordPress — wp-config.php, a .user.ini auto_prepend_file target, modified core files — where a callback can be registered before any plugin loads.

4. 04

   Check what the arguments carry

   Arguments stored with the event are passed to the callback. A URL, a file path or a base64 string in them is part of the payload, not configuration.

1. 01

   Preserve the evidence

   The cron option you saved above, the callback file with its timestamps and hash, and a database export:

   shell

   $ wp db export ~/incident/before-cleanup.sql
   $ cp -p PATH/TO/CALLBACK.php ~/incident/

   Keep everything outside the web root.

2. 02

   Remove the callback code

   Delete the rogue file, or replace a modified plugin, theme or core file from its official source rather than editing out lines by hand.

3. 03

   Delete the event

   With the code gone, remove every scheduled instance of the hook:

   WP-CLI

   $ wp cron event delete HOOK_NAME

   Deleting by hook name removes all of its scheduled occurrences, whatever their arguments.

4. 04

   Confirm it stays gone

   Load a few pages to let WP-Cron run, then list the events again:

   WP-CLI

   $ wp cron event list --fields=hook,next_run_relative,recurrence --skip-plugins --skip-themes

   If the hook is back, something else is still registering it: another file, a drop-in, or code above WordPress.

5. 05

   Close the way in and rotate

   Something wrote that callback file. Find the entry point — a vulnerable plugin, a stolen login, a neighbouring site — and rotate administrator, application, database, hosting and SFTP credentials, plus the WordPress salts.

If WP-Cron is clean but files still return on a timer, the schedule is on the server: a user crontab, a file in /etc/cron.d, a systemd timer, or an at job. Those need shell access to see, and the server cron guide covers them. And a WP-Cron callback rarely works alone — the same access that planted it usually left a payload in the options table or a loader in mu-plugins as well.