Why WordPress Is Releasing So Many Security Fixes (And Why Leaving Won’t Save You)

WordPress Security In The Age Of AI: Don't Blame The Platform

Stuart

Published on

Oct 29, 2026

–

min read

Over the last few weeks my timeline on X.com has been full of the same message: WordPress keeps shipping security fixes, so it is time to move your site somewhere else. Sometimes the suggestion is a static site, sometimes it is a newer CMS, and sometimes it is a site rebuilt with AI. Most of these posts are well meant, and a few of them are fair, but I think they miss what is actually going on.

I work at Automattic, so you should read this with that in mind. These are my own views and not an official position.

The short version is that I do not think WordPress is getting less secure. AI models have moved quickly from early experiments in 2024 to systems that Anthropic says can find and exploit zero-day vulnerabilities in every major operating system and web browser when directed to, and that pressure lands on anything connected to the internet. WordPress runs 39.5% of all websites according to W3Techs, so when it ships a security release people notice. Moving platform will not make the pressure go away.

By the end of this post you should know why WordPress is releasing security fixes faster than before, where the real risk in the WordPress world sits, and what I would do to protect a site today.

What people are saying about WordPress

The posts I have seen fall into a few groups. Some suggest moving compatible sites to static and keeping WordPress only as a back end for content updates. Some say a simple static site would suit most people better, because it is faster, cheaper and easier to move between hosts. Others announce that they have rebuilt their site with AI or switched to a newer CMS and are much happier. I have deliberately not named or linked anyone, because the point is the pattern and not the people.

Plenty of this has nothing to do with security. People are talking about speed, cost, and wanting to own their content as plain files. Those are reasonable things to care about, and for some sites a static build really is the better fit. Keeping WordPress as the editing back end and publishing static output is a sensible way to reduce exposure, and I have no argument with it.

The security angle is where I disagree, and it is also where the recent run of releases is feeding the mood. So it is worth looking at what has actually been released.

What WordPress has released in 2026

Here are three of this year’s core security releases:

WordPress 7.0.2 and 6.9.5 (17 July): the 7.0.2 announcement says it addresses one critical and one high severity issue, a SQL injection and a REST API batch-route remote code execution, reported by Adam Kues of Assetnote/Searchlight Cyber. Chained together they became known as wp2shell. According to The Register, exploitation was reported on the Friday night of the patch, and watchTowr’s honeypots recorded tens of thousands of exploitation attempts.
WordPress 7.0.3 (6 August): the announcement lists 12 security fixes, and Patchstack’s summary covers cross-site scripting, a multisite privilege escalation and an email confirmation bypass.
WordPress 7.1.4 (28 October): a short-cycle security release. The official announcement lists 13 security fixes, including a remote code execution issue in the upgrade process and several stored cross-site scripting bugs.

I want to be straight about this. The wp2shell bug was serious, it was in core, and it was exploited quickly. I am not going to pretend otherwise.

A quick timeline of AI and security bugs

To understand why this is happening now, it helps to look at how quickly the capability has moved.

30 November 2022: OpenAI introduces ChatGPT as a research preview.
October to November 2024: Google’s Big Sleep team reports an exploitable stack buffer underflow in SQLite, found before it reached an official release and fixed on the same day it was reported. The team described these as highly experimental results, which is fair, because it was an early one.
May 2025: the UK’s National Cyber Security Centre assesses that AI will almost certainly keep making parts of intrusion operations more effective and efficient, and says the time between disclosure and exploitation has shrunk to days. It also judges fully automated, end-to-end advanced attacks unlikely through to 2027, which is a useful bit of balance.
June 2025: EchoLeak (CVE-2025-32711), a zero-click prompt injection vulnerability in Microsoft 365 Copilot, is disclosed. According to the researchers’ paper, a server-side fix was deployed with no customer action required, and there was no evidence of exploitation in the wild. It shows that AI systems can become an attack surface in their own right.
7 April 2026: Anthropic publishes its assessment of Claude Mythos Preview. It reports that the model can find and exploit zero-days in every major operating system and web browser when directed to, including a 27-year-old OpenBSD bug, and that one browser exploit chained four vulnerabilities to escape both the renderer and operating system sandboxes. Anthropic says it does not plan to make the model generally available, and shared it with a limited group of partners through Project Glasswing, backed by up to $100 million in usage credits and $4 million in donations to open source security groups.
17 July 2026: wp2shell is patched in WordPress core, as covered above.
21 October 2026: Wiz publishes PHP2Shell, flaws in PHP itself that it found using AI models, and shows remote code execution on the latest WordPress, Drupal and Joomla container images. Wiz says a single researcher completed in a week what previously would have taken a world-class team months.

Nothing in that list says security got worse. What it says is that finding hard bugs has become faster and cheaper. Anthropic’s own examples include a bug that was 27 years old, which tells me the flaw was there long before anyone found it. Both wp2shell and Anthropic’s browser exploit also depended on chaining more than one weakness together. These bugs were always there. They are just being found faster, by defenders and attackers alike.

It is not a WordPress problem

This is the part I most want people to take away. Look at what was affected in that timeline: SQLite, OpenBSD, FFmpeg, FreeBSD, major browsers, PHP and Microsoft 365 Copilot. The PHP2Shell flaws sat in the language runtime that WordPress, Drupal and Joomla all run on. In my view, anything that is connected to or hosted on the internet is in scope.

That includes the alternatives people are moving to. A static site has no server-side runtime or database serving visitors, and I will give it that. But it still sits on a host, a CDN, DNS, a build pipeline, a pile of packages and an account somebody logs into to deploy it.

