Is WordPress Secure?
Is it time to move on? WordPress has survived two decades of vulnerabilities, and the October 2026 PHP flaw was fixed for managed customers before most self-hosted sites had read the advisory.
The short answer
WordPress is as secure as the people running it, and in October 2026 that answer split the market in two. WordPress VIP, Pressable, Kinsta, WP Engine and Pantheon had the PHP2Shell flaw covered within hours; self-hosted sites were told to patch PHP or go offline. If nobody on your team owns that job, yes, it is time to move on, and a cloud-managed headless CMS such as Storyblok, Contentful or Sanity is where to go.
Key takeaways
- The October 2026 vulnerabilities were not in WordPress. They were in PHP itself, the language under every WordPress site, rated 9.2 out of 10 and exploitable without a login. WordPress.org said no WordPress update was required or planned, because there was nothing WordPress could do.
- Who hosts you decided how the week went. WordPress VIP told customers no action was required before the PHP team had published the details. Pressable, Kinsta, SiteGround, WP Engine and Pantheon followed within the day. Self-managed servers were advised by WordPress.org and the UK National Cyber Security Centre to go offline if they could not patch at once.
- WordPress still runs 39.6 percent of all websites and 58.3 percent of sites with a known CMS, per W3Techs on 27 October 2026. That is down from about 43 percent at the start of 2025, but no rival is close: Shopify is second at 5.3 percent.
- Most WordPress incidents come from plugins and themes, not core. Patchstack's annual counts put well over nine in ten reported WordPress vulnerabilities in third-party code. The fix for that is fewer plugins and someone who updates them, which is a staffing decision, not a software one.
- A cloud-managed headless CMS removes the server, the runtime and the plugin layer from your responsibility entirely. Storyblok, Contentful, Sanity, Contentstack, DatoCMS and Prismic patched nothing in October because there was nothing of theirs for a customer to patch. That is the strongest argument for moving on, and it only applies if nobody on your side wants to own operations.
Our analysts’ take
On 21 October 2026 the PHP project shipped an emergency release for two flaws that security researchers had already nicknamed PHP2Shell. Both allowed an attacker to run code on a server without logging in, both were rated 9.2 out of 10, and both lived in PHP's own memory handling rather than in any application written on top of it. The identifiers leaked a day early, the release was pulled forward, and Cloudflare reported thousands of exploit attempts before the announcement, hundreds of thousands within two hours of it and millions by the next day. Amazon later said its honeypots had seen an attempt on 17 October, four days before anyone outside the PHP security team was supposed to know. By 26 October the United States Cybersecurity and Infrastructure Security Agency had added both flaws to its catalog of exploited vulnerabilities and given federal agencies three days to fix them.
WordPress.org published its own notice the same day, and the most telling sentence in it was that no WordPress update was required or planned. There was nothing to update. WordPress is a PHP application, so every WordPress server on earth was exposed, and the only fix was a new PHP build installed by whoever runs the server. That is where the week divided. WordPress VIP told its customers, before the PHP team had released the details, that every site on the platform was already protected and no action was required. Pressable said the same for every PHP version it runs. Kinsta put interim protections in place and rolled the fixed builds out version by version through the day. WP Engine and Flywheel blocked the exploit at the CDN while PHP updates rolled out. Pantheon patched everything on PHP 8.2 to 8.5. Cloudflare turned on firewall rules for every plan, including the free one. If you were paying a managed host, your Tuesday was mostly reading status pages.
If you were running WordPress on your own server, you were on your own. The guidance from WordPress.org, echoing the UK National Cyber Security Centre, was to upgrade PHP immediately and, where that was not possible, to consider taking the site offline. Sites on PHP 8.1 or older got no new release at all, only source patches to compile yourself, and anything on PHP 7.3 or earlier got nothing. The popular community package repository that many Linux servers rely on said it would not have builds on day one. Configuration workarounds reduced exposure but, in PHP's own words, did not make an installation safe, and every PHP worker had to be restarted after any change. Researchers counted more than 1.3 million internet-exposed hosts that were potentially vulnerable. Some of them are still running the old build as you read this. That gap between the managed customer and the self-hosted one is the whole of this editorial, because it is the gap that decides whether WordPress is secure for you.
What to look for
- 1
Who patches the runtime
Ask your host, in writing, who updates PHP and the operating system, how fast, and whether you have to do anything. In October 2026 the right answer was an email that said no action required. If the answer is you, you are self-hosting, whatever the invoice calls it.
- 2
How many plugins you depend on
Count the active plugins and the people who update them. Each one is third-party code running with full access to your site, and most WordPress breaches start there. A site with eight plugins and a named owner is a different security posture from one with forty and nobody.
- 3
What is left to attack
A cloud-managed headless CMS exposes an editing interface and an API, both run by the vendor, and your website is a static or server-rendered front end with no database behind it. There is no PHP, no plugin directory and no admin login on your domain. Less to attack is the simplest security control there is.
- 4
Proof the vendor runs a security program
A SOC 2 Type II report, ISO 27001 and a published incident history tell you the vendor patches, logs and tests on a schedule rather than when a story breaks. WordPress VIP and the leading cloud headless vendors publish these. Self-hosted WordPress has none of them, because there is no vendor.
- 5
Whether marketers can still do their jobs
Moving on only works if the editing experience survives. Insist on a visual editor with live preview of your real site, scheduled publishing, roles and an approval step, and check that a marketer can build a landing page without a ticket. Every headless platform named here now offers that; the trial is where you confirm it.
Twenty years of incidents, and why this one was different
WordPress is no stranger to security headlines, and it is worth separating the kinds, because they call for different responses. Most of them were never about WordPress core.
Core flaws: rare, and fixed fast
The last core incident that defaced sites at scale was the REST API content injection flaw in WordPress 4.7.0 and WordPress 4.7.1 in early 2017, when well over a million pages were vandalised before auto-updates caught up. Core has shipped automatic security updates since 2013, and the core team's record since 2017 is good. Core is not where WordPress gets hacked.
Plugins and themes: the real surface
Patchstack's annual counts put well over nine in ten reported WordPress vulnerabilities in plugins and themes. The November 2024 Really Simple Security authentication bypass affected about four million installs; the August 2024 LiteSpeed Cache privilege escalation affected about five million. Each was a plugin you chose, running with full access, that somebody on your side had to update. That is the model: WordPress hands you the keys and the responsibility together.
PHP2Shell: the layer under everything
October 2026 was different because the flaw sat below WordPress, in the language runtime. No plugin audit, no core update and no security plugin could fix it, and the site owner's only lever was the server. For managed customers that lever was pulled by someone else before they woke up. For self-hosters it was a scramble, and for anyone still on an unsupported PHP version it was a dead end. The vulnerability was not a WordPress failure. It was a vivid demonstration of what owning the server actually means.
The grandfather clock: why people will not leave
WordPress has been around since 2003 and PHP since 1995. Both have outlasted every platform and language that was going to replace them, and both have earned a following that treats the question in this title as an insult. We understand the loyalty. It rests on real things.
The numbers are still enormous
At 39.6 percent of all websites and 58.3 percent of sites with a known CMS, WordPress is larger than the next ten platforms combined. Shopify is second at 5.3 percent, Wix third at 4.2 percent and Squarespace fourth at 2.4 percent. Every agency can build on it, every marketer has used its editor, and the talent pool has no equal. None of that changed in October.
Survival is evidence, up to a point
A platform that has absorbed twenty years of attacks and still runs two in five websites has proven something that a three-year-old product cannot. The core team is disciplined, the ecosystem reacts within hours, and the managed hosts have turned security into a product. For a publisher on WordPress VIP or a mid-market brand on Kinsta or WP Engine, the October release was a non-event, and that is exactly the outcome the loyalty predicts.
But the share is slipping, and the reason is operational
WordPress peaked at about 43 percent of the web at the start of 2025 and has lost ground every quarter since. The sites leaving are not the ones with a developer on staff. They are the marketing sites, the brochure sites and the campaign sites whose owners discovered that a free CMS comes with a part-time operations job, and that a hosted builder or a cloud CMS does that job for them. The clock is not ticking on WordPress. It is ticking on self-hosted WordPress run by people who did not sign up to run a server.
How to decide whether to move on
Here is where we land. The question is not whether WordPress is secure. It is whether your organization is set up to keep it that way, and the honest test is what happened on 21 October.
You read a status page and went back to work
You are on WordPress VIP, Pressable, Kinsta, WP Engine, SiteGround, Pantheon or a comparable managed platform, and your host patched PHP before you asked. Stay. Your remaining risk is the plugin list, so trim it, name an owner for updates, and ask the host for its security attestations at renewal. WordPress is secure for you because someone is paid to make it so.
You patched a server yourself, and it went fine
You have an engineer or an agency that owns the stack, patched PHP within hours and restarted the workers. WordPress is still a reasonable choice, but put a number on that person's time. If the same engineer also updates plugins, tests upgrades and watches the logs, you are paying for a managed host in salary and getting it with one point of failure. Price a managed tier against that cost before the next advisory.
You found out from this editorial
Nobody on your side knew who updated PHP, or the answer was a freelancer who built the site in 2021. This is the team the October release was aimed at, and the one that should move on. Not to a bigger WordPress, but to a platform where the server, the runtime and the plugin layer are the vendor's problem.
Where to move, and what you give up
Storyblok, Contentful, Sanity, Contentstack, DatoCMS and Prismic are cloud-managed, SOC 2 attested, patched by the vendor and built for a visual editor on top of a modern front end with no database on your domain. Published entry prices sit in the range a managed WordPress host charges. You give up the plugin directory, which is the point, and you take on a front end that a developer or agency builds once and a component library a marketer then works inside. Judge the editing experience in a trial on a copy of your own site before you sign.
If you stay, close the October gap for good
Move to PHP 8.2 or newer, because older versions get source patches at best and nothing at worst. Put the site behind a web application firewall; Cloudflare's rules blocked this exploit on every plan. Cut the plugin list to what you can name a reason for. Turn on automatic updates for core, plugins and themes, and write down who checks that they ran. If that list looks like a job, it is, and it is the job you are deciding whether to keep.
Platforms in this piece
WordPress
WordPress VIP
Storyblok
Contentful
Sanity
Contentstack
DatoCMS
PrismicFrequently asked questions
Is WordPress secure in 2026?
WordPress core is well maintained and ships automatic security updates, so the software itself is not the weak point. The risk sits in the plugins you add and the server you run it on. On a managed platform such as WordPress VIP, Kinsta or WP Engine, both are handled for you and WordPress is as secure as any cloud CMS. Self-hosted with nobody owning updates, it is one of the most attacked systems on the web.
What was the October 2026 PHP vulnerability and did it affect WordPress?
On 21 October 2026 PHP released fixes for two critical flaws, CVE-2026-109618 and CVE-2026-109619, nicknamed PHP2Shell, that let an attacker run code on a server without logging in. Every WordPress site was affected because WordPress runs on PHP, but no WordPress update could fix it. The patch was a new PHP build, PHP 8.5.12, PHP 8.4.27, PHP 8.3.36 or PHP 8.2.35, installed by whoever runs the server.
Did managed WordPress hosts patch the PHP2Shell flaw?
Yes, and quickly. WordPress VIP told customers that every site was already protected and no action was required before PHP published the details. Pressable said the same for all its PHP versions. Kinsta, SiteGround and Pantheon patched through the day, and WP Engine and Flywheel blocked the exploit at the CDN while PHP updates rolled out. Self-managed servers had to install the new PHP themselves or go offline.
What percentage of websites use WordPress in October 2026?
W3Techs reported on 27 October 2026 that WordPress runs 39.6 percent of all websites and 58.3 percent of websites whose CMS is known. Shopify is second at 5.3 percent of all websites, followed by Wix at 4.2 percent and Squarespace at 2.4 percent. WordPress's share peaked at about 43 percent at the start of 2025 and has declined slowly since.
Is a headless CMS more secure than WordPress?
A cloud-managed headless CMS such as Storyblok, Contentful or Sanity removes the parts of WordPress that get attacked: there is no PHP runtime, no plugin directory and no admin login or database on your domain, and the vendor patches its own platform under a SOC 2 program. The website becomes a front end with very little to exploit. It is not magic; your API keys, your front end hosting and your vendor's track record still matter.
Should I move off WordPress after the PHP security release?
Only if the release showed you that nobody on your side owns the server. Teams on a managed host had nothing to do and should stay, with a smaller plugin list. Teams with an engineer who patched within hours can stay if they price that time honestly. Teams who learned about the flaw after the fact, with a site built by someone who has moved on, should move to a platform the vendor runs.
About this editorial
This is a position our principal analysts took on October 27, 2026. It is not updated: when the view changes, we publish a new editorial. The scorecards linked above carry the current ratings for every platform named here.
Scorecards and platform inclusion are unsponsored: no vendor pays to be named in an editorial or to change a rating. Disagree with us? Tell us.
Still deciding?
Answer seven questions for a shortlist built around your team, or put two of the platforms named here side by side.