PHP broke the internet again. Why WordPress should have retired in 2015, and what to build instead

On 21 October 2026 the official advice included taking websites offline

On 21 October 2026 the UK National Cyber Security Centre published an alert headed "Critical security issue affecting PHP". PHP is the programming language underneath WordPress, WooCommerce, Joomla, Drupal, TYPO3, Magento and a long tail of booking, membership and shop software. The alert said the flaws "may allow attackers to execute commands on any web server running PHP", and that under certain conditions this means unauthenticated remote code execution: a stranger on the internet making your server run their instructions, with no password and no login.¹

One sentence turned a routine patch notice into a bad week for a lot of businesses: "Organisations using any version of PHP are affected." The recommended actions were to find every PHP system, starting with anything facing the internet, update it, apply the temporary mitigations if an update was not possible, and if neither could be done, "consider taking the system offline until it can be fully mitigated". The NCSC also asked organisations to check for signs of compromise before patching, because an attacker who got in first may have left a back door that survives the update.¹

The United States agency CISA went further. Its alert the same day said the flaws "affect all PHP installations serving web requests" and that systems which cannot be updated straight away, or still run PHP 8.1 or earlier, should be taken offline until they are patched or upgraded.² On 26 October 2026 CISA added both flaws to its catalogue of known exploited vulnerabilities, which it does only when it has evidence of exploitation in the wild.³

If your website runs on PHP and you have not checked it since, stop reading and check it now. The rest of this article will still be here.

What the two flaws actually do

The two issues carry the catalogue numbers CVE-2026-109618 and CVE-2026-109619, and security researchers nicknamed the pair PHP2Shell. The PHP project rated both critical, 9.2 out of 10 on the current scoring system (CVSS version 4).⁴⁵

You do not need the internals, but the shape explains why the fix was urgent. The first flaw sits in how PHP handles running out of memory. When a request hits its memory limit, PHP abandons it in a hurry, and some parts of PHP can be left holding memory that was never properly set up. The clean up routine that runs afterwards can then read or act on that garbage. The PHP project's own advisory says an attacker can reach this state with a crafted upload form request and get code running as the web server's worker account, and that this was demonstrated over plain HTTP against Apache with mod_php in its normal configuration.⁴ The second flaw is stale state: some of PHP's global bookkeeping can keep pointing at memory from a request that has already finished, and the next request can pick it up before it is cleaned.⁵

Fixed releases came out the same day: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The advisory is clear that updating is the only complete fix. Its temporary measures, such as changing the memory limit or blocking upload form requests at the front door, reduce the risk but do not remove it.⁴

Why one flaw in PHP reaches so much of the web

Most security stories are about one product with one bug. This one is about a foundation.

According to W3Techs, PHP is the server language of 68.8% of the websites whose server language can be identified, and WordPress alone runs 39.3% of all websites, 58.0% of the sites whose content system is known (figures dated 11 November 2026).⁶⁷ The NVD record for the first flaw also lists industrial and building products from Siemens that ship PHP inside them, which is why the alert told organisations not to stop at their website.⁵

The version picture makes it worse. Among PHP websites, W3Techs counts 66.8% on PHP 8, 25.6% on PHP 7 and 7.5% on PHP 5.⁷ The PHP project currently supports only the 8.2, 8.3, 8.4 and 8.5 branches, so every site on PHP 7 or 5, and every site on 8.0 or 8.1, is running a version that the project itself no longer patches.⁸

That is roughly a third of PHP websites on a major version with no upstream fixes at all, before you even ask how many PHP 8 sites are on 8.0 or 8.1. When the whole web shares a foundation, a crack in it is everyone's problem at the same moment. Attackers know this. You are not targeted because someone dislikes your business. You are targeted because a script scanning the whole internet found your address and your server answered.

The weak point is the plugin model, not WordPress core

Fairness matters here, because a rant is less persuasive than the evidence.

WordPress core is maintained carefully. Patchstack, a security company that tracks the WordPress ecosystem, counted 11,334 new vulnerabilities in that ecosystem in 2025, 42% more than in 2024. Only six were in WordPress core, all low priority. Plugins accounted for 91% and themes for 9%.⁹

