How to Monitor WordPress File Integrity
How to monitor WordPress file integrity
Understand official core checksums, local baselines and what a changed file does—and does not—tell you.
File integrity monitoring helps you notice changes to a WordPress installation. It answers a narrow question: do these files match a reference? Understanding where that reference comes from matters as much as the result.
This guide explains the Integrity screen in Nimble Security Free. It does not present a scan of the NimblePlugins shop or claim that a particular installation is clean.
1. Separate core verification from local baselines
WordPress core files can be compared with official WordPress checksums. A mismatch deserves investigation: check the installed version and whether the file was changed intentionally before deciding what it means.
Plugins, themes and selected configuration files use local SHA-256 baselines. A local baseline records the files observed at a particular point in time. Later scans can identify changes from that point.
A baseline is not a cleanliness certificate. If a file was already compromised when the baseline was created, an unchanged hash does not reveal that history. Verify the origin of the files and investigate suspected compromise separately.
2. Start from files you can account for
Before relying on a baseline, record the WordPress, plugin and theme versions and any intentional customisations. Keep a backup and know where trusted replacement packages come from.
Use a demonstration installation when learning the controls. Do not publish screenshots containing live security findings, server paths or account details.
3. Run the initial integrity scan
Open Nimble Security → Integrity and review the screen before starting the scan. The initial scan creates the local baseline and verifies WordPress core.
The work runs in resumable chunks. Let it finish before drawing a conclusion from the results. Symbolic links are not followed. Core verification may contact WordPress.org for checksums; this integrity scan does not upload file contents.
4. Investigate a change in context
Compare a finding with your change history. A plugin update, a theme customisation or an unexpected modification can all change files, but they call for different responses.
Check which file changed, when the relevant update happened and whether the change matches a trusted package or an intentional edit. Avoid treating every change as malware, or treating every expected update as proof that all files are safe.
5. Keep integrity and malware scanning distinct
Integrity monitoring detects differences from a reference. Malware scanning looks for suspicious patterns using its available rules. Neither result alone guarantees that a site is free of compromise.
If a finding is unexplained, preserve the evidence and investigate before accepting it as a new normal. Quarantine, containment and access changes are separate response actions; this guide does not ask you to run them.
6. Review after updates
Make integrity review part of your update routine. Keep enough context to distinguish planned changes from surprises: versions, dates, customisations and the scan result.
If you update a reference baseline, do so only after reviewing the changed files. Otherwise you risk making an unexplained change the reference for future checks.
What this check can tell you
- Whether core files match the official reference used for verification.
- Whether locally baselined files changed since that reference was recorded.
- Which differences need further investigation.
It cannot establish the trustworthiness of an unknown starting point. Watch the file-integrity walkthrough and the other Security videos, or read what Nimble Security includes.