Good to know: SecurynAI's free tier is a fully deterministic security plugin on its own — firewall, scanning, and hardening all work with no setup. Plain-English AI explanations require your own OpenAI or Anthropic API key (typically ~$0.10–$0.30/month); without one, you still get clear fallback explanations, just not full AI narratives.

Why this file is a common target

version.php is a small file with one job: reporting which version of WordPress you're running. That makes it an unusually attractive target for two reasons:

  • Evading vulnerability scanners. Some automated scanners (and some attackers doing recon) check this file to decide whether your site is running a version with known vulnerabilities. An attacker who's already compromised a site sometimes edits the reported version number to make it look up to date, hiding the real (vulnerable) version from anyone scanning from outside — including, ironically, from you noticing it needs an update.
  • It's rarely checked by hand. Almost no site owner ever opens this file to look at it. That makes it a quiet place to leave a small change unnoticed.

How SecurynAI actually catches this

To be precise about what's happening under the hood: this file isn't treated with special logic. It's covered by the same core-file integrity check that verifies every file in wp-admin, wp-includes, and your site's root against the official checksums published for your WordPress version. version.php gets flagged the same way any other altered core file would — the file doesn't need special-case handling because a straightforward "does this match the official version" check already catches it.

That's actually the reassuring part: you don't have to trust that someone remembered to add extra scrutiny for this one file specifically. It's caught by the same mechanism that watches everything else.

Is this actually bad?

Given what this file is used for, treat a genuine, unexplained change to it as a serious signal — not just "a file changed," but specifically "something wanted to hide what version of WordPress this site is running," which is a strong indicator of an attempt to cover tracks after a compromise, not a random glitch.

The one common false alarm: if you or your host just ran a WordPress update, this file legitimately changes as part of that process. Line up the timing before assuming the worst.

What to do

  • Confirm whether an update explains it. If a core update happened at the same time, verify the new version number is correct and move on.
  • If there's no update to explain it, restore the file immediately. Don't try to manually "fix" a suspicious version number — replace the file with the official version for your actual WordPress release.
  • Assume this isn't isolated. Check for other signs of compromise: unfamiliar admin accounts, other modified core or plugin files, or unusual login activity.
  • Verify your actual WordPress version afterward using a source that isn't self-reported by the site.

Have every core file checked against the official version automatically.

Install free →