Guides · For agencies
Wordfence alert triage: how to prioritize scan findings
A Wordfence scan report is not a to-do list. It is a pile of claims of very unequal weight, from “there is a backdoor on this server” to “a plugin has a newer version”. Triage means deciding the order of work before fixing any of it. Done well it takes minutes; skipped, the day goes to whichever finding shouted loudest.
Four questions that classify any finding
Read the finding itself before opening update screens or deleting files. Four questions separate evidence from exposure, maintenance risk, and scan-health noise; the answers determine whether the next action is incident response, same-day remediation, scheduled work, or restoration of visibility.
- Is this evidence of compromise? A known-malicious file, malware in the database, or an administrator created outside WordPress describes something that already happened.
- Is this active exposure? A public configuration file or backup and an exploitable plugin vulnerability expose the site now even when no compromise is yet visible.
- Is this standing risk? An abandoned plugin, a firewall below full protection, or a weak low-privilege password gets worse with time rather than with the next few minutes.
- Is this operational noise? A scan that hit its time limit, low disk space, or another scan-health issue weakens visibility without itself proving the site is compromised.
Wordfence severity numbers, mapped
Wordfence stores native scan severities as numbers even though the interface usually shows names. These are fixed levels, not a CVSS score and not a probability that the site is hacked. Use the number for the first sort, then let evidence, exposure, site importance, and related findings override the mechanical order.
| Wordfence level | Number | Triage use | Typical shape |
|---|---|---|---|
| Critical | 100 | Interrupt and inspect now | Confirmed malicious content, public secrets, disabled protection, or another top-tier condition |
| High | 75 | Same-day review | Known vulnerability, suspicious administrator, modified distributed file, or serious scan failure |
| Medium | 50 | Weekly queue unless context raises it | Abandoned component or routine update/maintenance risk |
| Low | 25 | Batch, accept, or monitor | Low-impact information that still deserves a disposition |
| None | 0 | Do not treat as a security priority | Internal or ungraded state rather than an actionable severity |
The six-step Wordfence scan-results order
Use this category order as the default answer to “Wordfence found problems — what do I do first?” It is deliberately simple enough to hold in your head during a bad scan. Within a step, prefer the finding on the more exposed or more important site: a commerce site taking payments can outrank a parked brochure site even when the displayed number is lower.
- Malware. Start with known-malicious files, webshells, backdoors, database injections, and blocklist evidence. These are compromise-shaped findings, so preserve evidence and contain the site instead of treating them as ordinary cleanup.
- Login and administrator findings. An unexplained administrator is compromise wearing a uniform; a breached administrator password is one successful login away from it. Verify ownership, disable unknown access, and rotate credentials and salts.
- Public files and exposed secrets. A downloadable wp-config backup, database archive, log, or environment file can expose credentials. Remove public access and rotate what the file revealed; changing visibility alone does not revoke copied secrets.
- Known vulnerabilities. Confirm the affected installed version, public exposure, exploit status, and available patched release for each Wordfence plugin vulnerability. Patch exposed or exploited issues today and batch lower-context updates safely.
- File changes. A core checksum difference is often explainable, but sometimes it is the quieter sibling of a malware finding. Diff before replacing, correlate the timestamp with deployments, and escalate added executable code.
- Firewall and scan health. Restore the firewall's protection, resolve time-limit failures, and recover disk space last — unless broken visibility means you cannot trust the rest of the report.
Worked example from the live demo dataset
The WPSecureOps demo uses synthetic data. In one scan, certifiedmovers.net reports three Critical malware findings — a known-malicious file in uploads, a backdoor loader in mu-plugins, and an obfuscated webshell in cache — plus two High unauthorized-administrator findings. The right output is not five unrelated tickets. It is one probable-compromise incident with five pieces of corroborating evidence.
First, capture the three file paths, the two account names, scan identifier, detection time, hashes or signatures, and any relevant access logs. Second, contain the site and preserve copies of the artifacts outside the web root. Third, disable the unexplained administrators, rotate hosting and WordPress credentials, rotate WordPress salts to invalidate sessions, and restore affected code from known-clean sources. Finally, identify the entry point and check the client's related sites for the same component, account names, or indicators.
That cluster outranks a lone Critical vulnerable-plugin notice elsewhere because the cluster shows conditions on this installation, not only that a component could be exploited. It also changes the ownership and communication path: someone coordinates incident response, someone records evidence, and the client receives one coherent explanation rather than five alarming forwards.
When a finding stops being a fix
Most findings are fixes: update the plugin, remove public access, change the password, or restore a distributed file. Some are evidence, and evidence changes the job from routine remediation to investigation. The tells include a signature match, an unknown administrator, malware that returns after removal, multiple compromise-shaped findings on one scan, or executable code added to a core file.
Once that boundary is crossed, name an incident owner and separate containment from eradication. Contain what is actively dangerous, but retain enough information to reconstruct what happened. Cleaning without finding the entry point can produce a briefly tidy site that is scheduled to be compromised again.
Record decisions, not just fixes
Half of triage output is a decision not to act immediately: the abandoned plugin the client has accepted temporarily, a modified theme file that is a developer's deliberate patch, or a Medium finding scheduled for the maintenance window. Record the evidence, owner, reason, and review date where the next operator will see them. Use Wordfence's ignore function only when the reason remains visible in the team's operating record.
An unrecorded decision is made again after every scan by whoever is on rotation, usually with less context than the person before. This is why a finding should have one of four dispositions: fixed, scheduled with a date, accepted with a reason and review date, or escalated to incident response. “Seen” is not a durable disposition.
Make the queue finite
Triage works only against a queue that can reach zero. Work new compromise evidence immediately, assign same-day exposures, schedule maintenance findings, and record accepted items so they stop resurfacing as undecided. Then check that the next scan completed; remediation without a confirming scan leaves the result open to interpretation.
A cross-site queue adds one more useful question: does this repeat? The same vulnerable plugin on nine sites is one batch operation, and the same unauthorized account on two clients is a potential shared entry point. A per-site scan report cannot reveal that pattern until a human remembers another report. Whether the queue is a spreadsheet, Wordfence Central, MainWP, or WPSecureOps, its value is the ability to make the whole workload finite and owned.
Common questions
- Should I trust Wordfence's severity number as the work order?
- Use it for the first sort, not the final decision. Wordfence's native values — Critical 100, High 75, Medium 50 and Low 25 — describe the finding in isolation. They cannot know that a payment site matters more than a dormant brochure site, or that malware plus an unauthorized administrator on one scan forms a stronger incident story than either result alone.
- How long should Wordfence alert triage take?
- The sorting pass should take minutes each day; investigation and remediation are separate work. If classification regularly takes more than fifteen minutes, reduce upstream noise, aggregate the sites, or record recurring decisions so the same findings are not debated every week. A bad incident can take hours, but deciding that it is an incident should be fast.
- What if I cannot tell whether a Wordfence finding means compromise?
- Treat uncertainty asymmetrically. Preserve the evidence, contain what you can reverse safely, and get a second technical review before deleting artifacts. The cost of retaining a suspect file outside the web root and rotating credentials is usually small; the cost of dismissing a real backdoor or unknown administrator can be an extended incident with a destroyed timeline.
Referenced in this guide
- A known malicious file was found Malware
- An administrator was created outside WordPress Login
- A file appears to be malicious Malware
- Wordfence alert explainer Free tool
The other guides
- How to manage Wordfence across 10, 20 or 50 client sites
- Too many Wordfence emails? What to turn off and what to keep
Primary references
Product behaviour and remediation guidance were checked against these primary sources.