What matters first: A suspicious cron entry may call an unknown hook, run unusually often or be registered by code that is no longer visible in the plugin list. The schedule itself is persistence evidence.
What this symptom actually tells you
Deleting the event can stop one cycle, but the loader that re-registers it may recreate the task on the next request.
Capture evidence before changing anything
- Export all events with hooks, recurrence, next run and arguments.
- Map each unknown hook to the PHP callback that registers or handles it.
- Compare event creation and execution times with file changes or reinfection.
- Inspect mu-plugins, active plugins, themes and database options for registration code.
Most common causes
- Backdoor persistence: A hidden loader schedules remote downloads or file writes.
- Compromised plugin: Legitimate code was modified to register the task.
- Database-only residue: The event remains after the original code was removed.
- High-frequency abuse: A task runs every minute to preserve access or send spam.
Safe diagnostic and repair sequence
- Preserve the event list and relevant code before modification.
- Remove the registering code and payload, then delete the orphaned event.
- Run due events in a controlled environment to identify side effects when safe.
- Monitor the cron array through several normal cycles for recreation.
How to choose between the likely causes
Do not treat Backdoor persistence and Compromised plugin as interchangeable. A hidden loader schedules remote downloads or file writes. By contrast, legitimate code was modified to register the task. Use two checks to separate them: Export all events with hooks, recurrence, next run and arguments; and map each unknown hook to the PHP callback that registers or handles it. Those observations usually show whether the next safe move is to preserve the event list and relevant code before modification 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 unknown cron hooks on production simply to see what happens. They may send mail, rewrite files or contact attacker infrastructure.
How to verify the repair
- Suspicious hooks and registration code are removed.
- No file, user or option is recreated after cron cycles.
- Legitimate scheduled jobs continue to run once.
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
Safe intervention sequence
Deleting the event can stop one cycle, but the loader that re-registers it may recreate the task on the next request.
- Export all events with hooks, recurrence, next run and arguments.
- Map each unknown hook to the PHP callback that registers or handles it.
- Compare event creation and execution times with file changes or reinfection.
- Inspect mu-plugins, active plugins, themes and database options for registration code.
What must be verified
- Suspicious hooks and registration code are removed.
- No file, user or option is recreated after cron cycles.
- Legitimate scheduled jobs continue to run once.
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.
If I delete the suspicious scheduled task, is that enough to stop it?+
Not necessarily. Deleting the event can stop one execution cycle, but if a hidden loader is still present and re-registering the task, it can simply recreate the same or a similar cron entry on the next request.
Is it safe to manually trigger an unknown cron hook to see what it does?+
No. Unknown hooks should not be run on production just to observe behavior, since they may send mail, rewrite files, or contact attacker-controlled infrastructure the moment they execute.
Can a malicious cron entry remain even after the plugin that created it has been removed?+
Yes. This is called database-only residue: the scheduled event can persist in the cron array even after the original registering code has been deleted, which is why the cron array itself needs to be checked, not just the list of active plugins.
What does it mean if a cron task is set to run every minute or unusually often?+
A very high execution frequency is a common pattern for tasks used to preserve unauthorized access or send spam continuously, since frequent execution keeps the attacker's foothold refreshed. Comparing the recurrence and next-run values across all events helps surface this kind of abuse quickly.