How to check WordPress scheduled tasks after a hack
If a WordPress site has been compromised, attackers often leave behind scheduled tasks to regain access, launch spam campaigns, or reinstall malware.
This guide explains how to inspect WordPress cron events, server-level cron jobs, and related persistence points so you can find and remove suspicious automation quickly.
Scheduled tasks are especially important because they can survive a password reset, keep malware active, and trigger changes long after the initial intrusion.
Knowing where to look can reveal the difference between a one-time breach and an ongoing compromise.
Why scheduled tasks matter after a compromise
WordPress uses a pseudo-cron system called WP-Cron to run time-based actions such as publishing scheduled posts, checking for updates, and sending email notifications.
Attackers can abuse this mechanism by registering custom events that execute malicious PHP code, re-infect files, or call remote servers.
On Linux hosting, a separate server-level cron service may also be present.
If an attacker gained access to the hosting account, they may create operating system cron jobs in addition to WordPress hooks.
Checking both layers is essential because one compromised task can keep restoring the infection even after you clean core files.
Start with a safe forensic snapshot
Before making changes, record what you find.
Capture screenshots or export lists of scheduled events, cron entries, plugin files, and suspicious database rows.
A simple log helps you compare before-and-after states and document what was removed.
If possible, create a backup of the file system and database for offline analysis.
Avoid cleaning aggressively before you inspect, because deleting evidence too early can make it harder to identify the attacker’s method of persistence.
How to inspect WordPress scheduled tasks?
The easiest way to review WordPress cron events is with a plugin such as WP Crontrol, which lists registered cron hooks and their next run times.
This is useful because it surfaces event names, callbacks, and schedules in a readable format without requiring direct database queries.
When reviewing the list, look for anything unfamiliar or unusual, especially tasks added recently or events with odd names that do not match installed plugins or core WordPress functions.
Common red flags include randomized hook names, repeated short-interval jobs, and events tied to files outside standard plugin directories.
What suspicious cron events look like
- Hooks with nonsensical names such as
asdkj123_updateorwp_cache_refresh_x9 - Tasks that run every minute, every five minutes, or on very short intervals
- Events pointing to functions in unfamiliar plugins or theme files
- Repeated tasks that download remote content or contact unknown domains
- Scheduled actions created after the compromise date
Also check whether the same event appears many times with different timestamps.
Attackers sometimes duplicate cron events so that one deleted copy is quickly replaced by another.
Check the WordPress database for cron payloads
WordPress stores scheduled cron data in the wp_options table under the cron option.
If you have database access, review this value carefully for unusual hooks, file paths, or serialized entries that do not belong to the site’s normal plugins.
Database inspection is useful when a plugin interface hides malicious entries or when the admin dashboard is unavailable.
Search for unfamiliar event names, references to base64-encoded strings, and callback functions that call eval, assert, system, or remote URLs.
These are strong indicators of a malicious payload.
Database indicators to examine
- Unexpected rows in
wp_optionswith odd autoload values - Serialized cron arrays containing unknown hook names
- Encoded strings that decode into PHP code or remote fetches
- Recently modified entries in tables related to users, settings, or plugins
Review server-level cron jobs
Attackers who gained hosting access may add system cron jobs outside WordPress.
On a typical Linux server, inspect the current user’s crontab, root’s crontab if you have permission, and the standard cron directories such as /etc/crontab, /etc/cron.d/, /etc/cron.hourly/, /etc/cron.daily/, and /var/spool/cron/.
Search for commands that download files with curl or wget, execute scripts from temporary directories, or run PHP scripts from unusual paths.
A common pattern is a cron job that restores a malicious file from a remote source whenever the file is deleted locally.
Common suspicious cron patterns
curlorwgetcommands downloading payloads- Base64-decoded shell commands
- PHP scripts running from
/tmp, hidden folders, or upload directories - Jobs scheduled every few minutes without a clear business purpose
- Commands that append code to legitimate files
Compare scheduled tasks with installed plugins and themes
Every legitimate cron event should map to a known plugin, theme, or WordPress core feature.
Compare each hook against the active plugin list, the active theme’s functions.php, and custom code in mu-plugins or drop-in files.
If a task references code that no installed component should contain, investigate that file immediately.
Pay special attention to custom plugins in wp-content/plugins/ and must-use plugins in wp-content/mu-plugins/.
Attackers often hide persistence code there because these locations load automatically and are less likely to be reviewed during routine maintenance.
Inspect files linked to suspicious hooks
Once you identify an unfamiliar scheduled task, follow the callback to the underlying file.
Review the file for obfuscated code, remote includes, file writes, and unusual permission checks.
Malware often disguises itself as a helper function or uses names that resemble legitimate utility code.
Look for recently modified PHP files in wp-content, especially those with long strings, encrypted-looking blocks, or repeated calls to functions that build and execute code dynamically.
Also check for modified .htaccess rules, hidden backups with extensions like .php.bak, and files placed in image or cache directories.
Use command-line tools for faster auditing
If you have SSH access, command-line tools can speed up triage.
WP-CLI can list scheduled hooks, inspect plugins, and verify WordPress core, while standard shell tools can search for suspicious patterns across files and logs.
This is useful on larger sites where manual dashboard review is too slow.
Typical checks include searching for recent file changes, identifying PHP files outside expected directories, and reviewing logs for the first signs of compromise.
When available, compare timestamps with the site’s analytics, access logs, and administrative activity to determine when the malicious task was introduced.
Helpful command-line checks
wp cron event listto review scheduled WordPress eventswp plugin listto confirm installed componentsfind wp-content -type f -name "*.php" -mtime -7to locate recently changed PHP filesgrep -R "base64_decode\|eval\|gzinflate" wp-contentto identify common obfuscation patterns
Remove malicious tasks without breaking legitimate automation
Delete only the cron events you have verified as suspicious.
If a hook belongs to a legitimate plugin, remove the plugin-related malware first and then rescan to ensure the event does not reappear.
After deleting a task, check whether another scheduled job or file watcher recreates it.
After cleanup, change all relevant credentials, including WordPress administrator passwords, hosting account credentials, database passwords, SFTP accounts, and API keys.
If the attacker had access to cron, assume they may have captured secrets stored in configuration files.
Harden the site after cleanup
Once the scheduled tasks are clean, reduce the chance of reinfection by limiting what can run automatically.
Remove unused plugins and themes, keep WordPress core updated, and restrict file editing from the dashboard.
If your hosting panel allows it, review all user accounts and delete any account that should not exist.
It also helps to monitor future cron changes.
Many security plugins can alert you when files change or when new scheduled tasks are created.
For higher-risk sites, a file integrity monitor and regular database review can catch persistence mechanisms early.
When to escalate to a deeper incident response
If you find repeated malicious cron jobs, unknown administrator accounts, or evidence of server-wide access, the compromise may go beyond WordPress itself.
In that case, a full incident response should include log analysis, credential rotation, malware scanning, and a review of the hosting environment, email accounts, and connected services.
Persistent reinfection usually means the attacker still has a foothold somewhere.
At that point, checking scheduled tasks is necessary, but it is only one part of a broader containment and recovery process.