WordPress core files were modified: what it means

When a scanner says “WordPress core files were modified,” it is telling you that at least one file that ships with WordPress no longer matches the official copy from wordpress.org. The homepage can still look fine. That is often the point. Attackers like a quiet edit inside wp-includes that loads on every request, so this warning is worth opening even when the site “still works.”

This article is the diagnostic. For the product overview, start with Core Scanner. To run a scan, see scan WordPress core. Short definitions live in core file integrity and file integrity monitoring.

The Core Scanner is included in Free. It compares wp-admin, wp-includes, and the WordPress root against wordpress.org checksums for your installed version and locale.

What the scanner is actually saying

Each finding has a severity. Critical is reserved for obvious junk in core paths, such as a phpinfo drop. Warning covers most unknown or modified files. Notice is lower risk. The tab badge counts critical and warning items, not every notice.

The scan looks for three kinds of mismatch. Modified core files no longer match official checksums. Expected core files can be missing (WordPress allows a few exceptions). Unknown files can appear in core directories, including unexpected files in the WordPress root and hidden dotfiles under wp-admin and wp-includes.

This is not a malware signature scan. A clean core check does not prove plugins are clean. A dirty core check does not always mean you are hacked. It means you should look at the diff before you ignore it.

When it can be harmless

Some mismatches are expected. wp-config.php is unique per site. Missing readme.html, license.txt, or install helpers is often intentional. OS metadata such as .DS_Store is excluded from results.

Someone editing core “just to silence a warning” also produces a mismatch. That is still a problem. Do not keep custom PHP inside WordPress core. Put that work in a plugin or a child theme.

If you just updated WordPress and the scan ran in the middle of the update, run it again. A leftover mismatch after a finished update is not something to wait out.

What to do next

Open Security Ninja → Core Scanner and work each finding in order:

1. Open View File or View differences in the File Viewer.
2. Ask whether you (or a trusted deploy) changed that file on purpose.
3. Restore altered core files from wordpress.org when you did not mean to edit them.
4. Delete unknown files in core paths only when you are sure they should not be there.
5. Ignore a path only after you understand it (how to ignore files).
6. Scan again. Then check users, plugins, and the malware scanner if the diff looks obfuscated or you did not put it there.

Do not ignore a changed wp-includes PHP file because the site still loads.

When this is an incident

Treat it as a compromise when you did not update or deploy anything, the diff is obfuscated (eval, mystery includes), unknown PHP appeared in a core directory, or the same file comes back after you restore it. That last one is malware that kept coming back.

From there, follow WordPress malware removal and signs your site is hacked. If you are locked out or it reinfects, use DIY vs hire or consultation.

Related reading

• Core Scanner
• Core Scanner docs
• Malware scanner
• WordPress malware removal
• Security tests

Bottom line

A modified-core warning is a checksum mismatch, not a diagnosis by itself. Open the diff. Restore stock WordPress files you did not edit. Investigate anything you did not put there. Core should match wordpress.org. Your custom work belongs in plugins and themes, not in wp-includes.