A Core File Has Been Silently Altered — What It Means

What just happened

WordPress core — the files in wp-admin, wp-includes, and the files sitting in your site's root — should only ever change when you run a WordPress update. Every official release has a known, published checksum for every one of those files. SecurynAI compares the files actually on your server against those official checksums on a regular basis.

When a file doesn't match what it should be, and no update happened to explain the change, that's a core checksum mismatch — the alert you just received.

How the checksum check actually works

WordPress publishes an official, per-version checksum for every core file at api.wordpress.org/core/checksums/1.0/. Verifying your site means fetching the checksums for the exact WordPress version you're running and comparing each one against the file that's actually on your server — a straightforward "does this match" check, run deliberately early (before WordPress itself even finishes loading) specifically so the check isn't relying on a WordPress environment that might itself already be compromised.

Is this actually bad?

Usually, yes, and it's treated as a high-severity finding by default. A modified core file outside of an update is one of the most reliable signs of a compromise: it's a classic way attackers plant a backdoor, because core files are trusted by definition and rarely inspected line-by-line by a human. WP-VCD, one of the most widespread WordPress malware families, works exactly this way — it injects a backdoor into wp-includes/post.php and creates a second copy at wp-includes/wp-vcd.php, then uses that access to plant unauthorized admin accounts.

There are two situations where the severity gets adjusted automatically:

• If the same file was already flagged by malware scanning, the finding gets escalated to critical — two independent signals agreeing is a much stronger indicator than one.
• If the change looks benign on closer inspection, it can be downgraded — but it still shows up, it's never silently dismissed.

If WordPress core couldn't be verified at all (for example, if the official checksum service was temporarily unreachable when the check ran), you'll see a separate, lower-severity "unverifiable" finding instead — that's a "we couldn't confirm either way," not a "you're fine."

A second real example, at much larger scale

WP-VCD isn't the only well-documented case. In December 2014, a campaign that came to be known as SoakSoak compromised over 100,000 WordPress sites by modifying wp-includes/template-loader.php — a genuine core file — to load a malicious script on every page view, which then redirected visitors and attempted drive-by malware downloads. Google blacklisted more than 11,000 domains in a single day once it caught on. The campaign later evolved to target a different core file, wp-includes/js/json2.min.js, once site owners and scanners started specifically watching the first one.

The root cause is worth knowing too, because it's the same pattern behind most core-file compromises: the actual entry point wasn't core at all. Attackers exploited a zero-day in a popular slider plugin (RevSlider) that let them download arbitrary files — including ones containing database credentials — and used that access to reach in and modify core files directly. The core-file alert is the symptom you actually see; the plugin vulnerability is usually where the story starts.

What counts as "core" — and what doesn't

Worth being precise about this, since it changes what a clean checksum result actually tells you: WordPress core is specifically the files in wp-admin, wp-includes, and the loose files sitting in your installation's root (wp-load.php, wp-settings.php, and similar). It does not include anything in wp-content — your plugins, your theme, and your uploads folder are entirely outside the official checksum manifest, because their content is different on every single WordPress site by design. A clean core-checksum result says nothing about whether a plugin or theme file has been tampered with; that requires separate malware/integrity scanning of wp-content specifically, which is a different check than the one this alert is about.

What to check

• Did you or your host just run a WordPress core update? If the timing lines up exactly, this may be a false alarm from a check that ran mid-update — but confirm the file content matches the official release before dismissing it.
• What does the diff actually show? Injected code that adds an HTTP call, an eval(), a base64_decode(), or references to an unfamiliar domain are strong signs of tampering, not a benign edit. A large share of real WordPress backdoors follow the same shape: a call wrapped so it isn't readable at a glance —

<?php @eval(base64_decode('aWYoaXNzZXQoJF9QT1NUW3...'));

• Has anything else happened recently? A modified core file is exactly the kind of signal that gets grouped with other findings (new admin accounts, unusual logins) into a single incident if they're related — check whether this alert is part of a larger picture.

You can also run WordPress's own checksum verification directly if you have shell access, independent of any plugin:

wp core verify-checksums

Verifying a single file by hand

If you want to see the actual difference yourself rather than trust a pass/fail result, it's a two-step process: download the official release your site is running from wordpress.org/download/releases, extract it, and diff the one file you're checking against its clean counterpart in the same relative path:

diff wp-includes/post.php /path/to/clean-wordpress-6.8.2/wp-includes/post.php

Any output at all means the two files differ. A short, unexplained addition — especially one involving eval, base64_decode, or a raw HTTP call — is what you're looking for; formatting-only differences (whitespace, line endings) are far less concerning than an actual added statement.

What to do

• Restore the file to its official version. Since core files should never be hand-edited, the safe move is almost always to overwrite the modified file with the clean, official version — not to try to "fix" the injected code manually.
• Don't stop at one file. If one core file was altered, check whether others were too, and extend the same scrutiny to your plugins and themes.
• Change credentials if you find anything conclusive. If the modification is confirmed to be malicious, assume the access that made it possible is still open until you've addressed it directly.

Why this matters even if the change looks small

A one-line addition to a core file can be enough to grant an attacker persistent access, log credentials, or serve malicious content to only some visitors (making it easy to miss on a casual look). Treat "small change" and "low risk" as two separate questions — they're not the same thing here.