File Integrity Monitoring for WordPress: Choosing Tools and Setting Up Alerts That Catch Unauthorized Changes

One stealthy WordPress compromise often leaves one “quiet clue”: a core file or plugin file changes—sometimes within minutes—before malware ever shows on your pages. In my incident response work, the teams who recover fastest aren’t the ones who “installed more plugins.” They’re the ones running File Integrity Monitoring for WordPress with alerts they trust.

File Integrity Monitoring for WordPress is the practice of tracking cryptographic hashes (and file metadata) so you get notified when something changes that shouldn’t. In practical terms, it means you’re alerted when an attacker drops a webshell, modifies a theme template, or tampers with a plugin file—often long before search engines or visitors notice.

What “file integrity monitoring” means for WordPress (and what it doesn’t)

File integrity monitoring for WordPress is designed to answer one question: “Did any tracked files change since the last known-good state?” It works by comparing current file checksums and timestamps against a baseline you generate after updates or cleanups.

It’s not a malware scanner. Integrity monitoring catches changes; it doesn’t always tell you what the change is. That’s why strong setups pair integrity alerts with quick triage steps (we’ll cover them) so you can confirm whether the change is legitimate—like a plugin update—or malicious.

Why unauthorized changes happen (the real-world paths attackers use)

Unauthorized file changes are rarely random—they’re the payload. Attackers need a foothold first, and then they alter files to persist.

Here are common routes I’ve seen in real cleanups:

Stolen admin credentials: attacker logs in, uploads a plugin drop-in, or edits theme files.
Vulnerable plugins: an exploited plugin updates its own code to add backdoor logic.
Supply-chain tricks: tampered theme/plugin files get distributed or installed with minimal detection.
Write permissions misconfigurations: weak server permissions let malware write into uploads or even application directories.
Crontab-based persistence: sometimes the attacker changes cron scripts and relies on integrity alerts to be missed.

In 2026, the “classic” attack patterns still work, but the stealth layer is better. That’s where integrity alerts shine: even if the website looks normal, the file system tells the truth.

Choosing File Integrity Monitoring tools for WordPress: features that actually matter

Security professional reviewing file integrity alerts on a computer dashboard

The right tool for file integrity monitoring for WordPress is the one that matches your hosting reality and your alert workflow—not the one with the fanciest dashboard.

When evaluating tools, focus on these selection criteria:

1) Baseline control and “known-good” verification

You need a baseline you can trust. The best tools let you:

Generate hashes after a clean install, update, or confirmed malware removal.
Rescan on demand (before major deployments).
Store history so you can see when the change first appeared.

What most people get wrong: they start monitoring on a compromised site and treat the “first baseline” as clean. If you do that, you’ll train alerts to ignore the real problem.

2) Granular rules: what to watch, what to ignore

WordPress changes constantly during normal operations. Your tool should support include/exclude paths and file patterns so you don’t get alert fatigue.

Look for options like:

Watch: wp-content/plugins, wp-content/themes, critical core files, and uploads where you don’t expect executables.
Exclude: cache files, log files, and normal writable directories that change frequently (unless you need deeper visibility).

If the tool can’t separate “expected drift” from “suspicious drift,” you’ll stop reading alerts.

3) Alert delivery that reaches you immediately

The goal is to know within minutes, not days. Choose a tool that supports fast notifications like:

Email and SMS
Webhook integrations (Slack, Microsoft Teams)
Instant dashboard notifications with change summaries

In a recent case, the difference between recovery in 90 minutes versus 8 hours was simple: the client had integrity alerts routed to a team Slack channel. Everyone saw the first file change instantly, ran triage, and stopped the attacker from re-deploying the payload.

4) Performance impact and scanning frequency

High-traffic sites can’t afford slow or resource-heavy scans. As of 2026 best practice, aim for scheduled incremental checks (or near-real-time monitoring where possible) and reserve full scans for weekly/monthly windows.

Practical approach:

Every 5–15 minutes: quick integrity checks on high-risk directories.
Daily: verify core + plugin/theme integrity.
Weekly/monthly: full scan of the site root and server-side writable locations.

Exact cadence depends on your hosting. If you have shared hosting, start conservative and verify CPU usage during the first scan.

5) Compatibility with your hosting and permissions

Not every tool works the same way on every server. Some require:

SSH access
A specific cron configuration
File read permissions for checksum generation
Support for inotify or other filesystem event hooks

If you’re on managed WordPress hosting, your provider may offer built-in file integrity features or logs. That can be the lowest-friction path—especially for small businesses.

Tool comparison for WordPress file integrity monitoring (pros, cons, and best-fit scenarios)

Comparing tools helps you avoid the common trap: buying a “security suite” that doesn’t do integrity checking deeply enough to be useful during a cleanup.

Below is a practical comparison of approaches people commonly use. Availability and exact feature sets change often, so verify current capabilities before installing.

