The php2shell PHP vulnerability: what website owners should do now

On October 21, 2026, the PHP project released fixes for two critical flaws in PHP, the programming language that runs a large share of business websites and online shops. The flaws, nicknamed php2shell, can let an attacker run their own code on a web server without logging in. CISA, the U.S. government's cyber defense office, told organizations to patch immediately, and to take PHP systems offline if they can't.

This PHP vulnerability is not only a problem for large companies. If your business website runs on WordPress or another PHP system, it applies to you, even if someone else built the site and someone else hosts it. This guide covers what happened, how to tell if you're affected, and what to ask your web host today.

What is the php2shell PHP vulnerability?

It is two separate bugs in PHP itself, fixed in the same release. The PHP project's advisory describes them like this:

1. CVE-2026-109618: when PHP runs out of memory partway through handling a request, the cleanup step can treat half-built data as if it were valid.
2. CVE-2026-109619: data left behind by one request can be picked up by the next request that the same worker process handles.

Both can lead to remote code execution: an attacker sends a crafted web request, and your server runs code of their choosing. CERT-EU, the response team for the EU institutions, rates each one 9.2 out of 10 on the CVSS severity scale.

Three details make this worse than a typical website bug:

• No login needed. The attacker doesn't need an account on your site.
• It is in PHP, not in a plugin. The PHP project says every installation serving web requests is at risk, whichever way PHP is connected to the web server.
• It can fire before your site's own code runs. The PHP project rates the mod_php setup as highest risk, with a demonstrated exploit that works "before any application code runs". A site with every plugin up to date is still exposed if PHP underneath it is not.

Is my website affected?

Probably, if your site runs on PHP and nobody has updated PHP since October 21. PHP sits under WordPress and many other site builders, online shops, booking tools, forums and customer portals. The UK's National Cyber Security Centre (NCSC) calls PHP "a widely used server-side scripting language designed for web development" and notes it is used inside other products too.

That last part matters. CISA warns that PHP "is often a component of other software", so you may not see it. A network device's admin page, a phone system, a backup box or an old customer portal can run PHP without saying so.

Here are the fixed versions:

PHP branch	Fixed in	Support from the PHP project
8.5	8.5.12	Supported
8.4	8.4.27	Supported
8.3	8.3.36	Supported
8.2	8.2.35	Security fixes end December 31, 2026
8.1 and older	No regular release	Ended; vendor fixes or source patches only

To find your version, look in your hosting control panel, which usually shows a PHP version for each site. In WordPress, the Site Health screen lists it under Server. Or ask whoever hosts the site.

A version number is not the whole answer. The PHP project says Linux distributions received the patches in advance and ship their own updated packages, which can keep an older-looking number. So ask your host to confirm the fix is in place, not just the number.

What should I do today?

Go in this order. Each step comes from the CISA alert, the NCSC guidance or the PHP advisory.

1. Find every place PHP runs. Your main site, old landing pages, a shop on a subdomain, a client portal, test copies. NCSC says not to stop at outdated versions, since all versions may be affected.
2. Update, starting with what faces the internet. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your vendor's patched package. The PHP project is direct about it: "There are no complete mitigations, updating is the only safe choice."
3. If you can't update today, take it offline. CISA says organizations that cannot update right away, or that still run PHP 8.1 or older, should take PHP systems offline until they are patched or upgraded. A day behind a maintenance page costs some traffic. A taken-over server can cost far more.
4. Use stopgap settings only as a bridge. The PHP project published temporary settings (memory and upload limits, and switching off one session feature) but says they "do not make an installation safe". CISA adds that a web application firewall may give some protection in the meantime.
5. Check for signs of a break-in. If a site stayed online and unpatched, NCSC advises checking it for compromise and looking for backdoors. CISA suggests watching for PHP worker processes that launch shells or download tools.
6. Ask your other vendors. Devices and hosted services that bundle PHP need their own updates. NCSC says to keep watching for those.

What should I ask my web host or developer?

Most small businesses don't run their own servers. A hosting company, a web designer or a freelancer does. Send them a short email today:

