Why comparing WordPress core files matters after a hack
If your WordPress site has been hacked, comparing core files is one of the fastest ways to spot unauthorized changes.
It helps you separate legitimate WordPress files from modified, injected, or replaced files so you can clean the site with confidence.
Attackers often hide malware in WordPress core locations because they expect site owners to trust those files.
By checking core integrity against a known-clean WordPress release, you can identify altered PHP files, unexpected backdoors, and suspicious changes that may survive a simple password reset.
What WordPress core files are
WordPress core files are the files that power the WordPress software itself, excluding themes, plugins, and uploads.
They include the root files in your WordPress installation and the files inside folders such as wp-admin and wp-includes.
- Root files:
wp-config-sample.php,index.php,wp-login.php, andxmlrpc.php - Admin files: the contents of
wp-admin - Includes files: the contents of
wp-includes
These files should match the official WordPress release for the version you are running, aside from a few configuration-specific differences.
That makes them ideal for integrity checks after a compromise.
Signs your core files may have been compromised
Before comparing files, look for warning signs that point to core tampering.
Some infections are obvious, while others blend in with legitimate code.
- Unexpected redirects to spam, phishing pages, or malicious domains
- Sudden admin account creation or privilege escalation
- Unknown PHP files inside
wp-adminorwp-includes - Injected code at the top or bottom of core PHP files
- Repeated malware alerts from your host, scanner, or Google Search Console
- Site behavior changes after updates, logins, or plugin activation
If any of these appear, treat the site as compromised and compare the core files before making broad changes.
How to compare WordPress core files after hack
The safest method is to compare your current files against a fresh download of the same WordPress version.
You can do this manually, with command-line tools, or through security software that supports file integrity checks.
1. Confirm your installed WordPress version
Start by identifying the exact version running on the site.
You can find it in the WordPress dashboard, in the readme.html file if it is still present, or by checking the database and file metadata if the dashboard is inaccessible.
Matching versions matters because core files change between releases.
Comparing version 6.5 files against version 6.4 files will produce many false differences.
2. Download a clean copy from WordPress.org
Download the same version from the official WordPress.org release archive.
If possible, verify the package checksum or signature from a trusted source.
This gives you a clean baseline for comparison.
Extract the archive on your local machine, not on the compromised server.
Use that copy as the reference set of core files.
3. Compare file structure and filenames
First compare the directory structure.
Hackers often add extra files in core directories or replace standard files with lookalikes.
Check for:
- Extra PHP files in
wp-adminorwp-includes - Files with similar names, such as
class-wp-query.phpversusclass-wp-query.php.bak - Hidden files or unusual file extensions
- Recently modified files that should not change often
Any filename that does not exist in the clean WordPress package deserves closer inspection.
4. Diff the file contents
Use a file comparison tool to inspect content differences between the clean copy and the live site.
Popular tools include WinMerge, Beyond Compare, and Diffchecker.
On Linux or macOS, diff and rsync can also help.
Focus on core PHP files first.
Malware is commonly inserted as obfuscated PHP near the top or bottom of a file, but it can also be hidden in the middle of legitimate code.
Look for patterns such as:
eval(),base64_decode(), orgzinflate()used together- Long, unreadable strings or encoded payloads
- Unknown function calls or suspicious network requests
- JavaScript injected into PHP files
- Code added without matching the clean WordPress release
5. Check file hashes for a faster integrity test
Hash comparison is useful when you need to test many files quickly.
A hash like SHA-256 acts as a fingerprint for a file, so a mismatch means the file content is different.
Generate hashes for the clean WordPress package and your live files, then compare them.
If the hashes do not match for files that should be identical, inspect those files manually.
Common tools include sha256sum on Linux, shasum -a 256 on macOS, and PowerShell commands on Windows.
Hash checking is especially helpful for large sites because it quickly flags tampered files.
6. Use WordPress integrity tools and security scanners
Several security plugins and hosting tools can help compare WordPress core files after a hack.
They often scan for modified core files, unknown files, and malware signatures.
- Wordfence: detects modified core files and compares them against the official repository
- Sucuri: scans for malware, file changes, and suspicious code
- Patchstack: focuses on vulnerability management and exposure reduction
- Hosting malware scanners: many managed hosts offer file integrity monitoring
These tools are useful, but they should supplement, not replace, manual verification.
Attackers may hide code in places a scanner misses or flag clean files as suspicious if you run custom modifications.
Which files you should review first
Not every changed file is equally important.
Start with files that are part of the WordPress engine and have high impact on authentication, routing, and loading behavior.
wp-login.phpwp-settings.phpwp-load.phpwp-admin/index.phpwp-includes/load.phpwp-includes/pluggable.php
These files are frequently targeted because altering them can help attackers persist, intercept logins, or load malware early in the request cycle.
If any of these differ from a clean release without an obvious reason, treat them as high priority.
How to handle custom modifications safely
Some sites intentionally modify core behavior, though this is not recommended.
If you inherited a site with custom core edits, compare the live file against the clean file and document every change before replacing anything.
In most cases, custom logic should be moved into a plugin, must-use plugin, or theme functions file rather than left in core.
This reduces risk and makes future integrity checks more reliable.
- Preserve a backup before editing or restoring files
- Record legitimate changes in a change log
- Move site-specific logic out of core when possible
- Test on staging before replacing production files
How to restore clean WordPress core files
Once you confirm which core files are compromised, replace them with clean copies from the same WordPress version.
Do not overwrite your entire installation unless you have verified backups and know exactly what needs to be restored.
Upload clean versions of the affected core files and folders, then re-run your comparison to confirm the replacements match.
If the compromise is widespread, it is often safer to reinstall WordPress core from scratch and keep only wp-config.php, your wp-content folder, and the database after thorough review.
What to do after the file comparison
Comparing core files is only one part of incident response.
After you restore clean files, rotate credentials, review users, and check for persistence mechanisms.
- Change all passwords, including admin, database, FTP/SFTP, and hosting logins
- Regenerate WordPress security salts in
wp-config.php - Review administrator and editor accounts for unknown users
- Scan
wp-contentfor backdoors in plugins, themes, and uploads - Check scheduled tasks, cron jobs, and mu-plugins for hidden persistence
- Update WordPress core, plugins, and themes to current secure versions
This broader cleanup helps ensure the attacker does not return through another compromised file or stolen credential.
Best practices for preventing future core file tampering
Keeping WordPress core file comparisons easy in the future starts with reducing attack surface and improving visibility.
Regular monitoring makes it much easier to detect a breach before it spreads.
- Use managed updates and keep WordPress current
- Restrict file editing in the dashboard with
DISALLOW_FILE_EDIT - Limit write permissions on core directories
- Enable file integrity monitoring
- Use two-factor authentication for admin accounts
- Store known-clean backups offsite
These steps do not replace cleanup, but they make compromise detection faster and recovery much easier if a hack happens again.