WordPress.org publishes checksums (SHA1 and MD5) for every core file in every release. This audit compares the hash of files on disk against the official signature. A mismatch means the code has been altered. In 95% of cases that is a backdoor planted after a breach.
Why this matters
Attackers who get into a site want two things: a way back in even after passwords change, and concealment. The easiest path is to inject code into core files - an eval line that accepts commands through an HTTP parameter, or a small modification to wp-login.php that logs every password typed. Core files are the ideal target because admins do not normally touch them, and the next WordPress update that would overwrite the change might be months away. If your core is not authentic, you do not run your site - someone else does. The risk: customer data leakage, spam sent from your domain (which lands you on email blacklists), hidden links injected that tank Google rankings, and your server being used as a node in a botnet.
How to detect
The audit downloads official checksums from api.wordpress.org/core/checksums/1.0/?version=X.Y.Z, runs md5_file on every core file, and compares. Mismatched files appear in the report. Manually: install Wordfence (free) > Scan > Run scan. It produces an identical list. WP Activity Log records changes in real time. In an emergency: compare file sizes between the site and an official ZIP from wordpress.org/download/release-archive/.
How to fix
- Take a full backup (files + database) before touching anything. There is a chance the cleanup will remove things you want for forensics.
- Download a copy of the suspicious file (FTP/SFTP) and open it in a text editor. Look for eval(), base64_decode, gzinflate, str_rot13. Lines after the closing ?> at the end of the file are a classic signal.
- The easy fix: Dashboard > Tools > Site Health > Reinstall WordPress. WordPress will re-download the current version and overwrite every core file.
- Manual: download the ZIP of the same version from wordpress.org > extract > upload over SFTP. Do not delete wp-content - that is your content and plugins.
- After restoring: run a full malware scan (Wordfence Premium or MalCare) - they detect backdoors in plugins and themes, not just core.
- Rotate every password: database (wp-config.php and cPanel), FTP, every admin, hosting account.
- Replace the salts in wp-config.php - it invalidates all live sessions, including the attacker's.
- Inspect wp_users for accounts you do not recognise.
- Compare plugin versions against wordpress.org. If core was compromised, plugins may be too.
Common mistakes
Do not fix only the specific file flagged - an attacker who placed one backdoor usually placed a backup elsewhere. Clean comprehensively and do not assume you found everything. Do not assume that a one-line change is harmless - one line of eval is enough for full control. Do not ignore warnings claiming 'changes for translation reasons' - translators who edit core files instead of using .po files are making a mistake, but not an attack.
Verifying the fix
Re-run the audit - the check should turn green. Run Wordfence Scan again - 'No issues found'. Inspect server logs for suspicious activity (POST to wp-login.php from many IPs, access to .php files inside uploads/). Stay vigilant for several weeks - backdoors sometimes return after an incomplete restoration.