# The GuardPress File Integrity Monitor Explained
> GuardPress File Integrity Monitor detects unauthorized changes to core, plugin and theme files via baseline hashes, WordPress.org checksums and daily scans.
- Canonical:
- Last updated: 2026-09-27
- HTML version:
---
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.
### Daily background scan + on-demand
The FIM runs once per day as part of the scheduled security check cycle. You can also trigger a manual scan any time from **GuardPress → File Monitor**. See [File Integrity Alert Investigation](https://royalplugins.com/support/guardpress/file-integrity-alert-investigation/) for the triage flow when it flags something.
## 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](https://royalplugins.com/support/guardpress/uploads-php-execution-block-setup/) 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](https://royalplugins.com/support/guardpress/file-integrity-alert-investigation/) for the triage flow.
Related
- [**File Integrity Alert Investigation**](https://royalplugins.com/support/guardpress/file-integrity-alert-investigation/): the triage flow when the FIM flags an unauthorized change
- [**Malware Scanner Explained**](https://royalplugins.com/support/guardpress/malware-scanner-explained/): the sister module that catches malicious content within files, complementing the hash-based drift detection
- [**Uploads PHP Execution Block**](https://royalplugins.com/support/guardpress/uploads-php-execution-block-setup/): the config change that neuters any PHP file that ends up in the uploads directory
[Back to GuardPress Support](https://royalplugins.com/support/guardpress/)
[GuardPress Plugin Page](https://royalplugins.com/guardpress/)