Initial assessment without passwords Quote before intervention One accountable specialist from start to finish

Malware & Security

Malicious WordPress Cron Jobs: Finding Tasks That Reinfect the Site

Attackers use WP-Cron to restore files, users or remote payloads. Record hooks and callbacks before deleting them.

A suspicious scheduled event is only half the incident. Removing one cron entry is temporary if a plugin, MU plugin, option or external process is still registering it again.

Inventory scheduled hooks before deleting anything

Record hook name, next run time, recurrence and callback owner. Compare the list with installed plugins and known application jobs. An unfamiliar name is not proof of malware; provenance and behaviour matter.

Separate a malicious event from an orphaned legitimate job

  • Trace the callback to the file or class that registers it.
  • Check when the event first appeared relative to the incident.
  • Review whether the callback writes files, creates users or calls unexpected remote services.
  • Look for the same hook being recreated immediately after deletion.

Preserve the schedule and writer before removal

Take a snapshot of the event and related code. If the schedule is actively causing harmful side effects, contain execution while retaining enough evidence to identify the component that created it.

Remove both the event and its registration path

  1. Disable or remove the confirmed malicious writer.
  2. Unschedule the malicious event through WordPress-aware APIs.
  3. Reinstall or patch affected components from trusted sources.
  4. Rotate credentials if the callback exposed or used privileged access.

Look for companion persistence

Scheduled callbacks often work with MU-plugin loaders or database persistence in wp_options. If either remains, the cron event can return after cleanup.

Do not disable WP-Cron globally as the cleanup

That can stop backups, scheduled publishing, WooCommerce work and legitimate maintenance while leaving the malicious registration code present.

Verification over multiple schedule cycles

The malicious hook must stay absent through normal requests and scheduled runs, legitimate jobs must still execute, and no file, option or user change associated with the old callback may reappear.

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.

WP RepairDiagnostic model
1Trigger2Payload3Persistence4Entry point
Follow the chain until you find the first point that stops behaving as expected.
  1. Export all events with hooks, recurrence, next run and arguments.
  2. Map each unknown hook to the PHP callback that registers or handles it.
  3. Compare event creation and execution times with file changes or reinfection.
  4. 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.

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.

BEFORE YOU SEND THE REQUEST

Frequently asked questions.

Do you ask for passwords in the form?+

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?+

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?+

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?+

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

Assess my incident↗