The same report shows why that matters. In 46% of cases the developer had not released a fix by the time the vulnerability was made public, and for the most heavily targeted flaws the weighted median time from disclosure to the first exploit attempt was five hours.⁹ A typical business site is not "WordPress". It is WordPress plus a theme plus twenty or forty plugins from as many different authors, on a shared host, with an admin login that several people have used over the years. Its security is the security of the weakest of those parts, and of whichever of those authors patches last.

PHP2Shell is a different kind of problem again. It is not in a plugin at all, but in the language every one of those parts runs on. So a WordPress site carries two layers of shared risk: the plugin layer, which leaks constantly, and the language layer, which leaks rarely but all at once.

My opinion: new business critical builds on this model should have stopped around 2015

Here is the opinion, and it is mine. By around 2015 there were mature, well documented alternatives running serious businesses. Ruby on Rails had been in production for a decade, and today its own site lists GitHub, Shopify, Airbnb, Zendesk and 1Password among the companies built on it.¹⁰ Starting a new, important system on the PHP and plugin model after that was a choice, usually made because it looked quick and familiar rather than because it was the strongest long term foundation.

That is not a claim that WordPress is worthless or that the people who build it are careless. For a simple brochure site that a business is happy to rebuild every few years, WordPress can be a sensible tool. My objection is narrower. When the part of your business that takes orders, holds customer records or runs your service stands on a stack that the whole internet shares, stitched together from plugins whose authors you will never meet, then "secure" depends on dozens of other people patching on time. A week like this one is not bad luck. It is the architecture doing what it does.

No stack is immune, including mine

Anyone who tells you their software cannot be breached is selling you the next incident report, so here is the other side.

Rails has had its own security advisories, and so has the JavaScript world I also build in. In December 2025 a flaw in React Server Components allowed remote code execution before any login, and it affected applications built with Next.js on the newer server rendering model.¹¹ In March 2025 another Next.js flaw let attackers skip authorisation checks that were placed in middleware.¹² Both were serious and both needed urgent patching.

The honest difference is not that one framework is magic. It is how much of the system is shared with everyone else, how many strangers' components sit in the request path, how quickly the owner can patch and redeploy, and whether anyone is watching. Those are design decisions, and you can make them well on any stack. My argument is that the plugin model makes them hard to make well.

Secure by architecture, not by luck

Security is mostly decided by how a thing is built, not by a product bolted on afterwards. Four principles do most of the work.

Keep the attack surface small. Every plugin, theme and add on is another door with a lock fitted by someone else. A custom application built for what your business actually does has far fewer doors, and the person who built it knows where each one is.

Give every part the least power it needs. Breaches get worse when one compromised component can reach everything. The PHP flaws hand the attacker the web worker account, so what that account can touch decides how bad the day gets. A worker that cannot write to its own code folder or read secrets it does not need is a much smaller prize.

Watch it while it runs. Every application I operate is wired to error monitoring, so an unusual crash or a strange request pattern is visible the same day instead of in a customer's complaint. CISA's advice for PHP2Shell included watching for web worker processes that start a shell, which is only possible if someone is looking.²

Own the code and the deployment. When the code is yours and the release process is automated, a security fix is a decision you can make and ship today. When the site is a tower of other people's plugins on a host you rent, you wait for other people's release schedules.

Rails helps with the basics by default. Its security guide describes forgery protection that new applications switch on automatically, and query methods that escape what users type before it reaches the database.¹³ That does not make a Rails application safe on its own, but it means the safe path is the normal path. On the sites I build, every release runs an automated test suite before it can go live, which I describe in the TDD and BDD guide.

A worked example: a Bristol shop on the morning of the alert

Take an invented business: Harbourside Ceramics in Bristol, harboursideceramics.example, selling handmade tableware through WordPress and WooCommerce on shared hosting. The site has 27 active plugins, including a payment gateway, a booking calendar for workshops and a page builder.

On the morning of 22 October the owner logs into the hosting panel and finds the site on PHP 8.1. That branch receives no fixes from the PHP project, so there is no patch to apply, and CISA's advice for 8.1 or earlier is to take the system offline until it is upgraded.²⁸ The host offers PHP 8.3, but the page builder has not been updated for two years and the owner does not know whether it will run.

The sensible sequence is the one in the alert. First, find out whether anything happened already: ask the host for the access logs since 21 October and for a scan of the files for anything added recently. Second, switch the shop to maintenance mode, move to the patched 8.3.36, and test checkout, payments and the booking calendar on a copy before reopening. Third, remove the abandoned page builder and any plugin nobody can name a reason for. If it takes two days, that is two days of lost orders, which is far less than the cost of a skimmed checkout.