• Which PHP version does each of our sites run, including old and test sites?
• Has the October 21, 2026 fix for CVE-2026-109618 and CVE-2026-109619 been applied, and on what date?
• Does any of our software run on PHP 8.1 or older? If so, what is the plan, and should it go offline until then?
• Have you checked our server for signs of compromise since October 21?
• When was our last clean backup, and where is it kept?

A good host answers within a day, in writing. A vague reply such as "we keep everything up to date" is a reason to ask again, or to bring in someone who can check.

Why are officials telling sites to go offline?

Advice to unplug a website is rare, and here it comes from several places at once. CISA says unpatched or out-of-support PHP systems should go offline until fixed. NCSC says to consider taking the system offline if the stopgap settings can't be applied quickly. CERT-EU suggests isolating internet-facing applications from public networks until a fix is applied and verified.

The reasons are the ones above: no login is needed, the attack can run before the site's own code, and the technical details are public. On release day, CERT-EU reported that initial proofs of concept have begun to circulate, which raises the chance that attacks are already under way. CISA said it had not observed exploitation as of its publication. Both can be true. The gap between a public fix and working attacks is often short, so the first days after a release count most.

What about PHP 8.1 and older?

The PHP project no longer ships fixes for PHP 8.1 and older. Because of how serious these bugs are, it did publish small source patches for PHP 7.4, 8.0 and 8.1, and some Linux distributions and long-term support vendors ship their own fixes. Those are patches, not a plan. PHP 8.2 reaches end of life on December 31, 2026, so a site on 8.2 needs an upgrade path soon too.

Old PHP versions usually linger because the software on top can't move: a custom portal written years ago, a plugin nobody maintains, a theme that breaks on a newer PHP. That is the real cost to plan for. Sometimes the answer is an upgrade, and sometimes it is a rebuild. Our guide to legacy system modernization covers how to decide.

Will there be more of these?

Probably. Earlier this year, the NCSC's chief technology officer warned of a coming "patch wave." The blog says AI, used by skilled people, is "showing the ability to exploit this technical debt at scale and at pace". The advice applies to organizations of every size: shrink what you expose to the internet, patch outward-facing systems first, turn on automatic updates where they exist, and replace software that no longer gets security fixes.

For a small business, the lesson is plain. Know what your website runs on, who updates it, and how fast. Choose a host that applies security fixes within days and tells you when it has.

How Raileon helps

On a free 20-minute call with the founder, we'll look at what your website and customer-facing tools run on, list what needs updating, and help you write the questions for your host. If an old system can't be updated, we can replace it with custom software built to current versions. For systems we build and run, monthly care (hosting, monitoring, fixes and updates) starts from $1,999 a month. Our free business checkup is a quick second step: it shows how your site does on a phone and whether your email domain can be faked.

FAQ

What is php2shell?

php2shell is the nickname for two critical PHP flaws, CVE-2026-109618 and CVE-2026-109619, fixed on October 21, 2026. Both can let an attacker run code on a web server without logging in.

Which PHP versions fix the vulnerability?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older get no regular fix from the PHP project, so those sites need a vendor fix or an upgrade.

Is my WordPress site affected?

WordPress runs on PHP, so it is exposed unless the server's PHP was updated or patched on or after October 21, 2026. Ask your host to confirm the fix in writing.

Should I take my website offline?

CISA says yes if you can't update right away or you still run PHP 8.1 or older. Keep it offline until it is patched or upgraded.

Sources

1. PHP project: Security advisory: Critical remote code execution vulnerabilities, update now, October 21, 2026.
2. PHP project: PHP 8.2.35 Released!, October 21, 2026.
3. CISA: Critical Vulnerabilities in PHP Require Immediate Patching, October 21, 2026.
4. NCSC (UK): Critical security issue affecting PHP, October 21, 2026.
5. CERT-EU: Security Advisory 2026-018, Critical Vulnerabilities in PHP, October 21, 2026.
6. NCSC (UK): Preparing for a vulnerability patch wave, 2026.

Send the email today

Copy the five questions above into an email to your host or developer now. If you'd rather go through the answers with someone, we'll do it with you on a call.

Book a free 20-minute call