The GuardPress File Integrity Monitor Explained
The File Integrity Monitor (FIM) watches every file on the site that shouldn’t change between plugin updates and alerts on unauthorized modifications. This article covers exactly what it monitors, how baselines are established, and what to expect on the day WordPress core auto-updates.
What’s monitored
Four distinct scopes, each with its own baseline strategy:
| Scope | Baseline source | What triggers an alert |
|---|---|---|
| WordPress core | Official WordPress.org core-checksum service for the currently-installed WP version | Any core file whose hash doesn’t match the WordPress.org record. Includes modifications and unexpected extra files. |
| Active plugins | Hash captured at plugin install / update time and stored locally | Any change to a plugin file that wasn’t made by a plugin update. Detects both direct file edits and injected code. |
| Active themes | Hash captured at theme install / update time | Same as plugins — changes to theme files not attributable to a theme update. |
| Uploads directory | No hash baseline (uploads change constantly). Pattern-based scan instead. | Suspicious file types (PHP files inside wp-content/uploads/), files with unexpected extensions, and files matching known-bad naming patterns. |
Core checksum comparison
The WordPress.org API publishes a canonical file-hash list for every WordPress core version. The FIM fetches the list for your current version and compares every core file’s SHA-256 hash against it.
This makes core file monitoring the most reliable of the four scopes: there’s an authoritative baseline (not one you generate locally), and any drift is definitively unauthorized. If wp-login.php has been modified, the FIM catches it regardless of when the modification happened, without needing to have had a baseline in place beforehand.
Plugin and theme baselines
Plugins and themes don’t publish authoritative file hashes the way WordPress.org does for core, so the FIM builds a local baseline at install time by hashing every file when a plugin or theme is first installed or updated.
When a legitimate plugin update happens, the FIM re-baselines automatically: the new hashes become the reference for future scans. When someone edits a plugin file outside of an update (via SFTP, via the wp-admin file editor if it’s enabled, or via injected malware), the file’s hash diverges from the baseline and an alert fires on the next scan.
Consequence for developers: if you’re actively editing a plugin (developing on it in place, patching a bug locally), the FIM will alert on every save. Either work on a staging site or add the plugin’s directory to the FIM ignore list temporarily.
Uploads directory suspicious-file scan
The uploads directory legitimately changes with every user-uploaded image, PDF, or attachment, so hashing every file is pointless. Instead the FIM does pattern-based scanning:
- PHP files inside
wp-content/uploads/. There is no legitimate reason for a PHP file to be in the uploads directory. Every hit is suspicious. If the Uploads PHP Execution Block is on, these files can’t execute, but the FIM alert still fires so you can investigate the upload path that created them. - Files with executable extensions:
.php,.phtml,.php3,.php4,.php5,.php7,.pht,.shtml. - Files with known-bad naming patterns from webshell drop-in campaigns (specific filename generators used by common exploit kits).
What to expect on WordPress core update day
WordPress core updates (major and minor) change every core file’s hash. On the next FIM scan after a core update, expect a large batch of “file changed” alerts — every modified core file will be flagged.
These are expected changes, not tampering. Two paths to clear them:
- Wait for the automatic reconciliation. The FIM re-fetches the current WordPress.org checksum list on every scan; once your site is on the new version, the fresh checksums match and the alerts clear themselves.
- Acknowledge them explicitly from the File Monitor admin page. This forces the alert to clear immediately.
If you see a large FIM alert batch and there was no recent WordPress core update, treat every changed file as potentially malicious and see File Integrity Alert Investigation for the triage flow.
- File Integrity Alert Investigation: the triage flow when the FIM flags an unauthorized change
- Malware Scanner Explained: the sister module that catches malicious content within files, complementing the hash-based drift detection
- Uploads PHP Execution Block: the config change that neuters any PHP file that ends up in the uploads directory