Why your WordPress update button cannot fix PHP2Shell (and why it isn't just a WordPress problem)

On Wednesday afternoon, 21 October 2026, the PHP project released emergency fixes for two critical security flaws. Security researchers call them PHP2Shell (CVE-2026-109618 and CVE-2026-109619). They let an attacker without an account send a crafted request to a website and run their own code on the server. The PHP team rates both flaws at 9.2 out of 10 for severity, and the US National Vulnerability Database scores them at 9.8.

PHP is the programming language behind most of the web. It is best known as the engine behind WordPress, Drupal, Joomla and Magento, and it also runs custom web frameworks such as Laravel and Symfony. If your business website or customer portal was built in the last fifteen years, there is a good chance PHP runs underneath it.

The UK’s National Cyber Security Centre advised organisations to update immediately, or consider taking affected systems offline. We practised what we preach and took our own self-hosted PHP invoicing system offline on Wednesday, where it stays until it is patched.

If you run a business website, that leaves two practical questions. Am I affected right now? And is there a way to build a website so you are not caught up in the next emergency server scramble?

Why a dashboard update will not fix PHP2Shell

Most WordPress site owners have one main security habit. They log in, spot the red badge next to Updates, click the button and get on with the day. Businesses running Drupal, Joomla, Craft CMS or Magento rely on similar updates inside the application.

This time, updating your CMS or framework does nothing. PHP2Shell is a flaw in the PHP runtime itself, the server engine underneath your website, and not in WordPress core, a Magento module or a Laravel package. As WordPress.org noted in its own announcement, no CMS update is needed, because no CMS update can fix it. The patch has to go on the server, installed by whoever manages your server or container images.

If your website, online shop or web app runs on WordPress or any other PHP software, run through this checklist today.

1. Check your PHP version. In WordPress, go to Tools, then Site Health, then the Info tab, and open the Server section. For Magento, Drupal, Craft CMS or custom Laravel and Symfony apps, check your hosting control panel (such as cPanel, Plesk or Forge) or ask your developer.
2. Compare it with the patched releases. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If your version number is lower than the one for your branch, your server is exposed.
3. Check with your host or agency. Send your hosting provider or web developer a short message. “Have you patched the server my site runs on against PHP2Shell (CVE-2026-109618 and CVE-2026-109619), and which version of PHP does it run now?” A good provider gives you a straight answer.
4. Watch out for old PHP branches. If your site runs on PHP 8.1 or older, the PHP project no longer supports it. PHP released source-code patches for some older branches, but your host has to compile and install them by hand, and many budget hosts will not. Upgrading to PHP 8.3 or newer is the reliable fix, because support for 8.2 ends on 31 December 2026.
5. Isolate unpatched servers. If you manage your own VPS or Docker containers and cannot patch or rebuild them straight away, follow the NCSC guidance and take them offline or restrict public access until you can.

More than a third of WordPress sites run a version of PHP that no longer gets regular security updates, according to WordPress.org’s statistics and PHP’s support schedule. If your site is in that group, PHP2Shell is a strong reason to move.

How a vulnerability goes from discovery to attack

When legitimate security researchers find a major flaw, they follow a process called coordinated disclosure. They report the bug privately to the software maintainers, who write and test a fix in secret. Google’s Project Zero, for instance, gives vendors 90 days. Once the update is ready, the patch and the public advisory go out together, so server administrators have a head start.

The risky part is the gap between the public announcement and the moment your server gets patched. Automated bots and attackers read security advisories with far more urgency than a small business owner who has customers to serve and a VAT return due. In 2025, nearly 30% of known exploited vulnerabilities were attacked on or before the day they were made public. The days when you had a quiet month to get round to server updates are gone.

An ideal security release is boring. The fix goes live, the details are published, and hosts patch their servers that same afternoon. PHP2Shell did not go to plan.

What went wrong with PHP2Shell’s timeline

The vulnerabilities were first reported to PHP in August by researchers at Calif working with OpenAI, and later by a team at Wiz. PHP scheduled the coordinated release for Thursday 22 October, and for more than two months the embargo held.

Then the details began to leak. On Tuesday afternoon, 20 October, the CVE numbers and severity scores started circulating on forums and social media. That evening, the PHP team pulled the release forward by 24 hours. Around the same time, one of the research teams published a demonstration video by mistake, which the PHP Foundation says gave attackers a head start on building working exploits. Early on Wednesday morning, a third-party software distributor published patched PHP code hours before the official release, and anyone comparing the old and new code could spot the weaknesses.

By the time the official patches arrived at around 3pm UK time on Wednesday, rough proof-of-concept exploits had been circulating for twelve hours.

Amazon’s security team adds an awkward detail. Its decoy servers recorded an attempt to exploit PHP2Shell on 17 October, three days before any of the public leaks. Someone may have found it independently and kept quiet.

Are attackers breaking into websites with it? As of 22 October, Amazon, Cloudflare and watchTowr have logged attack and scanning attempts, while the US cyber agency CISA and the security firm Huntress have not confirmed any breaches. Waiting to see if your site gets hit is still a bad strategy. Once a reliable exploit script is public, automated scanning follows within hours.

Why it isn’t just WordPress

It is easy to point the finger at WordPress because it runs around 40% of all websites, but PHP itself powers roughly 69% of all websites where the server language is known.

Researchers at Wiz showed PHP2Shell working out of the box against WordPress, Drupal and Joomla. Because the flaw sits in PHP itself, online shops on Magento or OpenCart, content sites on Craft CMS and custom applications built on Laravel, Symfony or CodeIgniter need the same server patch if they run an affected version.

That shared foundation is why attackers focus so heavily on PHP. One working exploit gives automated bots a way into a huge share of the web, off-the-shelf WordPress blogs and expensive custom-built Laravel portals alike. Those bots do not care whether a server belongs to a high-street bank or a plumber in Witham, and they scan every address they can find. For every one of those sites, staying safe depends on someone patching the server in time.

Is a custom website more secure than WordPress?

Not automatically. On 21 October, a custom Laravel portal had the same exposure as a WordPress blog, because both run PHP on a live server. What protects a site is how it is built, and the biggest choice is whether a live server assembles each page when a visitor asks for it.

Why a modern web stack avoids the problem

The most effective way to protect your business website from PHP server flaws is to keep a live PHP server off your public website in the first place.

Every time a visitor clicks a link on a traditional PHP site, whether that is WordPress, Drupal or a server-rendered Laravel app, the server has to start PHP, run its code, query a live database, assemble the page and send it back. That gives attackers a live server engine and database to target on every visit.

For marketing websites, brochure sites and content hubs, that architecture is unnecessary weight. We build business websites on a modern stack instead. Your pages are built ahead of time into finished files and served from data centres close to your visitors. When a customer visits your site, the server hands over a page that already exists.

On 21 October, while PHP hosts were scrambling to patch their servers, websites built this way had nothing to fix.

Taking the PHP server away changes both the security and the speed of your site. With no PHP engine running and no public login page such as /wp-admin for bots to hammer, far fewer server attacks have anything to hit. Most CMS breaches come from third-party plugins and modules rather than the core software (we broke down the numbers in Should you use WordPress for your website?), and a site built this way does not depend on dozens of plugins running on a live server. Pre-built pages served from a data centre near your visitor also load faster than pages built from a database on every click, which your customers and Google both notice.

Leaving traditional PHP platforms does not mean losing the ability to edit your own website. You still get a straightforward dashboard to update text, add photos, publish blog posts or change your opening hours. We pair your site with a headless content system such as Sanity, which runs this blog, or a sandboxed CMS such as Cloudflare’s EmDash. Either way, the editing tools stay separate from the public site, so a bad add-on is far less likely to reach the pages your customers see.

Built securely, monitored continuously

A modern stack removes the biggest target on your back, but the technology is only half the job. A secure website also needs disciplined engineering while it is built and monitoring once it is live.

Unless a project needs WordPress or a traditional server framework, in which case we explain why upfront and include the ongoing patching costs, we build on this modern stack. Every change passes automated security gates before it reaches the public web. Every code library in the build is checked against published security advisories on every update, and locked to exact versions so untested code cannot slip in quietly. The full codebase is scanned for API keys and passwords committed by mistake. Automated quality checks, type checks and hardened build pipelines, using verified, time-tested scanner releases, stop broken or tampered code before it deploys.

Once your site goes live, our website care plan keeps watch over it with uptime monitoring and security updates, applied through the same tested pipeline, so your website stays fast and off your worry list.

Six security questions to ask your web developer

Whether you are commissioning a new site or reviewing your current agency, ask these six questions before you sign. A competent developer answers each one clearly.

1. What software runs on the server when a visitor loads a page, and who is responsible for patching it?
2. When a critical flaw like PHP2Shell is announced, how quickly will you patch my server?
3. How many third-party plugins or packages will my site rely on, and how are they isolated if one has a flaw?
4. What automated security checks run before a code change goes live?
5. How do you monitor the site after launch, and when did you last test restoring a backup?
6. If we part ways in the future, which files and assets do I get to take with me?

If the answers are vague, the security behind the scenes usually is too.

If you are planning a new website, or want to move off WordPress or an older PHP platform, tell us what your site needs to do and we will put together a clear quote.