No. Whether a plugin vulnerability can be exploited on a given site depends on the installed version, whether the plugin is active, which feature is affected and whether that feature is turned on or reachable. Check each of those before ranking urgency, but do not use them to delay patching without a written reason.
Four questions per site
- Is the affected version installed? Compare against the advisory's range, not just the plugin name.
- Is the plugin active, or sitting inactive on disk? Inactive plugins are not loaded by WordPress, but their files are still present, so keep them in your inventory and remove them.
- Is the vulnerable feature in use? Some flaws affect one shortcode, one block, an import tool or one endpoint.
- Who can reach it? A flaw that needs an administrator login is a different urgency from one that works for any visitor.
Your inventory export from the WP-CLI list command gives the first two answers for every site in minutes. See how to list every plugin across client sites.
Turning answers into priority
| Situation | Suggested handling |
|---|---|
| Affected version, active, feature in use, reachable by visitors | Patch today, with a staging smoke test |
| Affected version, active, feature unused | Patch in the next window and note why |
| Affected version, inactive | Delete the plugin |
| Not in the affected range | Record and move on |
| Fix not available | Mitigate and document, see below |
When no fixed version exists
Disable the feature if you can, restrict access, or remove the plugin and replace it. Our post on what to do when a plugin vulnerability has no fix uses a different ecosystem but the same logic. Record the decision and an expiry date for the exception.
Where code level analysis helps
For bundled libraries inside a plugin, the real question is whether the plugin ever calls the vulnerable function. Reachability analysis answers that by tracing call paths. It is most useful for applications you build yourself, such as Composer based projects, where you have the full dependency tree. For a closed premium plugin you often cannot inspect the code, so you rely on vendor statements.
Be careful with the shortcut
Reachability is a way to order work, not a way to skip it. An unreachable flaw today can become reachable after a configuration change or a plugin update, so keep the patch on the schedule.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a long finding list shrinks once unreachable paths are set aside.
A worked example
Take three client sites that all run the same plugin at an affected version. On the first, the vulnerable import tool is used weekly by staff. On the second, the plugin is active but the import tool was never enabled. On the third, the plugin is inactive. Patch the first today, the second in the next window with a note, and delete the plugin from the third. All three get an action, and the order follows the real exposure.
Quick check
Can I ignore an advisory for an inactive plugin?
Do not ignore it. Remove the plugin, since inactive code on disk adds nothing but risk.
Does low reachability mean never patch?
No. It sets the order, and the patch should still follow.
Sources
Last reviewed: 19 October 2026.
