Summary: On 21 October 2026 the PHP project patched two critical flaws, nicknamed PHP2Shell, that let an attacker run code on a web server without any password at all. They sit in PHP itself rather than in your website, so a perfectly built site is just as exposed as a neglected one, and your own login page cannot block them. Most hosting companies have already applied the update. But a line appearing in many of this week’s notices — that PHP 7.4 or newer needs no action — is not correct, and if you are on 7.x it matters a great deal.
If you have a website, you probably got an email this week from whoever hosts it. Most of those emails are accurate, most hosts have already done the work, and most business owners can close the message and carry on. But one sentence keeps appearing in them that is not correct, and if it applies to you it matters more than everything else in this article.
The short answer
- Two flaws in PHP itself were patched on 21 October 2026. Both are rated 9.2 out of 10.
- They allow code execution with no password. Your site’s own login cannot block them.
- Fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Nothing older than 8.2 gets a fix at all.
- Many notices this week say “PHP 7.4 or newer, no action needed”. That is wrong. 7.4 is affected and will never be patched.
- Attacks were seen before the patch was published, so this is not theoretical.
- Most managed hosts have already updated. Check rather than assume — and do not panic-buy an emergency audit.
What PHP2Shell actually is
PHP is the programming language that runs underneath most of the web. WordPress, Joomla, Drupal, Magento and a very large share of the custom-built business sites in Toronto all sit on top of it. You never see it and you never install it — it is part of the server, and your hosting company decides which version you get.
On 21 October 2026 the PHP project published fixes for two flaws, tracked as CVE-2026-109618 and CVE-2026-109619. PHP’s own advisories describe them as remote code execution via out-of-memory corruption and remote code execution via stale global state. Security vendors have since given the pair a nickname, PHP2Shell, which is what most of the coverage calls it. PHP itself does not use that name.
In plain terms: PHP can be interrupted part-way through handling a request — by running out of memory, for example — and left holding data it has only half finished setting up. Clean-up then treats that half-finished data as if it were valid, and in the second flaw, leftover state from one request can survive into the next one handled by the same worker process. An attacker who can trigger that reliably can get the server to run their code.
No login is required. This is the part that makes it serious rather than merely bad. An attacker does not need an account, a password, or any access to your site. One of the two flaws also leaks fragments of server memory back to them — which is where session tokens, API keys and private keys live — in the same way the Heartbleed bug did in 2014.
This is not a flaw in your website
Worth saying clearly, because it changes what you should do about it. A beautifully built, fully updated, well-maintained website is exactly as exposed as a neglected one. The problem is in the engine underneath, not in the thing you had built.
That also explains why the usual defences do not apply. PHP handles an incoming request before any of your website’s own code runs. Your login page, your admin password, your two-factor app and your security plugin all live above that layer, so an attack of this kind never reaches the point at which any of them could intervene. A firewall sitting in front of the site can block some known attack patterns, and several providers added rules within hours, but that is filtering traffic rather than fixing the hole.
The version numbers that decide everything
Everything about your exposure comes down to one number. This is the whole article in a table.
| If you are on… | What you need |
|---|---|
| PHP 8.5 | Update to 8.5.12 |
| PHP 8.4 | Update to 8.4.27 |
| PHP 8.3 | Update to 8.3.36 |
| PHP 8.2 | Update to 8.2.35 — and note 8.2 reaches end of life on 31 December 2026 |
| PHP 8.1 or older including all of 7.x and 5.x | There is no fix. The only answer is moving to a supported branch. |
The vulnerable code has been in PHP since version 5.4, released in 2012. So the affected range is not a recent regression — it is effectively every PHP site that has existed for the past decade. What changed on 21 October is that it became public, and that a patch exists for the branches still being maintained.
Why “7.4 or newer is fine” is wrong
This is the sentence to watch for. Several hosting notices circulating this week tell customers that no action is needed if their site runs PHP 7.4 or newer, and that older installations should be moved up to 7.4.
That advice was probably written from an older template, and it is incorrect in a way that matters:
- PHP 7.4 stopped receiving security support in November 2022. It has been unsupported for nearly four years.
- The flaw predates it. The vulnerable code dates to PHP 5.4, so 7.4 contains it.
- No patch exists for 7.4 and none is coming. The fixes were published for 8.2, 8.3, 8.4 and 8.5 only.
So a site on PHP 7.4 is not in the clear. It is affected, unpatched, and unpatchable on that version. The same is true of 8.0 and 8.1, both of which are also past end of life.
One honest exception. Some enterprise Linux distributions maintain their own PHP packages commercially and backport security fixes into older branches for paying customers. That is genuine, and if you are on that kind of platform your vendor’s advisory is the one that counts. It does not describe an ordinary PHP 7.4 on shared hosting, which is what most small business sites in Toronto and the GTA are running on.
How to check what you are running
You do not need a developer for this, and it takes about five minutes. Pick whichever applies to your setup — most small business sites in Toronto are on the first one.
In cPanel
Log in and open Select PHP Version, or MultiPHP Manager. Your domain is listed with its version beside it.
In WordPress
Tools → Site Health → Info → Server. The PHP version is near the top of that panel.
In Joomla
System → System Information. The PHP version appears on the first tab.
Or just ask
Email your host: “Which PHP version does my account run, and has the 21 October 2026 security release been applied?” Both answers matter.
Ask both halves of that question deliberately. “You are on PHP 8.3” does not tell you whether it is 8.3.36. The branch tells you whether a fix exists; the patch level tells you whether you have it.
What to do, in order
- Find your version. Five minutes, using one of the four routes above.
- If you are on 8.2 or newer — confirm the patch level with your host. On managed and cPanel hosting this has very probably been done for you already, automatically, with no downtime.
- If you are below 8.2 — this is now a project rather than a checkbox, and it should start this week rather than next quarter. Back up first, test on a staging copy, fix what breaks, then move the live site.
- If you were unpatched during the window — rotate hosting, database and admin credentials, and any API keys sitting in your configuration files.
- Look for the obvious signs of compromise before you consider it closed. More on that below.
If the upgrade is the part that worries you, that is reasonable — it is the step most likely to break something. It is also the one we do routinely as part of website maintenance, and the pattern is always the same: an abandoned plugin, an old theme, or one custom function written for PHP 5 that nobody has touched since.
If you cannot move off old PHP today
Sometimes the upgrade genuinely cannot happen this week — a critical plugin has no PHP 8 version, or the site is custom-built and nobody has looked at the code in years. In that case there are stopgaps, and it is worth being blunt about what they are.
PHP’s own advisory lists a few configuration changes that reduce exposure, and then says plainly that they do not make an installation safe. Security researchers have published more aggressive options: blocking file-upload requests at the web server, allowing only read-only page views, or taking the site offline behind a static maintenance page. The UK’s National Cyber Security Centre has suggested organisations consider taking offline anything that cannot be fixed promptly.
Every one of those options is bad. Blocking uploads breaks contact forms and checkouts. Read-only breaks logins and orders. Offline breaks everything. They exist because, for a short window, they are less damaging than the alternative — not because they are solutions. Treat them as a bridge to the upgrade, measured in days.
How to tell if you were already hit
Attack traffic was observed before the patch was published, which means the window was not zero for anyone, in Toronto or anywhere else. If you were on an unsupported version, it is worth looking rather than assuming.
The things worth checking are the ordinary ones, and none of them needs a specialist:
- Administrator accounts you do not recognise, especially recently created ones
- Files in the site root or upload folders with modification dates that make no sense
- Scheduled tasks or cron jobs nobody set up
- Your host reporting outbound spam, or your domain appearing on a blocklist
- Unexpected redirects, or pages that behave differently for search engines than for you
Patching does not undo a break-in that already happened. Updating PHP closes the door; it does not remove anything that walked through it beforehand. If you find signs of a compromise, the site needs cleaning as a separate job — we do that for WordPress and Joomla sites, usually within a day.
Why this one is not the usual advice
Most website security advice ends with “keep your plugins and themes updated”, and most of the time that is the right answer, because most of the time that is where the holes are. This is a different shape of problem, and three things follow from that.
You probably cannot fix it yourself. On shared or managed hosting you do not control the PHP binary. Your host does. That is why so many of these emails exist, and why for most people the correct response really is to read it, check, and move on.
Updating your site would not have helped. There was no plugin to update, no setting to harden, and nothing a careful owner could have done differently beforehand. The only variable that mattered was which PHP branch the server happened to run.
The useful question is who is watching. A Toronto business whose site is actually looked after knew about this on the day and has already confirmed its version. A business whose developer stopped answering two years ago does not know what version it is on, cannot log in to find out, and will discover the answer the hard way — which is a more common situation in Toronto than it should be.
If you are not sure which of those describes you, that uncertainty is the thing to fix. It is also, for what it is worth, the only part of this that is still true next month.
Common questions
My host emailed to say no action is needed. Is that true?
Usually yes, and for most Toronto businesses on managed or cPanel hosting the update has already been applied for you. But check the wording. Several notices sent this week say that anything on PHP 7.4 or newer is fine, and that is wrong. The fixes exist only for PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Nothing older than 8.2 receives a patch at all, so a site on 7.4 is not covered by that reassurance no matter how the email is phrased.
My site runs on PHP 7.4. Am I actually at risk?
Yes. PHP 7.4 left security support in November 2022, and the vulnerable code in this case goes back as far as PHP 5.4 from 2012, so 7.4 is affected and there is no patch coming for it. Some enterprise Linux vendors backport fixes into older branches they support commercially, which is real but does not cover an ordinary 7.4 on shared hosting. The fix is to move to a supported branch, which means 8.2 or newer.
Will my WordPress or Joomla security plugin stop this?
No, and this is the part that surprises people. The flaws are in the PHP engine, which processes the request before a single line of your website's code runs. Your login page, your firewall plugin and your two-factor setup all live above that layer, so an attack never reaches the point where they could intervene. A web application firewall in front of the site may block some specific attack patterns, but that is filtering, not fixing.
How do I check which PHP version my site is on?
In cPanel, open Select PHP Version or MultiPHP Manager and read the version against your domain. In WordPress, go to Tools, then Site Health, then Info, then Server. In Joomla, go to System, then System Information. If none of those is available to you, email your host and ask two things directly: which PHP version this account runs, and whether the 21 October 2026 security release has been applied to it.
Is upgrading PHP risky for my website?
There is some risk, which is exactly why so many sites are still on old versions. Code written for PHP 5 or early 7 can break on 8, usually through an abandoned plugin, an old theme or a custom function nobody has touched in years. The sensible order is to take a full backup, try the new version on a staging copy, fix what breaks, then switch the live site. What is not sensible is staying on an unsupported version indefinitely, because the gap only widens.
Should I change my passwords?
If your site sat on an unpatched version while this was being exploited, treat it as possible exposure and rotate what matters: hosting and database passwords, admin accounts, and any API keys stored in your configuration. One of the two flaws can return fragments of server memory to an attacker, which is where credentials and tokens live. If you were already on a supported branch and your host patched promptly, routine good practice is enough.
Not sure what your site is running?
Send us the domain and we will tell you which PHP version it is on and whether it is patched. We do this for businesses across Toronto, the GTA and Ontario — no charge, and no obligation to do anything about it with us. If the answer is that your host has already handled it, we will say so and you can get on with your week.
