WordPress runs a large share of the web, which makes it worth attacking at industrial scale. But the core software is maintained by a serious team and patched quickly. Nearly every compromise arrives through something you installed on top of it.
That distinction is the whole of it, and it changes what you should actually do. "Keep WordPress updated" is good advice that addresses the smaller half of the problem.
Where the vulnerabilities are
A WordPress installation is core plus a plugin and theme ecosystem of extraordinary size, built by tens of thousands of separate authors with no shared review process, no common security standard, and wildly varying levels of ongoing attention. Core is one codebase with a security team. The rest is a supply chain.
That is why the vulnerability numbers are so lopsided: the overwhelming majority of publicly disclosed WordPress vulnerabilities are in plugins and themes rather than in core. Not because plugin authors are careless, but because there are so many of them and most are individuals maintaining something for free.
The four situations that actually cause trouble
1. The plugin nobody updates because nobody uses it
An installed but deactivated plugin still has files on disk. Depending on the vulnerability, that can be enough — some flaws are reachable without the plugin being active, because a PHP file sitting in the plugin folder can be requested directly over the web and will execute whether or not WordPress ever loaded it. More commonly, a plugin installed years ago for a form or a slider is still active, still loaded on every request, and has not been updated because nobody remembers it is there.
The practical instruction: delete what you do not use. Not deactivate — delete.
2. The plugin that was removed from the directory
This is the one most site owners have never heard of, and it is the most dangerous.
When a serious unpatched vulnerability is found in a plugin, WordPress.org can close it — it disappears from the directory and cannot be installed by anyone new. What does not happen is any change on the tens of thousands of sites already running it. There is no update. Plugins get closed for several different reasons — an unfixed security report, a guideline breach, a licensing problem, sometimes the author's own request — and the effect on you is identical in all of them: nothing is pushed to the sites already running it. Your dashboard shows no notice. The plugin simply continues working, permanently vulnerable, while its vulnerability is publicly documented.
You will not find out from WordPress. You find out by checking what you run against what has been published about it.
3. The nulled theme
A commercial theme or plugin obtained free from somewhere other than the vendor is about the most reliable way to be compromised there is: the modification is usually the point of the distribution, and a licence check is rarely the only thing that was removed. This one is a straight cost decision made years ago that nobody has revisited.
4. The exposed login
WordPress login pages are at a predictable address and are attacked continuously and indiscriminately — essentially every WordPress site with a reachable login page receives automated credential attempts, regardless of size or traffic. Two-factor authentication on every administrator account matters more here than any plugin you could install, and it costs nothing.
xmlrpc.php deserves a mention: its system.multicall method packs many authentication attempts into a single HTTP request, so an attacker can try hundreds of passwords per request and slip under any rate limit that counts requests. If nothing you use needs it — and most modern sites do not — turn it off.
What an attacker is actually doing
It is worth being clear that this is not targeted. Nobody chose your site. Automated tools scan enormous ranges of the internet, fingerprint what is running, and try known exploits against the versions they find. The entire process is unattended.
Two consequences follow. First, "we are too small to be a target" is not protective, because there is no targeting. Second, the window between a vulnerability being published and being exploited at scale is short — often days. The relevant question is not whether you will eventually update, but whether you would know within that window.
And the payoff usually is not your data. A compromised WordPress site is more often used to host phishing pages, inject spam links into your pages for someone else's search rankings, or serve malware to your visitors. Which means the damage lands on your reputation and your search visibility before you notice anything is wrong.
What to actually do
- Delete every plugin and theme you are not using. The most effective single action, because it removes risk rather than managing it.
- Enable automatic updates for core, and for plugins you trust. The argument against auto-updates is that one might break something. Weigh that against the alternative, which is a week of exposure while you find time to look.
- Two-factor authentication on every administrator account. No exceptions, including the developer who set the site up three years ago and still has access.
- Audit who has administrator rights. Old agencies, former employees, a contractor who did one job. Each is a live credential.
- Check what you run against what has been published about it — repeatedly. This is the part that cannot be done once, because the answer changes without your site changing.
- Make sure your backups are restorable and not on the same server. Untested backups are a plan, not a safeguard. And a backup file left in the web root is its own exposure.
An honest note on scanning
An external scanner can enumerate the plugins and themes a WordPress site loads, with versions where they are visible, and match them against published vulnerabilities. That is genuinely useful and it is how you find the closed-plugin case above.
But coverage of plugin vulnerabilities in the general vulnerability databases is thinner than for mainstream server software — the plugin ecosystem is large, fragmented and poorly indexed by the national databases. So a clean result on plugins is weaker evidence than a clean result on your web server, and anyone who tells you otherwise is selling something. Treat plugin hygiene — delete what you do not use, update what you keep — as the primary control, and scanning as the thing that catches what hygiene missed. The underlying mechanism is worth understanding if you are going to read scanner output at all: why vulnerability scanners report false positives explains why thin, badly-indexed advisory data produces both false alarms and false clean results.
Is WordPress secure?
WordPress core is maintained by a serious security team and patched quickly, so the core software is not usually the weak point. The overwhelming majority of publicly disclosed WordPress vulnerabilities are in plugins and themes, which are built by tens of thousands of separate authors with no shared review process and varying levels of ongoing attention. In practice, asking whether WordPress is secure is the wrong question — the answer depends almost entirely on what you installed on top of it.
What happens when a WordPress plugin is removed from the directory?
A closed plugin disappears from WordPress.org and cannot be installed by anyone new, but nothing changes on the sites already running it. There is no update: plugins are closed for several different reasons, and in all of them nothing is pushed to the sites already running it. Your dashboard shows no notice and the plugin keeps working, permanently vulnerable, while its vulnerability is publicly documented. You only find out by checking what you run against what has been published about it.
Should I delete or just deactivate unused WordPress plugins?
Delete unused WordPress plugins rather than deactivating them. A deactivated plugin still has its files on disk, and depending on the vulnerability that can be enough to be exploitable. Deleting removes the risk rather than managing it, which makes it the single most effective thing most site owners can do — more effective than any security plugin they could install in its place.
Why would anyone attack my small WordPress site?
Nobody chose your site — that is the point. Automated tools scan enormous ranges of the internet, fingerprint what is running and try known exploits against the versions they find, entirely unattended — so being small is not protective, because there is no targeting. The payoff is usually not your data either: compromised sites are typically used to host phishing pages, inject spam links for someone else's search rankings, or serve malware to your visitors, which means the damage lands on your reputation and search visibility first.
Where VulnControl fits
VulnControl identifies the software your site actually runs from the outside — WordPress core, the plugins and themes it loads with versions where they are visible, the web server and the JavaScript libraries — and matches each against a nightly-refreshed vulnerability database, marking anything confirmed to be under active attack. It also finds the adjacent exposures that come with a long-lived site: an admin panel reachable from anywhere, a database port left open, a backup file still sitting in the web root.
It is honest about the limit described above: plugin vulnerability coverage is thinner than core coverage, and a version it cannot establish is reported as unverified rather than clean.