The JavaScript ecosystem that a lot of static site tooling sits on has had its own scare. In September 2025, according to AWS’s write-up, social engineering of a trusted npm maintainer’s credentials led to 18 popular packages, including chalk and debug, being compromised on 8 September. A self-propagating worm called Shai-Hulud followed from 15 September, and AWS says that over 180 npm packages were compromised within its first 24 hours. Neither incident involved WordPress. My point is only that every platform has a supply chain.

The wider numbers point the same way. CrowdStrike’s 2026 Global Threat Report says AI-enabled adversaries increased their activity by 89% year on year, covering 2025.

It also reports that the fastest breakout time it observed was 27 seconds, although the average eCrime breakout time was 29 minutes, which is the figure I would use if I was trying to be fair. These numbers come from a security vendor, so I would treat them as the direction of travel and not as precise measurements.

Why the releases are coming faster

The clearest explanation I have found is from the WordPress security team itself. Their Core Security Initiative and its two months in follow-up put some real numbers on it:

For about a decade the HackerOne programme received 20 to 30 reports a month.
It received 450 in July and 773 in August, and more than 3,000 so far this year (excluding spam), which the team says is more than the previous twelve years combined.
The team says much of this growth reflects the rapid advancement of frontier AI models.
That has meant four security releases in 41 days (7.1.1 to 7.1.4), and seven core security releases since mid-July, with more than 50 critical or high vulnerabilities closed.
The team has closed nearly 3,000 reports this year, and says the untriaged queue went from 359 to double digits.
73% of the 109 steps in a security release now have automation, and an AI-powered triage system reads and reproduces incoming reports, with security researchers still making the final call.

To me, that is not what a neglected project looks like. A jump from 20 to 30 reports a month to 773 in a single month, met with faster releases, more automation and a stated aim of driving open findings down to zero, looks like a well-run project responding to a changed world. I have seen enough from inside Automattic to know how seriously the people involved take this. To be clear, the Core Security Initiative is a WordPress project effort and I am not speaking for it.

Not every report is good, of course. Patchstack notes a significant increase in AI-generated “slop” reports in 2025, and the WordPress team’s triage system reproduces reports before a researcher makes the final call.

Where the real WordPress risk is

If there is something to worry about, I believe it is the ecosystem and not core. Patchstack’s State of WordPress Security in 2026 counted 11,334 new vulnerabilities across the WordPress ecosystem in 2025, up 42% on the year before. Of those, 91% were in plugins, 9% were in themes, and six were in core, all low priority.

Two other figures from that report stuck with me:

46% of vulnerabilities did not have a developer fix available when they were publicly disclosed.
For the most heavily exploited vulnerabilities, the weighted median time to first exploit was five hours.

The report also warns that attackers are equipped with AI that is increasingly capable of finding and exploiting vulnerabilities on its own. Put those figures together and you have a supply-chain problem, and it is the part of the WordPress world that deserves the most attention. Note that the six core issues were for 2025, so they predate wp2shell, and I would not read them as a promise that core will never have another serious bug.

What the future could look like

This section is opinion and not fact, and I would be glad to be wrong about parts of it. It is also where I have the least certainty, so I have anchored it to the sources above wherever I can.

Businesses. If the median time to first exploit for heavily targeted flaws is already measured in hours, I expect the gap between a patch and an attack to keep closing. A stack that cannot be updated quickly becomes a business risk.

Open source. Open code can be read by everyone, including attackers, but it can also be fixed by a wide group of people. The WordPress numbers suggest the real strain is on the maintainers handling the flood of reports, which is why efforts such as the Glasswing donations to open source security groups matter.

Proprietary software. Anthropic’s write-up describes the model reverse-engineering exploits on closed-source software, so I do not think closed code is safe simply because nobody can see it. I expect vendors to lean on their own AI-assisted review.

SaaS. You inherit your vendor’s patch speed. The best question to ask a provider, I think, is how quickly and how openly they respond to security reports.

Individuals. The basics matter more than ever: automatic updates, a password manager, two-factor authentication or passkeys, and fewer abandoned accounts and apps. The NCSC’s view is that AI will keep making intrusion more efficient, so there is no reason to expect the basics to matter less.

The common thread is speed. The people and projects that do well will be the ones who can detect, triage and patch faster, which is exactly what the WordPress security team is trying to build.

What I would do if I ran a WordPress site today

Here is the practical version:

Turn on automatic updates for core, and for plugins you trust.
Remove plugins and themes you are not using, and do not just deactivate them. The Hardening WordPress guide is a good reference.
Check when each plugin was last updated, replace anything that looks abandoned, and look plugins up in the Patchstack vulnerability database.
Keep backups and test a restore at least once. WordPress has a guide to backups.
Use two-factor authentication on every admin account.
Use a host or security service that can mitigate known exploits quickly.
Know in advance who will apply an emergency patch if something goes wrong at the weekend.

Should you leave WordPress because of security?

I think the faster pace of WordPress security releases is a symptom of better bug-finding tools and a team that is responding to them, not a sign that the platform is failing. If you have a good reason to move to a static site, such as speed, cost or simplicity, that is a perfectly good decision. I would just not do it because you think it makes you immune, because the same pressure is arriving everywhere.

What I would worry about is software that nobody is maintaining. In the AI era, I would choose platforms and plugins by how quickly they fix things and not by how few fixes they ship.

I would be interested to hear what you think. Are you seeing the same posts, and has any of this changed how you think about your own sites? Let me know in the comments.