How to check client sites for vulnerable or closed plugins, without logging in
Updated 2026-10-10 ยท by Hieu Tran, written with AI agents and checked against the sources below
Your management dashboard says what it updated. To know what's actually running, check from the outside: every WordPress site serves files that reveal plugin versions, and WordPress.org and Wordfence publish what's outdated, closed or vulnerable.
Paste site addresses; it reads public files only and compares them with WordPress.org and the Wordfence Intelligence database.
What you can see from outside
Plugins in use: paths like /wp-content/plugins/<slug>/ in the page source.
Installed plugin version: the Stable tag line in /wp-content/plugins/<slug>/readme.txt, which nearly always matches the running version.
Core version: the generator meta tag or the RSS feed's generator line (many sites hide it, which is fine).
Theme version: the Version header in the theme's style.css.
What to compare against
Latest version: the WordPress.org plugin API returns the current version for each slug.
Closed plugins: the same API says if a plugin was closed, when and why (for example "Security Issue"). A closed plugin gets no more updates from the directory.
Known vulnerabilities: the Wordfence Intelligence feed (free API key) lists affected version ranges and the fixed version for each vulnerability.
Read the results with care
"Unauthenticated" vulnerabilities matter most: anyone can exploit them. "Administrator+" ones need an admin account.
Being a minor version behind isn't a problem by itself; a known vulnerability or a closed plugin is.
Older WordPress core branches still get security releases, so check whether a site is on the latest release of its branch.
Confirm any single finding in wp-admin before acting on it.