PHP2Shell: what happened, how we responded, and why architecture matters

On 21 October 2026, the PHP project released emergency fixes for two critical flaws in the PHP engine itself: CVE-2026-109618 and CVE-2026-109619, now known as PHP2Shell. Both let an attacker run their own code on a web server with a single, unauthenticated request, and attacks were reported before the patches were even out.

PHP sits underneath a huge share of the web, including WordPress, WooCommerce, Magento and countless bespoke sites. In this post we explain what happened, who was exposed, how we responded for the clients we look after, and why the way a website is built can decide whether a bug like this is a fire drill or a footnote.

What happened, and why it was so serious

PHP2Shell is two separate memory-safety bugs in PHP's core runtime. Both score 9.2 out of 10 on CVSS v4.0, the industry's standard severity scale, and both can lead to remote code execution with the privileges of the web server.

CVE-2026-109618 (out-of-memory corruption). If PHP runs out of memory while it is still parsing an incoming request, it abandons the work half-finished. Its cleanup routine then treats that half-built data as valid, which corrupts memory. Crafted form or file-upload requests can trigger this even when they look like they are within PHP's size limits. Researchers also showed it can leak fragments of server memory back to the attacker.
CVE-2026-109619 (stale state between requests). Internal data belonging to one request can outlive the memory behind it. The next request handled by the same PHP worker can then pick up that stale data before it is reset, again opening the door to code execution.

The timeline was compressed. Researchers at Calif and Wiz reported the bugs to PHP privately in August. Details leaked on 20 October, security firm watchTowr confirmed working remote code execution, and Cloudflare reported early attacks at 07:43 UTC on 21 October. PHP published the fixed versions at 14:00 UTC that afternoon.

Three things made this unusually serious:

No login needed. The attacker does not need an account or a password.
It happens before your code runs. PHP processes the malicious request before WordPress, Magento or any application code is involved. A perfectly maintained site with no vulnerable plugins was still exposed, and application-level security such as login screens or plugin firewalls could not stop it.
The blast radius is enormous. The vulnerable code dates back to PHP 5.4, released in 2012. Palo Alto Networks counted more than 22.6 million internet-facing instances potentially affected.

Which websites and applications were at risk

In short: anything that runs PHP to answer web requests. Every version from 5.4 up to 8.5.11 is affected, across every common way of running PHP: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Setups using Apache mod_php were the most exposed.

In practice, that covers:

WordPress sites, including marketing sites, brochure sites and blogs, regardless of how well their themes and plugins are maintained.
WooCommerce, Magento and Shopware stores. Researchers confirmed unauthenticated code execution against Magento 2.4.9 and ten other PHP applications.
Other PHP CMS platforms such as Drupal, Joomla and Craft, and frameworks such as Laravel and Symfony.
Bespoke PHP applications, customer portals, booking systems and internal tools.
Legacy sites on old PHP versions. PHP 8.1 and earlier are end of life and received no official release. PHP published limited source backports for 7.4, 8.0 and 8.1, but anything older than that needs a full upgrade to 8.2 or later.

The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If a server is not on one of those, or a version later than them, assume it is vulnerable.

How iNet Digital responded

When the details leaked and attack activity against PHP sites was reported on the morning of 21 October, there was no patch yet. We moved quickly to put limited mitigations in place across the platforms we look after, including configuration changes that close off the known attack paths and web application firewall rules that block the exploit patterns circulating publicly.

In parallel, we had honest conversations with clients about whether some services should be taken offline until the patch landed. Neither option is comfortable: mitigations reduce risk without removing it, and taking a site offline costs enquiries, sales and trust. But waiting and hoping is not a strategy.

Once PHP released the fixed versions that afternoon, we began rolling them out across client servers and container images, prioritising the most exposed sites first. For clients on older, end-of-life PHP versions, we are planning upgrades rather than relying on stopgaps.

The experience also reinforced something we have been saying to clients for a while: the most effective security measure is often not a patch at all, but an architecture that keeps the riskiest code away from the public internet in the first place.

