Check WordPress files for tampering and malware

The Integrity & malware row on a hosting’s WordPress tab answers the question the Updates row does not: has anything been changed? It compares WordPress core and plugin files with the checksums wordpress.org publishes for the exact installed versions, and, when ClamAV is installed on the node, scans the site’s files for malware. Every node also runs the check on all its sites once a day.

Before you start

• WordPress is installed on the hosting and the hosting is active. A hosting without WordPress answers “hosting has no WordPress installation”.
• You hold the View WordPress vulnerability scans permission to read the row, and the Manage WordPress (plugins, staging, …) permission to click Scan now or a fix button.
• For the malware half, ClamAV is installed on the node that owns the hosting. Install it from Service health in the sidebar.

Steps

Read the row

1. Open Hostings in the sidebar, click the hosting, and open the WordPress tab.
2. In Updates & integrity, find Integrity & malware. It loads when it scrolls into view and shows one of four results, never a bare green dot:
   • Clean — files match WordPress.org, no malware found: both halves ran and found nothing.
   • Files verified — malware not scanned: checksums were compared, but no malware pass finished.
   • <n> file(s) don't match what should be on disk: something was found.
   • Couldn't check — nothing was verified, so this is not a clean result: wp-cli could not compare the site. The row prints why.
3. Read the coverage line under it: Checksums: core + <n> of <total> plugin(s) and Malware: ClamAV scanned the site's files, or not scanned with the reason. A result of “no findings” only means something once you know what was looked at.
4. Click Scan now to run it again. This re-reads every core and plugin file and can walk the whole document root with ClamAV, so it can take a minute.

Fix what it found

The row lists findings in groups.

• WordPress core lists up to 50 paths of each kind. modified — differs from the official release and missing — official file is gone are fixed by Repair core files. Click it and confirm. Hyperion downloads the release the site already runs and replaces core files only; wp-content, wp-config.php and the database stay as they are. The site is scanned again straight after, and the result shows Fixed: or Fix failed: above the new scan.
• shouldn't exist — not part of WordPress has no fix button. A stray file in wp-admin/ or wp-includes/ is either a leftover or the intruder’s own file, and only you can tell which. Open it, then delete it over SFTP or the file manager once you know what it is.
• Plugin <slug> — <n> file(s) don’t match wordpress.org lists up to 25 files. Click Reinstall <slug> and confirm with Reinstall plugin.
• ClamAV detections list up to 50 files with the signature that matched. No button is offered. Look at each file before removing it.
• <n> plugin(s) couldn't be verified — this is normal lists plugins wordpress.org does not host, such as premium plugins. They have no published checksums, so they are not covered. This is not a finding.

Before you reinstall a plugin from the row

Reinstall <slug> replaces the plugin’s whole folder with the same version from wordpress.org. Changed files are overwritten and added files are removed. The plugin’s settings live in the database and stay, and an active plugin stays active. Anything saved inside the plugin’s own folder is lost.

Confirm a backup first: open the hosting’s Backups tab and check that the newest entry shows the state ok. To undo it, restore that backup, or install the plugin again from its source. Without a backup, files that were only in that folder cannot be recovered.

Treat modified core files and files that should not exist as a compromise until you have looked at each path.

Check from a shell

hctl wp integrity-scan example.com

What runs on its own

• Daily integrity sweep. Each node verifies every active site’s core and plugins and runs ClamAV where it exists, once a day. The first run comes 6 minutes after the agent starts. The sweep is per site and on by default. It is off only where someone switched it off, and a care plan that includes File integrity & malware scanning keeps it on.
• ClamAV pacing. A site gets at most one ClamAV pass every 20 hours, and one that failed is retried after an hour. A node runs one clamscan at a time. A scan that finds the node busy keeps the previous malware result instead of waiting.
• Alerts. The administrators get “WordPress integrity check found changes” when a scan lists findings that the previous one did not, with counts of core files, plugin files and malware hits. A standing finding is not announced again every night. A scan that could not run is never stored over yesterday’s real findings.

Check that it worked

After Repair core files or Reinstall <slug>, the row shows Fixed: ... and the fresh scan no longer lists the file. A clean result reads Clean — files match WordPress.org, no malware found.

If it fails

• Couldn't check — nothing was verified with wp-cli couldn't compare this site against WordPress.org: the install is broken, wp-cli is missing, or the node cannot reach wordpress.org. See Repair a broken WordPress site.
• Malware: not scanned — ClamAV isn't installed on this node: install ClamAV from Service health.
• ClamAV is installed, but no pass over this site's files has finished yet: the first pass is pending or failed. The row shows the reason if it failed.
• Fix failed: ...: the message holds the node’s answer. For a plugin it includes the wp-cli output.
• “couldn’t read the installed version of <slug>, so it was not reinstalled”: the plugin’s version could not be read. Reinstall it from Plugins instead.