File integrity

The file integrity check answers one question: are the files on disk the ones that should be there? It gives two different kinds of answer, and it never blurs the line between them.

The check costs nothing until you run it. Start one from the File integrity tab, or let the daily schedule run it on its own. A scan runs in steps and keeps its place on disk, so an interrupted request simply resumes where it stopped.

Against the official record

WordPress core and any plugin published on WordPress.org have an official checksum — the record of exactly what the publisher shipped. Alovio Protect compares your files against it. A mismatch there is a fact, not a guess, which is why this runs before any pattern matching.

It reports three kinds of finding:

Finding	What it means
Modified	The file’s contents differ from the published release
Missing	A file the release includes is not on disk
Unexpected	A .php file inside wp-admin/ or wp-includes/ that WordPress.org never shipped

The last one matters more than it looks: a backdoor usually does not modify a core file — it adds one. The core check skips wp-content/ on purpose, because plugins and themes are checked as their own targets, and default themes get deleted routinely, which would only add noise.

When there is no publisher to ask

Premium plugins, client work and every theme on every site have no checksum record anywhere — WordPress.org publishes none for themes at all. Calling these “unverifiable” was honest but useless, since they are often the ones most worth watching.

So the first scan takes a record of its own: every file under the plugin or theme, with its hash. Later scans compare against that record. The interface never calls the result “verified”, because it is a weaker claim:

	says
a checksum	this is the file the publisher shipped
a record	this is the file that was here when we first looked

A plugin that arrived already altered has its altered files recorded as normal, and the screen says so rather than implying cover. What this catches is the ordinary case: a file edited on the server afterwards.

The statuses you will see for these targets:

• recorded — the first record has just been taken.
• unchanged — it matches the record.
• updated — the version moved, so the differences are the update itself and a fresh record was taken.
• drifted — files differ from the record and a person should look.

When you have looked and the changes are expected, accepting the drift makes the current files the new record.

What actually leaves your site

Being straight about this is part of the point. When the integrity module is on and runs a scan, it fetches the published checksums from WordPress.org:

• core checksums from api.wordpress.org
• plugin checksums from downloads.wordpress.org

Those requests identify the plugin and its version and carry your site’s address, the same way WordPress’s own update requests do. They ask for a public list and send nothing about your files — the comparison happens on your own server. The checksums are cached for 12 hours. Switch the module off and the requests stop.

Everything the check finds — the list of modified, missing, unexpected and drifted files — stays on your own site. It is never sent to us or to anyone else.

A note on its limits

The record of your own files lives on the same disk it is watching, so anyone who can write a backdoor into a plugin could also rewrite the record to match it. That is true of every local integrity check, and it is worth saying rather than designing around badly: the checksum path is the one with an authority somewhere else, and the record exists for the files that have no such authority at all.

A file that matches your own record is still read by the malware scanner. Unchanged is not the same as clean.

See also

• The malware scanner
• Licence & updates — the other request the plugin makes