How to Fix wp-blog-header.php Regenerate Malware in WordPress When Security Scanners Miss the Backdoor

A client hired me after dealing with one of the most frustrating WordPress malware problems: they kept cleaning the infected wp-blog-header.php file, the site would come back for a few minutes, and then the exact same malware would return again.

They had already tried the usual recovery steps. They replaced infected core files, ran Wordfence scans, and kept removing the visible payload. But the infection would regenerate within minutes. This is a classic sign that the visible hacked file is not the real root cause. Somewhere else on the server, a hidden dropper was monitoring the file and rewriting it after every cleanup.

In this case study, I’ll show exactly how the wp-blog-header.php regenerate malware worked, why normal WordPress malware scanners missed it, how I wrote a custom hunter script to find the hidden backdoor, and how I broke the reinfection loop permanently.

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

Quick Summary

• Main symptom: malware inside wp-blog-header.php kept coming back after removal
• Why the cleanup failed: a hidden dropper file was rewriting the infected code
• Why scanners missed it: the dropper used normal PHP file-writing behavior instead of obvious malware signatures
• Breakthrough: a custom PHP hunter script found a hidden backdoor buried deep inside the active theme
• Final fix: removed the dropper, cleaned the infected root file, hardened access, and stopped the reinfection loop permanently

Why hackers target wp-blog-header.php

Before looking at the malware itself, it helps to understand why attackers chose this file.

In a normal WordPress installation, wp-blog-header.php is part of the site’s main request flow. It helps load the WordPress environment and template logic, which means it gets executed again and again as the site serves normal page requests. That makes it a valuable place for attackers to inject redirect logic, cloaking behavior, or SEO spam payloads.

If attackers can control this file, they can run malicious code before the site behaves normally for the visitor. That is exactly why regenerating wp-blog-header.php malware is so disruptive.

What the visible malware was doing

When I opened the infected wp-blog-header.php, I found a large obfuscated PHP payload injected before the legitimate WordPress flow. It was not just a simple redirect. It was built for cloaking and SEO abuse.

Here is how the payload behaved:

• Targeted high-value pages: it only activated on selected URLs instead of every page
• Fingerprinting and IP logic: it checked headers and visitor details to avoid exposing itself too easily
• Bot cloaking: it recognized search-engine-like traffic and served external gambling spam content
• Human search-traffic hijacking: if a real visitor arrived from Google, Yahoo, or Bing, it redirected them to a betting shortlink
• Direct visits looked normal: if the site owner typed the URL directly, the site could still appear clean

This is exactly why this kind of infection is so deceptive. It can stay invisible to the owner while still poisoning rankings and redirecting real search traffic.

Related reading: How to detect WordPress malware.

Why the malware kept coming back

The biggest mistake in these cases is thinking the infected wp-blog-header.php file is the full infection. It is usually only the symptom.

If the file comes back after you clean it, that means something else is putting it back. In practice, that “something else” is often:

• a hidden dropper script
• a backdoor hidden in a theme or plugin folder
• a scheduled server task
• a secondary remote-triggered reinfection mechanism

That was exactly what was happening here. The visible file was only the payload. The real problem was a hidden script elsewhere on the server that was watching for the cleanup and restoring the malware.

Related reading: Why WordPress malware keeps coming back and how to stop it.

Why Wordfence and standard scanners missed the root cause

The client was using Wordfence, and that is a solid security plugin. But solid scanners still have limits.

The problem was not that Wordfence was “bad.” The problem was that the hidden dropper did not look like classic malware at first glance. It was a small PHP file using native file-writing behavior, which is something legitimate code can also do. Many automated tools are better at detecting known signatures, suspicious obfuscation patterns, or common malware strings than they are at spotting a custom backdoor that quietly rewrites another file.

That is why this case needed manual investigation, not just another scan.

The turning point: writing a custom hunter script

At that point, I stopped looking for “malware signatures” and started looking for behavior.

I knew two things had to be true about the hidden dropper:

1. it had to know the target file name: wp-blog-header.php
2. it had to use a file-writing function such as file_put_contents to put the malware back

So I wrote a custom PHP script called hunter.php and uploaded it to the root of the site. Instead of scanning for known malware patterns, it recursively scanned every PHP file in the site and looked for both of those behaviors together.

<?php
$dir = __DIR__;

echo "<h3>Hunting for backdoors targeting wp-blog-header.php...</h3><hr>";

$iterator = new RecursiveDirectoryIterator($dir, RecursiveDirectoryIterator::SKIP_DOTS);
$files = new RecursiveIteratorIterator($iterator);
$found = false;

