WordPress Core Files Modified: Hack or False Alarm?

ObaidaAlsulaiman

Obaida Al-Sulaiman, Information Security Manager at ScanTitan,

Magnifier over a WordPress core folder with a harmless check mark and a suspicious shield, showing how to check if core files were modified
Table of Contents

WordPress core files modified is a scanner alert that means a file in your install no longer matches the official release for your version. It is not always a hack. A missing hello.php or an edited readme.html is usually harmless, but a changed file inside wp-includes that nobody edited, or an unknown PHP file in a core folder, often is one. You can tell the difference in about ten minutes with a checksum check, and this guide shows how, then how to fix each case.

Quick answerRun wp core verify-checksums on the server. A mismatch in wp-includes or wp-admin that you never edited, or a PHP file that “should not exist” in a core folder, is a warning sign, so back up the site and reinstall core. Missing sample files such as hello.php, or a wrong version or locale, are usually harmless.

What “WordPress Core Files Modified” Means

Every WordPress release ships with a public list of checksums, which are fingerprints that match each core file exactly. A scanner or the WP-CLI command wp core verify-checksums compares the files on your server to that list for your exact version and language. It reports three results: a file that “doesn’t verify against checksum” was changed, a file that “doesn’t exist” was deleted, and a file that “should not exist” was added. The alert tells you that something differs. It does not tell you who changed it or why, so the next step is to sort the harmless differences from the dangerous ones.

Core Files Modified: Harmless or Hacked?

Most alerts come from ordinary causes, and a few come from attackers. A host or an installer may remove the sample plugin hello.php, a hardening guide may tell you to delete readme.html, and a wrong version or language setting makes the whole check fail at once. An attacker, on the other hand, edits a core file because that file runs on every request and few owners ever open it. A good rule is to ask whether anyone has a reason to touch the file: sample files and root text files have many harmless reasons, while wp-includes and wp-admin have almost none. The table below separates the cases by what the check reports and what to do next.

What the check showsUsual causeHow to confirm
hello.php or an index.php in wp-content “doesn’t exist”Harmless: a host, an installer or you removed a sample fileNothing to restore, and the file is safe to leave out
readme.html or license.txt missing or changedUsually harmless: a hardening step that hides the versionOpen the file and look for links or script tags you did not add
Every file fails to verifyFalse alarm: a wrong version or locale in the checkRun the check again with the correct version and locale
A file in wp-includes or wp-admin “doesn’t verify”Suspicious: nobody should edit these filesCompare it with a clean copy of the same release
A PHP file “should not exist” in wp-admin or wp-includesHigh risk: often a backdoor with a core-style nameOpen the file and read it before you delete anything
wp-config.php looks wrongNot covered: the official list never includes this fileRead it by hand for code you did not write
Harmless and suspicious WordPress core file changes sorted by what a checksum check reports

How to Check Which WordPress Core Files Changed

These steps take about ten minutes and give you a list of exact file names. Work on the live server, and write down every file the check reports.

  1. Confirm your WordPress version and language under Dashboard, Updates, because the check fails for every file when either one is wrong.
  2. Connect to the server over SSH, or open the terminal in your hosting panel, and move to the folder that holds wp-config.php.
  3. Run wp core verify-checksums and let it finish. Add --include-root to also catch extra files in the top folder.
  4. Read each result line and sort it with the table above: changed, missing or added.
  5. Compare every changed or added file with a clean copy of the same release before you decide it is safe.

Reading the Output Line by Line

Each line of output names one file and one problem. A line that says the file doesn’t verify against its checksum means the content changed, and that is the line to take seriously when the path sits in wp-includes or wp-admin. A line that says the file doesn’t exist usually points to a sample file that someone removed. A line that says the file should not exist means the check found a file in a core folder that WordPress never ships, which is the pattern a backdoor uses to look official. If the check reports nothing, core is intact, and a hidden problem sits in plugins, themes, uploads or the database instead.

Checking Without SSH Access

Many shared hosts give no SSH access, and you can still check core without it. Download a clean copy of your exact version and language from WordPress.org, unzip it on your computer, and download the wp-admin and wp-includes folders from your site by SFTP. Then compare the two folders with a free diff tool such as WinMerge on Windows or Meld on Linux and macOS. Any file that differs, or exists on only one side, is a candidate. Some hosts also offer a built-in file scanner in the control panel, and a scanner that checks core files by checksum will give you the same list.

Five steps to check WordPress core files with wp core verify-checksums: confirm version, connect, run, read and compare

What Malicious Core File Changes Look Like

Attackers change core files in three common ways, and each one leaves a different trace in the check. Knowing the three shapes helps you read a file quickly, instead of staring at hundreds of lines of legitimate code.

Code Appended to a Real Core File

The most common change is a few lines added to the end, or the start, of a real core file, so the site keeps working while the attacker gets a way back in. A typical line decodes a hidden string or reads a command from the request and runs it, for example eval(base64_decode($_REQUEST['cmd']));. The check reports the file as changed, and a diff against the clean copy shows the extra lines at once. Our guide on obfuscated PHP malware explains how to read the long encoded strings that often hide such a line.

