SiteFort security guide

Vulnerability Scanner

Many WordPress compromises happen because a patched vulnerability sits unaddressed for weeks. Recommended workflow for finding, prioritizing, and fixing known CVEs in plugins, themes, and core.

Security Guide Vulnerability Scanner Docs

Recommended workflow

Go to SiteFort → Vulnerabilities.

It's worth being precise about what this actually is, since the name invites a wrong assumption. This isn't a general "you're behind on updates" nag. It checks your installed plugins, themes, and WordPress core against a database of known CVEs, and only flags the ones with a confirmed security hole. Outdated-but-safe and outdated-and-exploitable are two very different categories, and this tool only cares about the second one.

Run this as a standing part of your maintenance routine, not something you reach for only after you already suspect a problem, by then a Critical finding could have been sitting there unaddressed for weeks:

Click Check Now to run an immediate check.
Review Critical and High issues first, before anything else on the list.
Update the affected plugins, themes, or WordPress core.
Delete anything you're not actively using, vulnerable or not. It's just as easy a target sitting idle.
For abandoned components with no patch coming, start planning a replacement now rather than waiting for the situation to force your hand.
Run another check after updating to confirm the findings are actually gone, not just assumed fixed.

If a License Required banner shows up, activate the license before you put any weight on the results shown. The check can't reach cloud CVE data without an active connection, so anything displayed without one isn't current.

The single most effective habit

Delete what you're not using. This is the cheapest win on this entire page and the one people skip most often. A plugin sitting deactivated is still a file sitting on your server, and deactivating it doesn't patch anything, an exploit targeting that plugin directly doesn't care whether it's switched on. If you installed something to test it once and never actually turned it on properly, that's not a safety net, it's dead weight with a CVE waiting to happen. Delete it.

Responding by severity

The scanner sorts findings by severity for a reason, so let that ordering do the work. Whatever order things happen to display on screen isn't the order to fix them in.

Severity	When to act	What to do
Critical	Immediately	Update, disable, or remove the affected component now, not at the next convenient moment. Check the Audit Log and Traffic Log for anything suggesting the vulnerability was already being used against you.
High	Same day	Update or remove the component, and check firewall and audit logs for suspicious activity around the same window. No patch yet? Disabling it until one lands is a reasonable trade.
Medium	Next maintenance window	Fold it into your normal update cycle. Don't let a Medium finding sit unresolved for more than a week or two, it's easy to let these quietly age past the point they're still "medium."
Low	Normal update cycle	Fix it during routine updates rather than ignoring it entirely. Severity classifications shift as exploitability becomes better understood, so today's Low is not a permanent label.

WooCommerce sites: a Critical or High finding in a payment, checkout, or customer-data plugin isn't just a technical item on a list, it's a business risk sitting in your store right now. Give it the same urgency you'd give an actual payment outage, because functionally, that's what it's one step away from becoming.

When you cannot update immediately

Sometimes there's no patch yet. Sometimes the update itself breaks something on the site. Sometimes the component is genuinely business-critical and pulling it means a planned migration, not a five-minute fix. None of these are reasons to just leave a known vulnerability sitting there unaddressed, they're reasons to put a temporary compensating control in place while the real fix gets arranged.

Situation	Recommended approach
No patch available for a Critical or High CVE	Disable the component if the site can survive without it for now. If it can't be disabled, use Firewall rules to restrict access to the affected endpoint while you plan a replacement. Write the exception down: severity, affected version, business owner, compensating control, target fix date. A verbal agreement to "deal with it later" tends to become nobody's job.
Update is available but breaks the site	Test it on staging, resolve the conflict there, then push to production. A staging conflict is a reason to fix the conflict, not a reason to sit on a known vulnerability indefinitely.
Plugin is abandoned with no maintained alternative yet	Restrict public access to the plugin's functionality through Firewall rules wherever you can. Treat finding a replacement as an actual project with a deadline, not a background task that quietly never gets done.
Client site managed by an agency	Flag Critical and High findings to the client immediately, in writing, with severity, affected component, and your recommended action spelled out. Resolving something silently without telling the client is the kind of shortcut that turns into a very uncomfortable conversation later.

Unresolved Critical and High findings stay visible on the SiteFort Dashboard on purpose. That's not a bug or an oversight, they genuinely affect the site's overall risk posture until they're fixed or the component is gone, and hiding that fact wouldn't make the risk any less real.