foreach ($files as $file) {
    if ($file->getFilename() === 'wp-blog-header.php' || $file->getFilename() === 'hunter.php') {
        continue;
    }

    if ($file->isFile() && pathinfo($file, PATHINFO_EXTENSION) === 'php') {
        $contents = @file_get_contents($file->getPathname());

        if ($contents !== false &&
            strpos($contents, 'wp-blog-header.php') !== false &&
            strpos($contents, 'file_put_contents') !== false) {

            echo "🚨 <strong>Malware Dropper Found:</strong> " . $file->getPathname() . "<br>";
            $found = true;
        }
    }
}

if (!$found) {
    echo "<p>✅ <strong>Scan finished.</strong> No exact behavioral match found. The payload might be differently encoded.</p>";
}
echo "<hr><p><em>Delete hunter.php after running.</em></p>";
?>

That script found what the scanners missed in seconds.

The hidden dropper I found

The output pointed me to a deeply buried file inside the active Divi theme:

🚨 Malware Dropper Found: /home/.../public_html/wp-content/themes/Divi/includes/builder/frontend-builder/assets/vendors/tinymce-skin/fonts/ext.php

This was not a legitimate theme file. The attacker had hidden the backdoor inside a deeply nested folder path where most site owners would never think to look. That is a common tactic: hide the dropper inside trusted-looking directories so it blends into the normal structure.

Related reading: How hackers hide backdoors in WordPress.

How the dropper actually worked

Once I opened the fake ext.php file, the reinfection logic became clear.

1. Heartbeat check
   The script checked whether the malicious marker was still present inside wp-blog-header.php.
2. Reinfection trigger
   If the malicious marker was missing, it assumed the file had been cleaned.
3. Payload download
   It reached out to an external source and fetched a fresh copy of the malware payload.
4. File rewrite
   It then used file-writing logic to overwrite the clean wp-blog-header.php with the malicious version again.

That is why the site kept getting re-hacked within minutes. The dropper was doing exactly what it was designed to do: silently restore the infection every time someone cleaned the visible payload.

How I stopped the reinfection loop permanently

1. Deleted the hidden dropper

Once the real backdoor was identified, I removed ext.php from the server completely.

2. Cleaned the infected root file one final time

After removing the persistence mechanism, I cleaned wp-blog-header.php again. This time, the infection did not come back.

3. Audited the broader environment

Breaking the reinfection loop is not the same as fully securing the site. I also treated the case like a full malware response and reviewed themes, plugins, suspicious users, access hygiene, and other possible backdoors.

4. Recommended post-cleanup verification

Because core files were involved, I also recommend verifying WordPress core integrity after cleanup and rotating all critical credentials. That includes WordPress admin passwords, FTP or hosting access, and database credentials.

Related reading: What to do after fixing a hacked WordPress site.

What site owners should learn from this case

• If wp-blog-header.php keeps coming back after cleanup, the visible file is not the real problem.
• Behavior-based hunting can work when signature-based scanning fails.
• Backdoors are often hidden in deep, trusted-looking directories.
• Replacing only the infected file will not solve a reinfection loop.
• You must remove the dropper and then audit the original entry point too.

FAQ

What is wp-blog-header.php regenerate malware?

It is a type of WordPress infection where malicious code keeps being written back into wp-blog-header.php after you remove it, usually because a hidden dropper or backdoor exists elsewhere on the server.

Why does my WordPress malware keep coming back after I clean it?

Because the visible infected file is often only the symptom. A hidden script may still be monitoring the file and rewriting the malware after cleanup.

Can Wordfence fix this kind of reinfection?

Sometimes, but not always. In custom reinfection cases, a hidden dropper may use ordinary PHP functions and avoid the obvious signatures scanners rely on.

Why did the custom hunter script work better?

Because it looked for the behavior that mattered: a file that referenced wp-blog-header.php and also used file-writing functions. That made it much more targeted than a normal malware signature scan.

How do I prevent this from happening again?

After cleanup, update all themes and plugins, remove unsafe or nulled components, rotate credentials, review user access, and harden the site so the original entry point cannot be abused again.

Related Reading

• WordPress Malware Removal Service
• How to detect WordPress malware
• Why WordPress malware keeps coming back
• How I fixed regenerating index.php malware
• How hackers hide backdoors in WordPress
• Known fake and malicious WordPress plugins

Need help stopping WordPress malware that keeps regenerating?

I’ve worked on thousands of WordPress malware cases, including regenerating core-file infections, hidden dropper scripts, redirect malware, cloaking spam, fake plugins, and reinfection loops that normal scans miss. If your wp-blog-header.php or index.php keeps getting infected again after cleanup, I can help you find the real persistence mechanism and remove it properly.

Hire me or go directly to my WordPress malware removal service.