← WordPress Security for High-Stakes Sites
What is file integrity monitoring on WordPress?
File integrity monitoring compares the files on a WordPress site against a known-good baseline on a schedule and flags anything added, modified, or deleted. It turns “someone changed something” into an alert that lists the files. The goal is to find an unauthorized change within one scan interval instead of hearing about it later from a visitor, a search engine, or a client.
How does a baseline comparison work?
The baseline is a record of the site’s files in a state you trust. Each scan records the files again and compares the two.
A typical record holds each file’s path and a hash of its contents. A hash is a short fingerprint calculated from the file, so changing a single character produces a different one. Comparing hashes is stronger than comparing modification times, because a file’s owner can set its modification time to any value, and on hosts where PHP runs as the file owner, so does code an attacker gets running.
Each scan produces three kinds of difference:
- Modified: the path is in the baseline but the hash differs.
- Deleted: the path is in the baseline but no longer on the server.
- Added: the path is on the server but not in the baseline.
Core files have a public reference. The WP-CLI command wp core verify-checksums compares installed core files to the checksums WordPress.org publishes for that version, and wp plugin verify-checksums does the same for plugins hosted on WordPress.org, per the core and plugin command pages. Those commands check once, when you run them. The core check also skips everything under wp-content and does not cover wp-config.php or .htaccess, so themes, custom code, plugins not hosted on WordPress.org, uploads, wp-config.php, and .htaccess all need a baseline you build yourself.
Two design points decide whether a baseline is useful. The first is where it lives: a baseline stored where the monitored site’s credentials can write to it can be edited by whoever compromised the site. The second is upkeep. Every legitimate release changes files, so the baseline has to be refreshed as part of the release, or every deploy becomes an alert and people learn to ignore the channel.
What should you do when an alert fires?
Work out whether the change was expected, then record the decision either way. Many alerts are legitimate changes, such as a plugin update or a deploy, and the job is to confirm that quickly so real alerts stand out.
A short triage:
- Check the release record. Was a deploy, update, or admin change made in the window between the last scan and this one, by someone authorized?
- Read what changed. A core or plugin file modified outside an update, a new PHP file in a directory that should only hold uploads, or an edit to wp-config.php or .htaccess all deserve attention.
- Decide: expected, or unauthorized. Write down who decided and why.
- If expected, refresh the baseline so the change stops alerting.
If the change is unauthorized, treat it as an incident and hand it to whoever owns the incident response plan.
What should a scan exclude, and how often should it run?
A scan should exclude what changes legitimately and constantly, and nothing broader. Typical candidates are cache directories, log files, and generated assets. Exclude narrowly, because an excluded directory is a place an attacker can write without triggering an alert.
Uploads change constantly, so excluding image files there is reasonable. Executable files do not belong in an uploads directory, so keep a rule that flags a new PHP file there.
Frequency is a trade between server load and detection delay. The time between scans is the longest a change can go unnoticed, so a site where an incident is costly should scan more often than a brochure site.
Who should receive the alerts?
A person who can act on them, through a channel they actually watch, with a named backup.
Decide in advance who triages, who they escalate to, and how quickly a first look is expected. Route alerts so they cannot all be silenced by one filter rule or one person on vacation, for example email plus a team chat channel.
Is file monitoring enough?
No. Monitoring detects a change after it has happened and does not prevent it.
It also has blind spots. It reads files, so it will not show a rogue administrator account created in the database, or spam content added through the editor. A malicious change shipped inside a legitimate plugin update looks like any other update, and the baseline refresh after the release accepts it.
Use it alongside hardening, which reduces how easily a file can be changed, and tested patching, which keeps known flaws closed. An activity log covers the database-side changes file monitoring cannot see, such as new admin accounts and content edits; see what an audit trail should capture.
What monitoring has 84EM built?
We built our own file monitoring system. Per its internal systems page, it verifies every file against a known-good baseline and “runs scheduled scans in the background,” with configurable scan scope, exclusions, and schedules, and email and Slack alerts that list the affected files.
That system does not run on client sites. Client sites in our Website Security service get file integrity checks as part of “monitoring for unauthorized change,” alongside hardening and tested patching.
