File Integrity Alert Fired — Investigate and Restore

What a File Integrity Alert Actually Means

The File Integrity Monitor runs on the guardpress_daily_scan cron hook and walks WordPress core, active plugins, the active theme, and the uploads/ directory. For each file it computes a SHA-256 hash via hash_file() and compares against the previous scan’s baseline. When a hash changes, the file appears as a row in the gp_file_changes table with one of three statuses, and a consolidated alert email is sent at the end of the scan (one email per scan since 1.6.24, not one per file).

The three statuses you’ll see in the File Monitor admin page:

• Added — the file didn’t exist at the previous scan and now does. Most common cause: a plugin update added a new file; less common but worth investigating: a webshell uploaded to uploads/.
• Modified — the file existed before, still exists, but its content hash changed. Most common cause: plugin / theme / core update.
• Deleted — the file existed before and is now gone. Most common cause: a plugin update removed a file that the new version no longer needs.

The alert is a signal, not a verdict. The signal is reliable (the hash comparison is exact). The interpretation is what this runbook is for.

Step 1: Rule Out Routine Causes

In the overwhelming majority of cases, file integrity alerts have an easy-to-recognise legitimate source. Check these first before assuming the worst:

Did a plugin or theme update just run?

Open WP Admin → Dashboard → Updates and scroll to the “Recently Installed Plugins” / “Recently Updated” sections. If anything updated in the last 24 hours, the file changes are expected. WordPress’s auto-updates run silently on a daily schedule for plugins and themes that opted in, so this is a more common cause than people expect.

Did WordPress core auto-update?

If the changed files are under /wp-admin/, /wp-includes/, or are top-level files like wp-blog-header.php, check whether WordPress core auto-updated to a minor version (security release) overnight. WP Admin → Updates shows current core version; if it’s a recent timestamp, that’s your cause.

Did you (or someone on your team) deploy code?

Custom themes, mu-plugins, and your own plugins won’t typically be auto-updated. But if you (or a developer / agency working on the site) ran a deploy, did a git pull on the server, or edited theme files in the WP admin theme editor, those files will show up as changed. Check your git log / deploy log / theme-editor history.

Did a security plugin or migration plugin run?

Some plugins legitimately write files during normal operation: SiteVault during a backup or restore, ForgeCache during cache regeneration, page builders generating CSS files (Elementor’s elementor/css/, Divi’s et-cache/). These directories should generally be in the file-monitor skip list (added in 1.6.7+ via guardpress_file_monitor_skip_patterns), but custom setups can still surface them.

Step 2: Identify the File Category (Determines Your Options)

GuardPress assigns every flagged file to one of four categories. The category determines whether you can Restore inline, and from where:

For categories 1, 2, and 3 you have a one-click recovery path. For category 4 you need a backup.

Step 3: Take Action

If Restore is available (categories 1, 2, 3)

If Restore is not available (category 4 — custom files)

The file has no canonical source GuardPress can fetch. Your options:

• Restore from a backup — if you’re running SiteVault Pro, open it and restore the affected file from a backup taken before the change. SiteVault stores per-file diffs so you can restore a single file without rolling back the whole site.
• If you (or your developer) made the change deliberately — nothing more to do. The new file content automatically becomes the new baseline on the next scheduled scan. No manual action is needed; the row simply stops appearing once the next scan establishes the new hash as the baseline.
• If you have no backup and don’t recognise the change — this is the hard scenario. Compare the file content against a known-good copy from your git repo, staging environment, or a previous deploy artifact. If the file looks malicious (PHP eval, base64-decoded payload, obfuscated code), run the Malware Scanner from GuardPress → Malware Scanner → Run Malware Scan Now and treat the site as compromised — see WordPress Malware Removal for the full cleanup path.

Recognising False Positives (Common Patterns)

These are file changes that look alarming but are almost always benign:

• Cache plugins regenerating CSS / JS — Elementor’s wp-content/uploads/elementor/css/, Divi’s wp-content/et-cache/, page-builder block CSS files. These regenerate on theme save, page edit, plugin update. Add these paths to the file-monitor skip list under GuardPress → Settings → Monitoring & Scanning if they’re noisy.
• Backup plugin working directories — wp-content/uploads/sitevault/, wp-content/updraft/, wp-content/backups*, wp-content/ai1wm-backups/. The file monitor in 1.6.7+ ships skip patterns for the most common backup plugin paths, but custom setups can still surface them.
• Vendor / node_modules in custom plugins — if your developer ran composer install or npm install on the server. The skip list covers vendor/, node_modules/, .git/, and .svn/ by default.
• SEO plugins regenerating sitemaps — some SEO plugins write a sitemap file to disk instead of generating it dynamically.

If You’re Getting Too Many File Integrity Emails

The emails are gated by deduplication state — pre-1.6.21 every daily scan re-emailed the same unresolved findings, and pre-1.6.24 the file monitor sent one email per changed file. Both bugs are fixed at 1.6.24+. If your inbox is being flooded, update GuardPress first. Full diagnosis flow at Quieting GuardPress Security Alert Email Flood.

Still Stuck? Email Priority Support

If you’ve worked through the triage flow and you’re not sure whether a file change is legitimate, or Restore is failing with an error, or you suspect a real compromise:

Email support@royalplugins.com with the diagnostic info below. Priority email support is included with your GuardPress Pro license — typical response time is within 24 hours, and we treat suspected-compromise tickets as highest priority.