The bigger question comes after the fire is out. For Harbourside the shop is the business. A shop that has to be pulled offline because a design plugin blocks a language upgrade is telling the owner something.

The legal bill if customer data was taken

There is a second bill after the technical one. If an attacker reached customer records, that is a personal data breach. Under Article 33 of the UK GDPR you must report it to the regulator within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to people.¹⁴ Since 30 September 2026 that regulator is the Information Commission, which replaced the Information Commissioner's Office (the ICO) under sections 118 and 119 of the Data (Use and Access) Act 2025.¹⁵ The higher tier of fines reaches £17.5 million or 4% of worldwide annual turnover, whichever is higher.¹⁶ A hacked shop is not only an IT problem.

What I build instead

None of this means every business needs custom software. It means the systems that make your money deserve a foundation you control. On Ruby on Rails I build three things.

• A custom online shop on Solidus and Rails, an open source ecommerce framework, where the code written for you becomes yours on full payment and is not a themed template shared with your competitors.
• A SaaS product with the data model, billing and permissions designed for the thousandth customer, not only the demo. Where a product needs a rich interactive front end, I use Next.js on top of a Rails back end.
• A smart website on a Rails stack rather than a tower of plugins, whose pages adapt to the campaign a visitor came from and to what the site may lawfully know about them.

Because these are built with a clean programming interface, the same back end can later feed a native app, as I explain in the article on API first Solidus. The longer argument about why I choose Rails over PHP frameworks for software meant to last is in why rapid development frameworks destroy PHP in the long run, and the comparison with Next.js is in the web frameworks article.

Custom does not have to mean slow. I use AI every day to build faster, and I answer for every line that reaches production. Speed is not the risk. Code that nobody understands and nobody owns is the risk.

Where this leaves you

Every few years the shared foundation cracks, everyone scrambles, the sites come back, and everyone agrees to worry about it next time. Patch first. That is the responsible thing and it has nothing to do with buying anything from me. Then ask whether the part of your business that actually takes the money should keep standing on a foundation the whole internet shares.

If this week made you nervous, that is a useful feeling. Let us turn it into a plan in a free workshop.

Footnotes

1. National Cyber Security Centre, Critical security issue affecting PHP, 21 October 2026, updated 23 October 2026, https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php

2. CISA, Critical vulnerabilities in PHP require immediate patching, 21 October 2026, https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching

3. CISA, Known Exploited Vulnerabilities Catalog, CVE-2026-109618 and CVE-2026-109619 added 26 October 2026, https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-109618

4. PHP Group, RCE via OOM corruption, security advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618), 21 October 2026, https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w

5. NIST National Vulnerability Database, CVE-2026-109618 and CVE-2026-109619, https://nvd.nist.gov/vuln/detail/CVE-2026-109618 and https://nvd.nist.gov/vuln/detail/CVE-2026-109619

6. W3Techs, Usage statistics and market share of WordPress, 11 November 2026, https://w3techs.com/technologies/details/cm-wordpress

7. W3Techs, Usage statistics of PHP for websites, 11 November 2026, https://w3techs.com/technologies/details/pl-php

8. PHP Group, Supported versions, https://www.php.net/supported-versions.php

9. Patchstack, State of WordPress Security in 2026, https://patchstack.com/whitepaper/state-of-wordpress-security-in-2026/

10. Ruby on Rails, official site (companies listed as using Rails), https://rubyonrails.org/

11. NIST National Vulnerability Database, CVE-2025-55182 (React Server Components), published 3 December 2025, https://nvd.nist.gov/vuln/detail/CVE-2025-55182

12. NIST National Vulnerability Database, CVE-2025-29927 (Next.js middleware authorisation bypass), published 21 March 2025, https://nvd.nist.gov/vuln/detail/CVE-2025-29927

13. Rails Guides, Securing Rails Applications, https://guides.rubyonrails.org/security.html

14. UK GDPR, Article 33, Notification of a personal data breach to the supervisory authority, https://www.legislation.gov.uk/eur/2016/679/article/33

15. Data (Use and Access) Act 2025, sections 118 and 119, https://www.legislation.gov.uk/ukpga/2025/18/section/118

16. Data Protection Act 2018, section 157, Maximum amount of penalty, https://www.legislation.gov.uk/ukpga/2018/12/section/157