My WordPress Site Has a Rogue Cron Job — What Does That Mean?

What WordPress cron actually is

wp-cron.php is how WordPress runs scheduled tasks — publishing a scheduled post, checking for updates, sending a batch of emails, running a plugin's periodic cleanup job. It's not a real system-level cron job by default; it fires based on site visits. Plugins and themes are allowed to register their own scheduled tasks, and most of the time that's completely legitimate.

Why attackers use it

A scheduled task is an appealing way to keep access to a compromised site, because it runs automatically and repeatedly without needing an active login. A rogue cron job registered by an attacker might:

• Re-download or re-create a backdoor file if it gets removed
• Send spam email in batches on a schedule
• Periodically "phone home" to report the site is still compromised
• Re-apply a malicious change if you undo it manually

That last one is why cleanup sometimes seems to "not stick" — if the persistence mechanism itself isn't found and removed, whatever it recreates will just come back.

How to tell a rogue task from a legitimate one

1. List what's actually scheduled. A number of free plugins can show you all registered cron events, including ones that don't come from anything currently visible in your plugin list.
2. Look for tasks tied to nothing you recognize. A scheduled hook name that doesn't match any installed, active plugin is worth investigating — especially if a plugin it once belonged to has since been deleted but the task is still running.
3. Check the frequency. Extremely frequent tasks (every minute, every few minutes) are more consistent with malicious "check-in" behavior than most legitimate plugin maintenance tasks.
4. Correlate with other issues. A rogue cron job rarely shows up alone — it's usually one piece of a broader compromise that also includes a modified file or an unfamiliar admin account somewhere.

What to do if you find one

• Don't just deactivate it and move on. Find and remove the actual malicious file or code the task is calling — removing only the schedule can leave the payload in place for something else to trigger it.
• Check file integrity across the site, not just the plugin the task appears to belong to.
• Change credentials for every admin account once you've confirmed a compromise.

Where this fits with a broader security setup

A standalone "suspicious cron job" scanner is only one narrow piece of what a real compromise looks like. Tools that watch file integrity, admin account activity, and login behavior are more likely to catch the actual entry point — the modified file or new admin account that let the attacker set the cron job up in the first place — even when the scheduled task itself isn't the thing being watched directly.