Approach	What it does well	Limitations / gotchas	Best fit
Server-level FIM (e.g., OSSEC/Wazuh, AIDE)	Strong integrity coverage; can monitor OS + web roots; reliable alerting.	Requires admin knowledge; tuning needed to avoid noise; setup time.	Teams with SSH/console access who want defensible security monitoring.
WordPress plugins for integrity monitoring (e.g., Wordfence, iThemes/other integrity add-ons)	Easy installation; lots of WordPress context; actionable alerts.	Must be configured carefully; performance depends on plugin settings; may rely on scheduled checks.	Small business sites that want quick coverage without server tooling.
CDN/WAF-side change signals (limited integrity)	Helps detect suspicious requests and some file upload patterns.	Not true integrity monitoring; won’t compute baseline hashes of your files.	Complementary layer for web attack protection (not a replacement for FIM).
Custom scripts (hash + log + notify)	Full control over what you monitor; lightweight; transparent.	More maintenance; easy to misconfigure include/exclude lists.	Technical teams or agencies standardizing security checklists.

My recommendation as a service provider: if you manage multiple client sites, server-level FIM (like Wazuh/OSSEC-style monitoring) plus a WordPress-aware plugin is often the best combo. If you can’t touch the server much, use a reputable WordPress plugin and add external alert routing so you don’t miss events.

Setting up file integrity monitoring for WordPress (step-by-step)

A successful setup is a process, not a single click. I’ll walk you through a workflow that catches unauthorized changes and reduces false alarms.

Step 1: Start from a clean baseline (or rebuild it)

If your site is currently compromised, an integrity baseline you create today will be “tainted.” During cleanups, I typically do one of two things:

Reinstall WordPress core files from a trusted source and restore plugins/themes from known-good versions.
Generate a baseline after malware removal, then immediately enable alerts.

Even if you’re confident it’s clean, take backups and ensure you can roll back changes quickly. Integrity monitoring is strongest when you pair it with recovery readiness.

Step 2: Define monitoring scope (high-risk directories first)

For most WordPress sites, begin with these directories and file types:

wp-admin and wp-includes (core)
wp-content/plugins (plugin code changes are frequent attack points)
wp-content/themes (theme edits can inject backdoors)
wp-config.php (high sensitivity—especially if it changes)
wp-content/uploads (watch for suspicious executable-like files)

Then decide how deeply to scan uploads. Many teams ignore it because it changes constantly. But attackers love to hide payloads there. A good compromise: alert on suspicious extensions and on changes to PHP files in uploads (which should be rare on sane setups).

Step 3: Configure exclusions to prevent alert fatigue

False positives kill monitoring. Set exclusions for:

Cache directories (like wp-content/cache)
Log files and temporary files
Generated assets that your build process updates predictably

Then test your alert rules by simulating a controlled change in a staging copy. If your tool can’t handle routine updates gracefully, adjust exclusions until it can.

Step 4: Set scan cadence and alert thresholds

Here’s a setup that works well for small business sites as of 2026:

Near-real-time / frequent checks for core + plugin/theme code changes.
Daily full verification to catch anything missed.
Weekly deep scan including uploads patterns and file permissions drift.

Alert thresholds should be strict for executable code (PHP/JS with suspicious patterns) and looser for static assets like images.

Step 5: Route alerts to the right place (and include enough context)

Your alerts must say:

Which file changed
What changed (hash mismatch, timestamp change, permission change)
When it changed
Whether the change is likely expected (e.g., during an update window)

If your alerts only say “Integrity violation detected” without the file path, you’ll waste time. Route them to Slack/email with file paths included so you can triage fast.

Step 6: Add a “change window” process for legitimate updates

This is the original insight I’ve used successfully in ongoing managed security: treat updates like maintenance windows and temporarily tag them.

Operationally:

Before updating plugins/themes, enable “maintenance mode” in your monitoring tool (or mark an update window in your incident log).
After updates finish, rerun an integrity check manually and confirm hashes match the new known-good state.
Disable maintenance mode so future unauthorized changes trigger alerts normally.

This reduces “who changed the files?” confusion and makes your alert signal-to-noise ratio dramatically better.

Configuring alerts to catch unauthorized changes specifically (not just “any change”)

The strongest alerts are selective. You want to catch unauthorized changes that matter most for WordPress compromise.

High-signal file events to alert on

Enable alerts for:

Hash mismatches in wp-content/plugins and wp-content/themes
New PHP files anywhere outside your expected locations
Changes to wp-config.php (especially salts, DB credentials, or injected lines)
Permissions changes that make files world-writable
Changes to critical entry points like index.php and theme functions.php

Suspicious pattern detection for quick triage

Even without deep malware analysis, you can set “triage hints” in your process. In a real case, we found injected code by searching for telltale patterns in changed files.

When you receive an integrity alert, scan the changed file for:

base64_decode usage followed by eval
Obfuscated gzinflate / str_rot13
Injected wp_insert_post or update_option logic
Unexpected require/include paths
Calls to external URLs (command-and-control behavior)