A Whole Core File Replaced

Sometimes an attacker swaps a core file for a longer or shorter version that adds a login bypass, a hidden admin account or a spam injector. The file name is correct, the file still loads, and the site seems normal, which is why owners miss it. The checksum check catches it every time, because the content no longer matches the release. When you find a replaced file, assume the attacker had write access to the whole install, and look for a second foothold such as a backdoor in the website before you close the incident.

A Fake Core File Name

The third pattern is an extra file whose name looks like core, such as wp-includes/class-wp-cache.php, wp-admin/user-new2.php or a random name with a core-style prefix. WordPress never ships these, so the check reports them as files that should not exist. The code inside is usually a web shell, a small script that lets the attacker run commands. Read the file before you delete it, because its contents often show what the attacker intended, and keep a copy for your records. Also check the file’s modified date, because a file dated days after the rest of core stands out. Our guide on the web shell shows what these files do.

How to Fix Modified WordPress Core Files

Reinstalling core is the fix, and it takes only a few minutes when you do it in the right order. The order matters, because you want evidence before you overwrite anything.

  1. Back up the site as it is now, files and database, so you keep the evidence and a way to roll back.
  2. Reinstall core from Dashboard, Updates, with the Re-install version button, or run wp core download --force --skip-content to overwrite core files and leave your themes, plugins and uploads untouched.
  3. Run wp core verify-checksums again and confirm that it reports no changed files.
  4. Delete every file that “should not exist” after you read it and save a copy.
  5. Search for the way the attacker got in, starting with outdated plugins, nulled software and weak passwords, using our guide on how a website gets hacked.
  6. Change every administrator, database, SFTP and hosting password, and rotate the secret keys in wp-config.php.
Six steps to fix modified WordPress core files: back up, reinstall, verify, delete, find the entry point and change passwords

Video: the web host 20i shows how it fixes modified WordPress core files on its own hosting. Your panel may look different, and it runs about 3 minutes.

When the Same Core File Keeps Changing

If the check passes after a reinstall and fails again days later, something on the server is rewriting the file, and reinstalling core again only resets the clock. The usual causes are a second backdoor outside core, a malicious must-use plugin or cron job that restores the change, or a stolen password that the attacker still holds. Reinstalling is necessary but never enough on its own in this case, because the change returns as soon as the hidden piece runs. Work through our guide on why WordPress malware keeps coming back, and check the mu-plugins folder first, since code there loads without appearing in the plugin list.

How to Stop Core Files From Changing Again

A few habits keep core clean and make a change obvious when it happens. None of them needs a developer.

  • Update core, plugins and themes within days of each release, and delete any plugin or theme you do not use.
  • Disable the file editor in the dashboard by adding define( 'DISALLOW_FILE_EDIT', true ); to wp-config.php. This blocks editing from a stolen admin login, but it does not stop an attacker who can already write files, so treat it as one layer.
  • Schedule a weekly wp core verify-checksums run, or a scan that checks core by checksum, so a change reaches you within days instead of months.
  • Restrict who has SFTP and hosting access, use unique strong passwords and turn on two-factor authentication.

When Modified Core Files Need a Professional

Get help when the same file changes again after a reinstall, when you find a file that should not exist and cannot tell what it does, or when the site handles logins or payments. These cases usually mean the attacker had access for some time, and a single reinstall leaves other footholds behind. A professional cleanup compares core, plugins, themes, the database and the server’s scheduled jobs against clean copies, removes every foothold and then confirms the result from outside. ScanTitan’s website malware removal service covers that process, and you can start with a free website malware scan to see what is exposed.

WordPress Core Files Modified FAQ

What does WordPress core files modified mean?

It means one or more files in your install do not match the official release for your version. The file may have been changed, deleted or added. It is a reason to check, and it is not proof of a hack, because hosts, installers and hardening steps cause harmless differences too.

Is a modified core file always a hack?

No. A missing hello.php, a removed readme.html or a wrong version or locale in the check are common harmless causes. A changed file in wp-includes or wp-admin that you never edited, or an unknown PHP file in a core folder, deserves a close look.

How do I check which core files were modified?

Run wp core verify-checksums from the folder that holds wp-config.php. Without SSH access, download a clean copy of your exact version and compare the wp-admin and wp-includes folders with a diff tool. Either method gives you a list of changed, missing and added files.

Will reinstalling WordPress core delete my content?

No. Reinstalling core replaces the core files and leaves your database, themes, plugins and uploads alone. The wp core download command with the skip-content option does exactly that. Back up first anyway, because the backup also preserves evidence of what the attacker changed.

Why does wp-config.php not appear in the checksum check?

The official checksum list does not include wp-config.php, because every site’s file is different. That makes it a favorite hiding place, so read it by hand for code you did not write, and check wp-content, plugins and themes with separate tools.

o

Information Security Manager · Dubai, UAE · 12+ years InfoSec experience

Obaida specialises in web application security, vulnerability management, and external attack surface reduction for SMB and mid-market organisations. All ScanTitan content is reviewed against live scan findings before publication.

Share :

Facebook
LinkedIn

Continue reading