“PHP2Shell” is the name for two critical PHP bugs, CVE-2026-109618 and CVE-2026-109619, that let an attacker run code on a web server without logging in. The PHP project shipped the fix on 21 October 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If your server runs one of those versions or newer, you are covered. If it runs PHP 8.1 or older, the PHP project will not send you a fix at all.
That last sentence is the real story. The headlines say every PHP website in the world is in danger. Most are not. The sites in danger are the ones nobody has upgraded in years.
What PHP2Shell actually is
PHP2Shell is a bug in PHP itself, not in WordPress, Laravel or any plugin. That is why the news sounds so big. PHP runs a large share of the web, and a bug in the engine reaches every app built on it.
The first bug, CVE-2026-109618, happens when a request runs out of memory. PHP stops halfway through setting up its internal request data, and the cleanup step then treats that half-built data as valid. The second bug, CVE-2026-109619, leaves internal state alive after its memory has been freed, so the next request on the same worker can pick it up. In both cases a crafted request can turn that confusion into code execution.
The part that should worry an owner is the timing. The attack happens before your application code runs. Your login form, your security plugin and your input validation never get a chance. The PHP project’s advisory says the risk is highest on Apache with mod_php, and that PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are all affected.
As of 23 October, Canada’s Cyber Centre reports that a proof of concept is available and that no active exploitation has been confirmed yet. That window does not stay open for long once a proof of concept is out.
Who is actually at risk
The risk depends on your PHP version, and there are three very different positions.
On PHP 8.2 to 8.5. You are fine once you update to the patched release. On most servers that is one package update and a restart. This is routine maintenance.
On PHP 8.1, 8.0 or 7.4. The PHP project no longer ships updates for these. Some Linux distributions and paid long-term support vendors backport fixes, and the PHP team pointed to minimal source backports. Nobody is going to apply those for you. If you are on one of these versions and nobody owns the server, assume you are exposed.
On PHP 7.3 or older. The same as above, with even fewer people looking. These are the sites most likely to be quietly taken over in the coming months.
I have spent 15+ years on PHP systems, and a lot of that work was taking over code other people had stopped maintaining. The pattern is always the same. The app worked, so nobody touched the server. The upgrade got postponed because it felt like risk with no visible reward. Then a week like this one arrives, and the postponed upgrade turns into an emergency.
The upgrade you postponed is the bill
Teams avoid PHP upgrades because they think an upgrade means a rewrite. It does not. Moving an old app from 7.x to 8.x is mostly finding deprecated functions, fixing stricter type behaviour and running the tests, if there are any. The version bump is usually the cheapest part of modernizing a legacy PHP application without a full rewrite.
Now compare that with the cost of not doing it. A server that runs code for a stranger is not a bug you fix in an afternoon. It is an incident: investigation, a rebuild, questions about customer data and lost trust. When people ask me what it costs to modernize legacy PHP, I tell them to price the alternative too. This week the alternative has a CVE number.
The upgrade habit is what turns a scary week into a boring one. On a server that already runs a supported branch, PHP2Shell is a ten minute job: update, restart, confirm. The hard part was done months ago, when nobody was in a hurry.
How to check and fix it today
Start by finding out which PHP version actually serves your site. The version on the command line is not always the one your website uses.
php -vOn WordPress, go to Tools > Site Health > Info > Server. It shows the PHP version the site really runs on. On shared hosting, the control panel shows the version per site. On a server with several PHP builds installed side by side, check which build each site is configured to use, not just the default.
One trap: Linux distributions often backport security fixes without changing the version number. On a distribution package, check the package changelog or your vendor’s advisory, not only php -v.
Then fix it, in this order.
- Update to a patched release. That means 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your vendor’s patched package. Restart every PHP worker afterwards. A patched binary on disk does nothing while the old workers keep running.
- If you are on 8.1 or older, plan the move to 8.2 or newer now. Use a backported package from your distribution or vendor only as a stopgap.
- If you cannot update today, set
session.upload_progress.enabled=0inphp.inior the server configuration, then restart. The PHP project says this blocks only the confirmed path for CVE-2026-109619 and does not make the server safe. It also covers a third, rarer issue, CVE-2026-115560, which the PHP team will fix in the next regular release. Treat it as a bandage, not a fix.
If you see signs the server was already hit, like unknown PHP files, new admin users or strange outbound connections, patching is not enough. I have written about why a password reset does not lock attackers out of a hacked site, and the same logic applies here. The patch closes the door. It does not remove whoever already walked in.
The next deadline is already on the calendar
PHP 8.2 reaches end of life on 31 December 2026. If you patch to 8.2.35 this week and stop there, you will be back on an unsupported version in about nine weeks. Use this week to move to 8.4 or 8.5, not just to the nearest patch.
PHP is still a solid choice for business software in 2026, and it is why I still write PHP. But a language is only as safe as the version you run. PHP2Shell punishes the version, not the language.
For teams that kept upgrading, PHP2Shell was a ten minute fix. For everyone else, it is the week the postponed upgrade came due.
Frequently asked questions about PHP2Shell
What is PHP2Shell?
PHP2Shell is the nickname for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, disclosed on 21 October 2026. Both let an unauthenticated attacker run code on a server through PHP’s request handling, before any application code runs. They affect PHP itself, so every app built on PHP is exposed until PHP is updated.
Which PHP versions fix PHP2Shell?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix both vulnerabilities. Any older release in those branches is vulnerable. Linux distributions may ship the fix under their own package version, so check your vendor’s advisory as well.
Is my WordPress site affected by PHP2Shell?
Your WordPress site is affected if the server runs an unpatched PHP version. The bug is in PHP, not in WordPress, so updating WordPress or plugins does not fix it. Check the PHP version under Tools > Site Health > Info > Server, then update PHP or ask your host to.
Does PHP 7.4 or PHP 8.1 get a PHP2Shell patch?
No official patch is coming. The PHP project no longer ships updates for PHP 8.1 and older. Some Linux distributions and long-term support vendors backport fixes, but the real fix is moving to PHP 8.2 or newer, and ideally 8.4 or 8.5, because PHP 8.2 reaches end of life on 31 December 2026.
What can I do if I cannot update PHP right away?
Set session.upload_progress.enabled=0 in php.ini or the server configuration and restart every PHP worker. The PHP project says this blocks the confirmed attack path for CVE-2026-109619 only and does not make the server safe. Treat it as a stopgap until you update.