Why static sites with a headless CMS sidestep most of this risk

A statically generated site, built with a framework like Next.js and fed by an API-driven (headless) CMS, would not have been exposed to PHP2Shell on its public-facing pages. The reason is architectural, not luck.

Traditional PHP site vs static site with a headless CMS

The traditional model: every visitor talks to PHP

On a typical WordPress site, every page view is assembled on the fly. A visitor's request hits a server running PHP, PHP queries the database, runs the theme and plugins, and builds the HTML. That means the public internet is in direct conversation with PHP, the database, and every plugin installed, all day, every day.

PHP2Shell exploited exactly that conversation. An attacker only needed to send one crafted request to any PHP script on the site.

The static and headless model: visitors never touch the CMS

With static site generation, the pages are built ahead of time, when content is published, not when a visitor arrives. The result is plain HTML, CSS and JavaScript files that are served from a global content delivery network (CDN).

The CMS, whether that's Sanity, Contentful, Storyblok, Payload or similar, is decoupled from the website. Editors use it to manage content, and the build process pulls that content in through an API. Visitors never interact with the CMS at all.

The security benefits follow directly:

A drastically smaller attack surface. There is no application server, no PHP and no database answering public requests. A CDN serving static files has very little for an attacker to work with.
Engine-level bugs can't be reached from the front door. PHP2Shell worked because PHP processed the attacker's request. If no PHP runs when someone visits your site, that whole class of attack has nothing to hit.
No plugin sprawl. Plugins are one of the most common routes into WordPress sites. A static front end does not run third-party plugins on the server.
The CMS can be locked down. Because only editors and the build process need access, the CMS can sit behind single sign-on, IP restrictions or a managed SaaS provider whose security team patches it for you.
Faster recovery. If something does go wrong, a static site can be rebuilt and redeployed from source in minutes, and a compromised CMS does not automatically mean a compromised website.

There are business benefits too. Static pages load extremely quickly, which helps search rankings and conversion rates, and they cope with traffic spikes, such as a new housing development launch or a marketing campaign, without needing bigger servers.

No architecture is bulletproof

Static and headless sites remove a big part of the risk, not all of it, and it would be dishonest to claim otherwise.

Server-side features bring a server back. Next.js can also render pages on demand and run server code for forms, search or personalisation. That code is a live attack surface. In December 2025, a critical flaw nicknamed React2Shell (CVE-2025-55182) allowed unauthenticated remote code execution in React Server Components, affecting default Next.js App Router projects until they were patched. The lesson is the same as PHP2Shell: anything that runs code in response to public requests needs patching promptly.
"Headless WordPress" still runs PHP. Using WordPress purely as a back-end CMS is a big improvement, but that WordPress install still needs updating and should never be publicly reachable if it can be avoided.
Dependencies still matter. Build tools, npm packages and third-party scripts need to be kept up to date and monitored.
Forms and integrations need care. Lead forms, CRM connections and APIs should be handled by well-maintained, isolated services with rate limiting and validation.

The principle we follow is simple: keep as little code as possible running in public, keep what remains small and isolated, and keep everything patched.

What to do now

If your website runs on PHP, act today:

Check your PHP version. Your host or developer can confirm it in minutes. Anything below 8.5.12, 8.4.27, 8.3.36 or 8.2.35 needs updating.
Patch, or ask your host to. Most reputable hosts are rolling out fixed versions now. Ask for confirmation in writing.
Plan an upgrade if you're on PHP 8.1 or older. These versions are end of life and will not get routine security fixes in future.
Review what's exposed. Old staging sites, forgotten microsites and legacy campaign pages often run outdated PHP and are easy to overlook.
Think about the longer term. If your site is mostly content, such as developments, plots, news and enquiries, a static front end with a headless CMS can make the next PHP2Shell a non-event.

If you're not sure where your website stands, or you'd like to talk through what a move to a static, headless setup would involve, get in touch with iNet Digital. We're happy to review your current setup and give you a straight answer.