PHP week… Php2shell: What It Is and What to Do This Week

If your website runs on WordPress, Drupal, Joomla or almost anything else built on PHP – and isn’t being supported by a hosting provider who does your patching, then this is a critical week to make sure you’re not exposed to new security issues.

Two critical flaws in PHP itself, now nicknamed php2shell, let an attacker take over a web server without logging in. The patches for this came out yesterday, so it’s vital you make sure you’ve updated.

The UK's National Cyber Security Centre has issued an alert asking organisations to act immediately. Let’s catch up on what happened, how to check if you’re affected, and why this is yet more evidence it’s time to let WordPress retire and go play golf or try to restore old motorcycles or something nice…

By the way - if your site is on Wix, Squarespace, Shopify, Webflow or Framer, or is a static site, the flaw isn't in your stack. Long live the static site…

What Happened

Researchers at Wiz, Calif and OpenAI found and reported two bugs in the PHP interpreter, CVE-2026-109618 and CVE-2026-109619. The PHP security team rates both critical, 9.2 out of 10, and both allow unauthenticated remote code execution. In plain terms: someone accessing your website or server from the internet can run their own commands on your server with no permissions or access required.

The findings were kept quiet to give everyone time to adapt and prepare – but then leaked on the 20th of October, so PHP brought the release forward; this is why it all feels a bit rushed and sudden. We’ve already got our own proof of concept on ongoing assessments, and Amazon and watchTowr have reported that people are using it in the wild already.

The technical cause (if you’re curious) is memory handling. One bug lets an out-of-memory condition leave half-built request data behind, which PHP later trusts. The other lets data from a finished request linger and get reused by the next one. The fix therefore needs to apply to PHP itself rather than specific plugins or themes.

Am I Affected?

If your site runs on PHP, assume yes until you can prove otherwise.

The issue covers WordPress, Drupal, Joomla, Magento, WooCommerce shops, Laravel apps and most "page builder" sites generally. Everyone is affected, even if you work on your site every day and consider it well maintained.

What to Do Now

Find out who runs the PHP part of your website for you. Your hosting company, your web agency or your IT provider. If you're not sure, the person who sends the hosting invoice is a good start. Many hosting providers will already have a page up explaining what they’ve done to mitigate this issue – but you do need a clear answer.
Ask them one direct question: "Have you upgraded PHP to a fixed release for CVE-2026-109618 and CVE-2026-109619, and restarted the PHP workers?" Managed hosts may well have done this overnight.
If you run your own server, patch now. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or your distribution's patched package), then restart every PHP worker.
If you can't patch today, apply the stopgap. Set session.upload_progress.enabled=0 in php.ini and restart every worker; on PHP 8.5 also set fatal_error_backtraces=0. This only covers one of the two bugs, so it buys time rather than fixing anything.
If neither is possible, take the site offline. That's the NCSC's own advice for internet-facing PHP that can't be updated, and although it sucks to take the site down, that’s better than a breach or incident.
Check for signs you were hit before you patched. Look for admin accounts nobody recognises, unexpected new files, or a site that's started redirecting visitors elsewhere. Exploitation began on 21 October, so there’s a real chance something already happened.
Consider upgrading to a static site: read more on this below, but these situations are almost entirely avoidable now.

The Bigger Question: Does Your Website Need PHP at All?

Most of the sites the Turtledove team sees that are going to be affected by this are almost entirely brochure sites: homepage, services, team page, a contact form and some blogs, with updates maybe once a week or less.

Yet every one of them is effectively running and maintaining a website that’s a live application on a server, with a database, a login page, and plugins from a dozen authors. That’s before we get into the world of dodgy custom plugins and unverified code. That’s a lot of moving parts to keep a few pages online, and php2shell has shown how quickly that turns your website into a liability.

And the surfacing of issues akin to PHP’s problems this week isn’t slowing down. It’s worth noting who found these bugs: one of the three teams was OpenAI, and the flaws had been sitting in PHP since version 5.4, back in 2012. That’s over a decade of very smart people reading the same code and not noticing these game-over level issues.

AI tools are now turning up issues like this far faster than before, and attackers have the same tools the very next day. This week went from leak to working exploits in about a day – which for anyone with day-to-day business obligations becomes quite difficult to stay on top of.

So in the AI-driven security age, the best defence now is having less to defend. Fewer moving parts, fewer dependencies, and less code running on the internet on your behalf. So, the question to ask of every plugin, framework and server isn’t “is it up to date?” but “do we need it running at all?” For most brochure websites, the honest answer is no.

There is a better way. It’s what we use for our own site, and it’s a way of building websites known as ‘static sites’.

A static site takes a different approach to web presence. The pages are built once into plain HTML files and served as they are, with nothing running behind them to attack:

No server-side code: there’s no PHP, database or admin login exposed to the internet, so this whole class of flaw doesn’t apply.
Less to maintain: no plugin updates, no theme conflicts and no “your site needs a PHP upgrade” email from your host before your first coffee on a random October morning.
Faster and cheaper to host: static files load quickly and can sit on a content delivery network for very little. We host the Turtledove Cyber website entirely for free.

Contact forms, booking widgets and newsletter sign-ups all work through trusted third-party services, and content can still be edited without touching code. It just massively reduces your security perimeter, and means you can stay high and dry on weeks like this.

We’ll do it for you: end to end, the Turtledove way.

We've explored launching a simple service to move small business and charity websites off WordPress-style builders and onto static sites before. We’ve done it many times for our wonderful clients but never thought to offer it as a service on the website. This week we’ve decided to change that, as we think the AI age is going to change expectations and minimum requirements around web security.

Take a look at the service page here – or if you know the work needs doing, please do just get in touch.

We rebuild your existing site, so it looks and reads the same, keep your forms and integrations working, and hand it back with nothing left to patch. These types of sites really are the future, they’re much lower maintenance and they’re also a lot faster to load and interact with which is good for customer experience.

So, if this week has you wondering why a five-page website needs a database and a login screen, it doesn't! We're happy to chew it over with you and iron out any bits and pieces you still need answering on this – just get in touch.