WordPress itself had six reported vulnerabilities in 2025. Its plugins and themes had more than 11,000. Here's why the add-ons on your site are where the real risk lies, and why older sites are hit hardest.
When a WordPress site is breached, WordPress itself usually gets the blame. The numbers point somewhere else.
According to the security company Patchstack, 11,334 new vulnerabilities were found in the WordPress ecosystem in 2025. Only six were in WordPress itself, and Patchstack describes those as low priority. The rest were in plugins and themes: the add-ons that site owners install to get contact forms, page builders, shops, sliders and backups.
Critical flaws in WordPress itself make headlines precisely because they are rare. Plugin flaws are not. For most businesses running WordPress, the plugin list is where the real risk lives, and it is often the part of the site nobody is watching.
The plugin problem, in plain terms
A WordPress plugin is a piece of software, usually written by an independent developer, that adds a feature to your site. Once installed, it runs with the same access as WordPress itself. It can read your database, change files and respond to visitors. There is no wall between one plugin and the rest of the site, so one badly written plugin can be enough to compromise everything.
Patchstack publishes an annual report on WordPress security based on its own data. Its report on 2025 found:
- 11,334 new vulnerabilities, a 42% increase on 2024.
- 91% in plugins and 9% in themes. Six were in WordPress itself.
- 46% had no fix from the developer by the time they were made public.
- 1,966 (17%) were rated high severity, and Patchstack says highly exploitable vulnerabilities rose 113% year on year.
Paying for a plugin was no guarantee of safety. Patchstack received 1,983 valid reports about premium or freemium plugins and themes, 29% of the total, and found that premium components had three times as many vulnerabilities known to be exploited as free ones. Paying buys features and support, not necessarily better security.
The year before showed the same shape. Patchstack counted 7,966 new vulnerabilities in 2024, 96% of them in plugins and just seven in WordPress itself. It found that 43% could be exploited without logging in, and that 1,614 plugins and themes were removed from the official WordPress.org directory that year for unfixed security issues.
These are one company's figures, and other vendors count differently. But the direction is consistent: the overwhelming majority of WordPress vulnerabilities are in the add-ons.
What could go wrong for your business
Because plugins have full access, a flaw in one can expose everything the site holds or touches. Depending on the flaw, the realistic consequences include:
- Customer and business data exposed through the site's database.
- A defaced or hijacked website, or one quietly used to attack your own visitors.
- Downtime while the site is cleaned up or rebuilt.
- Recovery costs and staff time diverted from normal work.
- Damage to trust, along with possible reporting obligations if personal data is involved.
These risks are not only theoretical. In 2020, a flaw in the popular File Manager plugin (CVE-2020-25213) let attackers who weren't logged in upload and run their own code. NVD, the US government's vulnerability database, notes that it "was exploited in the wild in August and September 2020", and CISA lists it among vulnerabilities known to be exploited.
Plugins can also make a flaw in WordPress itself more dangerous. One of the wp2shell flaws fixed in July 2026 only mattered, in NVD's words, "when a plugin or theme passes untrusted input to the parameter". Plugins and WordPress share the same database and the same access, so a weakness in either is a weakness in both.
Could your website be next?
Attackers often use automated tools to scan large numbers of websites for known weaknesses, and plugins are an ideal target for this. W3Techs reports that WordPress runs 39.6% of all websites, and a single popular plugin can sit on hundreds of thousands of them. Once a flaw in that plugin is public, the question for an attacker isn't who you are, but whether your site has it installed.
Patchstack's figures show how little time there is. It found that about half of high-impact vulnerabilities were exploited within 24 hours, and for heavily exploited ones the weighted median time to the first exploit was five hours.
That means a small or low-profile site is not automatically safe. A local business with one outdated contact-form plugin can be found by the same tools as a large online shop. And a site that has never had a problem may simply not yet have had a vulnerable plugin that attackers were looking for.
This doesn't mean every WordPress site is vulnerable, or that an attack is inevitable. It does mean the risk depends heavily on which plugins you run, and how quickly their fixes reach you.
Why legacy PHP applications deserve attention
Plugin risk grows with age. A five-year-old WordPress site typically carries plugins installed by people who have since left, for features nobody remembers asking for. Some are no longer maintained. Some were customised directly, so updating them would wipe out the changes.
Fixes also depend on each plugin's developer. If the developer doesn't release one, and Patchstack found that 46% weren't fixed in time for disclosure in 2025, the vulnerable code stays on every site that has it installed.
The PHP version makes this worse. Each plugin states the minimum PHP version it needs. When a plugin's latest release needs a newer PHP than your server runs, WordPress won't offer you the update, and shows a message saying the new version "does not work with your version of PHP." The fix exists, but your site can't install it.
That isn't a rare situation. WordPress.org's own statistics show about 35% of the sites reporting to it running a PHP version the PHP project no longer supports, including 15.5% on PHP 7.4. As plugin developers raise their minimum requirements, those sites fall further behind, one plugin at a time.
To be fair, this isn't unique to WordPress or PHP. Every software ecosystem built on third-party packages has a version of it, including Node.js. What matters is control: how many outside components you depend on, whether you can see and update them, and whether your platform is current enough to accept the fix.
What this means for your organisation
The real security of a WordPress site depends on questions that are easy to ask and often hard to answer. How many plugins and themes does each site run, including inactive ones still on the server? Who maintains each one, and when was it last updated? Is WordPress refusing any updates because the PHP version is too old?
It is also worth asking a bigger question: does the site need to be built from dozens of plugins at all? Many business sites use WordPress for content plus a handful of custom features, such as a booking form, a product catalogue or a link to a CRM. Each of those is a plugin with its own developer, schedule and security record.
Understanding what you actually run is the starting point for any decision about where the site goes next.
Recommended next step
Take our free Legacy PHP Risk Assessment to understand how many plugins your sites depend on, which are still maintained, and whether your PHP version is blocking the fixes you need.
Then talk to our team about what the findings mean. Sometimes the right answer is a leaner WordPress site on a current PHP version. Sometimes, depending on the application and your goals, it is a move to a modern stack such as Node.js, where custom features are built into your own codebase and covered by your own tests. No platform is free of risk, but fewer unknown dependencies make that risk much easier to manage.
Free Legacy PHP Risk Assessment
Not sure how many plugins your sites run, or which ones are still maintained? We'll review your WordPress and PHP versions, plugins and themes, and hosting setup, and tell you plainly where you're exposed and what your options are.
