On 21 October 2026 the PHP project shipped emergency fixes for two vulnerabilities that together have been nicknamed PHP2Shell: CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 out of 10 under CVSS 4.0. Both allow an attacker to run code on a web server without having an account, a password or any access at all.
They affect PHP going back to 5.4, which is most of the PHP on the internet. Palo Alto's Cortex Xpanse put the number of exposed instances at over 22.6 million at the time of disclosure.
Correct as of 25 October 2026. This is a fast-moving situation and some of the detail below will have changed. Where it matters, we have said what is confirmed and what is not.
The short version
If someone else manages your hosting — Hostinger, SiteGround, Kinsta, Cloudways, most cPanel shared hosting — this has almost certainly already been fixed for you, automatically, and you do not need to do anything. If you run your own VPS or server, you need to update PHP today. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. No configuration change is a complete substitute for updating.
What actually went wrong
Both bugs are in how PHP handles a fatal condition partway through a request.
- CVE-2026-109618 — when PHP runs out of memory, it jumps out of whatever it was doing to clean up. That jump can happen while the internal data for the request is only half set up, and the cleanup then treats the half-finished data as if it were valid.
- CVE-2026-109619 — internal state belonging to one request can outlive the memory it was stored in. A later request handled by the same worker process can then read that stale pointer.
The consequence in both cases is that an attacker who can make a server hit one of those conditions on demand may be able to get it to execute their own code. We are not going to publish the mechanics, and you do not need them: the only question that matters to a site owner is whether your PHP has been updated.
Is anyone actually being attacked?
This is where it is worth being careful, because the reporting has been loose and the honest answer is more nuanced than either "the sky is falling" or "nothing is happening".
What is confirmed: exploitation attempts have been observed in the wild by several independent parties. watchTowr reported attempts against its honeypot network from 21 October. Amazon logged an attempt against its MadPot honeypots on 17 October — four days before public disclosure. Cloudflare saw attack traffic against its customers, with the payloads being changed to get past its rules.
What is not confirmed, at least publicly: a successful compromise of an ordinary production website. Amazon said it was unclear whether the attempts it saw would have succeeded against real systems, and as of 22 October the vulnerabilities had not been added to CISA's Known Exploited Vulnerabilities catalogue. Palo Alto's Unit 42 has published an incident involving a European government entity where an attacker reached password hashes and MFA secrets within two hours — which, if you run anything sensitive, is the scenario to plan around rather than dismiss.
Security researchers at Wiz demonstrated unauthenticated code execution against WordPress, Drupal and Joomla in controlled research. So the risk is real and it is not theoretical. It is also, for most small business sites, already mitigated by a host that patched within a day.
Which versions are fixed
| PHP branch | Fixed in |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
| 8.1, 8.0, 7.4 and older | Source-only patches. These branches are past end of life, so there is no ordinary release and the version number may not change at all. |
A third issue, CVE-2026-115560, was disclosed on 23 October. PHP describes it as affecting only applications configured in an unusual way and considers it an unlikely risk; the fix is going into the next ordinary release rather than another emergency one. It is worth knowing about so you are not alarmed when you see a third CVE number, but it is not in the same category as the first two.
What to do, depending on who hosts you
If you are on managed or shared hosting
Almost certainly nothing. The major hosts patched within 24 to 48 hours and many deployed firewall rules blocking known exploit traffic before the patch even landed. Hostinger, for example, says the fix reached every one of its hosting plans except VPS, with the rollout completed on 22 October — and that customers on those plans need do nothing.
If you want to confirm rather than assume, there is a trap waiting for you: on most shared hosting the patched build keeps the old version number, because hosts backport the fix rather than ship a whole new release. We have written up how to actually check whether your PHP is patched, including the second trap that caught us out on our own server.
If you run your own VPS or dedicated server
This is on you, and it should be today's job. Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your distribution's patched package, and then restart your PHP workers — PHP-FPM, Apache, or your LiteSpeed processes. A running service keeps the old code in memory, so an update you do not restart has not taken effect.
If you genuinely cannot update within the next few hours, the stopgap circulating is to set session.upload_progress.enabled = Off in php.ini or your PHP-FPM pool config and restart the workers. Two caveats, both important: PHP has said no configuration change fully mitigates these vulnerabilities, so treat this as buying hours rather than solving the problem; and setting it through ini_set() in your application does not work, because the setting is read before your code runs.
If nobody is managing your site
This is the real risk, and it is far more common than either of the above. A site built three or four years ago by a freelancer who has moved on, on a hosting account whose login nobody can find, running a PHP version that stopped getting security updates in 2022. Nobody patched that site this week, because nobody is responsible for it.
If that describes a site you own, PHP2Shell is a symptom rather than the disease. The fix is to get it onto hosting that someone maintains.
Does where you are make a difference?
Not to the vulnerability — it is the same code everywhere. It does change what the practical risk looks like:
- If you handle US health data, an unauthenticated code execution flaw on a server that touches PHI is a different conversation from an ordinary outage, and it is one to have with your compliance people rather than only with your developer. We have covered that separately for medical billing and healthcare sites, which is the sector most of our US work sits in.
- If you are in Pakistan or the Gulf, the managed hosts patched quickly, so the exposure is concentrated in the older, cheaper, unmanaged corner of the market — which is a large share of small business sites in both regions. We have written that up for businesses on shared hosting in Pakistan and the UAE.
The question worth asking afterwards
Patching this one is the easy part, and for most readers it has already happened without them lifting a finger. The useful question is the one this week should have raised: when the next critical PHP flaw lands, who updates your site, and how would you know they had?
If the honest answer is "nobody" or "I assume the host does it", that is worth fixing while the lesson is fresh. It is the thing our website care plans exist to cover, and if your hosting is the weak link, moving to a host that patches properly is usually a cheaper fix than it sounds.
Not sure where you stand? Send us the domain and we will tell you what PHP version it is actually running and whether it is patched. That takes us a couple of minutes and we do not charge for it.
Have a project in mind?
Tell us about it and we'll get back to you within one business day.