This won’t replace malware removal expertise, but it helps you decide whether to treat the alert as “legit update” or “incident now.”

Incident workflow: what to do when a file integrity alert triggers

Security team in a meeting triaging a detected file integrity change

When an alert fires, your first job is containment and validation. Don’t rush to delete files based on the alert alone—do a fast triage so you don’t break the site or remove the wrong thing.

Minute 0–15: contain and preserve evidence

Confirm the change window: Was there an update, deployment, or plugin install recently? If yes, compare expected files from the update.
Disable automatic updates temporarily if you suspect persistence (depending on your policy).
Preserve logs and the changed file: capture the exact file path and contents if your process allows.
Block the source if you can: IPs, admin logins, or suspicious accounts.

In many cases, the attacker re-infects after you remove one layer. Containment prevents the second payload drop.

Minute 15–60: verify legitimacy and compare against known-good

Now focus on whether the change is expected:

Compare the changed file with the same version from a trusted source (plugin repository tag or WordPress.org release).
Check file hashes against a clean baseline.
Review surrounding files for the same signature pattern.

If you have staging, deploy the same update there and run an integrity scan to confirm what normal changes look like.

Hour 1–4: remediation choices

Your response depends on severity and confidence:

Legitimate change: record it as the new known-good state and reduce alert noise for that path.
Likely malicious change: restore from backup/known-good and remove the attacker entry point.
Unclear change: isolate the site and run deeper analysis (often best handled by a security team).

This is where our service experience matters. If you need an internal checklist, our WordPress maintenance practices include the operational steps that prevent attackers from leveraging “routine negligence.”

Hardening after you enable integrity monitoring (so the alerts don’t become daily)

Monitoring is reactive; hardening is preventative. Alerts are your early warning system, but you still want to reduce the likelihood of unauthorized writes.

Lock down writable locations

Attackers often win by exploiting write access. Make sure file permissions are sensible:

Prefer restrictive permissions for core and code directories.
Allow writes only where WordPress needs them (uploads, specific cache folders).
Remove write permissions from directories that shouldn’t be modified by the web server.

This reduces the attack surface even if a vulnerability exists.

Restrict admin actions and limit plugin installation

In many breaches, the attacker isn’t exploiting a zero-day—they’re leveraging a weak process. Tighten workflow:

Use unique admin accounts and remove unknown users immediately.
Require approval for plugin/theme installs.
Use strong passwords and disable legacy authentication methods where possible.

It’s also worth adding your own “update window” process (described earlier) so admins don’t accidentally drown monitoring in noise.

Keep backups that restore cleanly

Backups aren’t just for disasters. They’re your fastest path out of an integrity-triggered incident.

For recovery speed, store:

Database backups
File backups (or a way to reinstall known-good code)
Snapshots with timestamps

Then validate restores regularly. A backup that can’t be restored is an expensive placebo.

Real-world use case: how alerts helped stop a theme backdoor

I’ve seen integrity monitoring catch the payload before it hit the public. In one Hack Case Studies engagement, the client’s site had no obvious defacement. Traffic looked normal, but integrity alerts flagged a modification to wp-content/themes/<theme>/functions.php.

The alert arrived about 12 minutes after a new admin account login attempt. The changed file contained obfuscated code and an unexpected include call. Because we had a known-good baseline from a recent maintenance window, we restored the file precisely and removed the malicious registration routine.

That decision reduced downtime from what typically becomes a multi-day cleanup to a same-day recovery. The main difference wasn’t “better malware removal.” It was faster detection and better change control.

To connect the dots with broader security response, you can also explore our threat alerts response playbook to see how we prioritize investigation when multiple signals fire.

Common mistakes that make file integrity monitoring fail

Most monitoring failures are configuration failures. Here are the mistakes I see most often:

Baseline created on an already-compromised site (alerts become useless).
Too many exclusions that hide the attacker’s favorite locations.
No alert routing to an actual human who reads it.
Alerts treated as “spam” and dismissed without triage.
Ignoring file permissions drift (attackers often change rights to persist).
Scanning only core and ignoring plugins/themes where payloads land.

If you fix just two things—trustworthy baselines and reliable alert routing—you’ll dramatically increase your odds of catching unauthorized changes quickly.

Conclusion: implement integrity alerts with a workflow you’ll actually follow

File integrity monitoring for WordPress works when it’s paired with disciplined baselining, smart monitoring scope, and an alert workflow that leads to action. Choose a tool that can track code directories (plugins/themes/core), deliver detailed notifications, and let you manage update windows so legitimate changes don’t drown your team.

Start today with this actionable checklist: confirm you have a clean baseline, enable integrity monitoring on wp-content/plugins and wp-content/themes, route alerts to Slack/email with file paths, and run a test scan after a controlled change. Then harden the writable areas and keep backups restore-ready—so the moment unauthorized changes show up, you can respond fast and recover clean.

Featured image alt text (for your CMS): “File integrity monitoring for WordPress showing checksum alerts for plugin and theme file changes”