The problem with WordPress

In 2025, 11,334 new security flaws were disclosed across WordPress, its plugins and its themes, up 42 per cent on the year before. Nine in ten were in plugins. On the day they were made public, 46 per cent had no fix available. For the flaws attackers took an interest in, the first exploit attempt came a median of five hours after disclosure. Those are Patchstack’s figures, and Patchstack sells WordPress security, so read them as a vendor’s count; a second vendor, Wordfence, counts in the same range.

The arithmetic is the problem. A business site with 30 plugins depends on 30 developers it has never met, each of whom must notice a flaw, fix it, and publish the fix, after which someone at the business must apply it, all inside a window measured in hours. Many of those developers are one person. Some have stopped. Some have sold up.

In 2024 and 2025 the plugin figures were the story. In 2026 the trouble moved into the channel that was supposed to fix them.

A plugin vendor with 22 plugins in the directory was sold in 2025. In September, code was planted in its plugins; on 5 April 2026 it was triggered. WordPress.org closed all 22 two days later. In June, a different vendor’s own update server was compromised, and paying customers received backdoored builds through it. Also in June, script that a plugin vendor serves from its own network to sites running its plugins, installed on more than 1.2 million sites, was tampered with for several hours; a site that had done nothing but keep its plugins current was exposed. In July a plugin update carrying a backdoor was caught by WordPress.org’s reviewers and closed 26 minutes after they were told, which is the good news, and it was caught because the project had started holding releases. In October, stolen keys for a remote-management service were used to install backdoors on the sites connected to it.

None of those was a flaw in a plugin’s code that a diligent owner could have patched. They were the trusted channels themselves. The project’s answer, in June, was a cooldown before any plugin release reaches automatic updates, and from September an automated review of every release. Patchstack’s criticism is fair too: in one 17-day window the cooldown held 81 security fixes, for longer than the five hours attackers take.

Until this year, a fair critic had to say that WordPress core itself was not the problem. Patchstack counted six core flaws in 2025, all low risk, against 11,334 across the plugins and themes. That held for 2024 as well.

In 2026 it stopped holding. Core shipped about 44 security fixes in seven months. Two were critical and needed no login: one in July, with the first probing seen on the day of the release; one in September, with the first exploitation attempt the same day as the patch. Core still patches faster than any plugin and backports fixes to versions nine years old, which plugin developers do not. But “core is safe, only plugins are the problem” is no longer a fair summary.

• Security
• Maintenance
• New features

WordPress core releases per year, 2008 to 2026 (year to 28 October), by type

Year	Security	Maintenance	New features
2008	5	1	3
2009	1	6	2
2010	3	3	1
2011	5	1	3
2012	4	0	2
2013	3	1	3
2014	3	3	3
2015	6	1	3
2016	4	2	3
2017	7	2	2
2018	4	5	1
2019	4	4	3
2020	3	2	3
2021	4	2	2
2022	4	4	3
2023	4	2	3
2024	3	5	3
2025	1	3	2
2026	10	2	2

The dispute between Automattic, which runs WordPress.com, and WP Engine, a large WordPress host, began in September 2024 and is in litigation with a trial set for October 2027. A court restored WP Engine’s access to WordPress.org in December 2024. In January 2025 Automattic cut its sponsored contribution to the project to about 45 hours a week; in May it resumed. It has cut staff twice. The 2025 release cycle produced two major versions against the project’s usual three, and the 2026 one slipped.

Contributors did not leave: release credits rose through 2025 and eased in 2026. The community is intact. What changed is that a business owner can now see that the project’s direction depends on one company and one dispute, which was always true and was not always visible.

WordPress’s share of all websites was flat from 2022 to 2025, at around 43 per cent. From January to October 2026 it fell from 43.0 to 39.5 per cent, the first sustained fall in the series. The share did not go to a named rival; it went to sites with no identifiable system. No source shows what caused it. The security record and the dispute coincide with the fall. We do not say they caused it, because nobody has shown that they did.

WordPress remains the dominant system by a wide margin. Its community held 81 WordCamps in 39 countries in 2025, its directory holds more than 60,000 plugins, and every host sells a plan for it. Its editors are familiar to millions. Its core team patches fast and backports widely. Its pass rate on Google’s speed measures has risen three years running. A well-run WordPress site, with a few maintained plugins, a team that knows it and someone patching within 14 days, is a reasonable choice, and we look after sites like that.

The counter-case does not answer the arithmetic. It answers the question of whether WordPress is collapsing, which it is not, and leaves the question of whether a particular business can keep a plugin-heavy site patched inside a five-hour window, which most cannot.

If your site runs on WordPress, find out three things this week. How many plugins are active, and when each was last updated by its developer. Whether anyone applies security fixes within days, and how they would know a fix had been published. When a backup was last restored. If you cannot answer, the Website Risk Analysis answers them in writing, and ends with three options: fix in place, move, or wait. Sometimes the answer is to fix in place. Often, for a business site that does not need what WordPress is good at, the answer is a site with no plugins to patch and no login to attack, with every address kept. We will tell you which.