If your business has a website, there is a good chance it runs on PHP, which makes the PHP2Shell vulnerability something to check this week. On 21 October 2026, some Canadian government websites were taken offline as a precaution, according to news reports, after two serious flaws were found in PHP. This guide explains what they mean in plain English, which versions carry the fix, and the three questions to send your web host today. The video above covers the same ground in under two minutes.
Key takeaways
- PHP2Shell is two flaws in PHP, both rated 9.2 out of 10, that can let an attacker run code on a server without a password.
- The fix is a PHP update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, and PHP must be restarted afterwards.
- PHP 8.1 and older has no official fix download, so ask for a fixed build or plan an upgrade.
- Exposed does not mean hacked. Ask your host to confirm the fix against both CVE numbers.
What the PHP2Shell vulnerability is
PHP is the engine under the hood of many websites. WordPress runs on it, and you never see it as a visitor, but it builds your pages every time someone opens them.
Researchers found two flaws deep inside PHP and nicknamed them PHP2Shell. They are tracked as CVE-2026-109618 and CVE-2026-109619. A CVE is simply a public ID number for a security flaw, so that everyone talks about the same problem.
In plain terms, think of a lock that gives way when the building is overloaded. When a server’s memory fills up, the protections that normally keep each web request separate can break down. An attacker can then run their own code on the server, and no password is needed.
Those numbers explain why the response was so fast. A flaw this severe in software this common leaves very little time to wait and see.
What an attacker could reach, and when attacks began
If an attacker gets that far, they can read what the server holds. That can include passwords, login tokens and API keys (the secret codes that let one system talk to another). They could also take over the website itself. For a small business, that might mean the logins to your WordPress admin screen, the details behind a contact form, or the keys that connect your site to other services. How much is at risk depends on how your site is built and hosted, and the PHP project says exploitability varies by configuration.
The timing matters too. Amazon’s threat intelligence team reported a first exploitation attempt on 17 October 2026, four days before the fix was released on 21 October. Cloudflare has also reported attack traffic, and Qualys reports that public demonstration code has appeared online. That is why governments and large organisations moved quickly, and why taking a site offline was a reasonable precaution for some of them.
An unpatched site is exposed, which is not the same as compromised. The lock is weak until the update is applied, so the job is to get it applied and confirmed.
How to check your website for the fix
The PHP project released fixed versions on 21 October 2026. Find the branch your site runs (the first two numbers of the version), then check that you are on the fixed version or a later one.
| PHP branch | Fixed version | What to do |
|---|---|---|
| 8.5 | 8.5.12 | Update to 8.5.12 or later |
| 8.4 | 8.4.27 | Update to 8.4.27 or later |
| 8.3 | 8.3.36 | Update to 8.3.36 or later |
| 8.2 | 8.2.35 | Update to 8.2.35 or later |
| 7.4, 8.0, 8.1 | No official release | Ask for a fixed build, or upgrade |
An example (illustrative, not a client case): your host tells you the site runs PHP 8.3.30. That is the 8.3 branch, and the fixed version for 8.3 is 8.3.36, so the site is behind and needs the update.
There is a catch with version numbers. Some hosts and server software packages apply the fix themselves but keep an older version number on the label. So a number that looks old is not proof the site is exposed, and a number that looks right is not proof it is safe. That is why we suggest asking your provider to confirm the fix against the two CVE numbers, not just the version.
There is a second catch. PHP keeps running code in memory, so installing an update is not the end of the job. PHP has to be restarted before the fixed code is actually in use. Qualys, which published guidance on these flaws, also advises restarting every service that loads PHP.
Three questions to ask your web host or developer
You do not need to understand the technical details to get a clear answer. Send these three questions to whoever hosts or maintains your site, and keep the replies.
- Which PHP version do we run?Ask for the full number, such as 8.3.36, not just “8.3”, and ask about each website you have.
- Is it fixed for CVE-2026-109618 and CVE-2026-109619?Confirmation against the CVE numbers covers hosts that keep an older version label.
- Was PHP restarted after the update?Until it restarts, the old code can still be running in memory.
Ask for the answers in writing. If you have more than one website, ask about each one, because different sites can sit on different servers. If the answer to any question is “we are not sure”, ask them to check and come back to you.
If you run PHP 8.1 or older
PHP 7.4, 8.0 and 8.1 are end of life. The PHP project no longer supports them, so there is no official download with the fix. The project did publish code patches for these three branches, but those are meant for people who build PHP from source.
For everyone else, that leaves two options: ask your provider to supply a fixed build, or upgrade to a supported version. Upgrading older PHP can break old plugins or themes, so it is best planned and tested rather than rushed.
You would not be alone. Qualys measured about 156 million installations where the PHP version is known, and found that around 71 percent were on end-of-life branches. For the PHP2Shell vulnerability, that group is the hardest to protect, so it deserves a conversation with your provider soon.
A stopgap is not a fix
If your host cannot update straight away, they may offer a temporary step. Qualys describes switching off a PHP setting called session.upload_progress.enabled at the server level. It has to be changed in the main server configuration, because changes made inside a website’s own code or settings files are not enough. Treat it as a bridge to the real fix. The PHP project says updating is the only complete answer.
Keeping PHP patched from here
The lasting lesson is that website software ages quickly, and someone needs to own the updates. Keeping software patched is routine work for our managed clients, through our security patch management and remote monitoring and management services. It is the quiet work that does the most to reduce the risk of incidents like this one.
If you want to see how this fits into a wider plan, our cyber security assessment looks at the whole picture, and our managed IT services cover the day to day. If you are in Toronto or the Greater Toronto Area and you are not sure who looks after your website, read about IT support in Toronto or start with the free risk assessment below.
Frequently asked questions
Does PHP2Shell affect WordPress sites?
WordPress runs on PHP, so the PHP version on your server matters more than the WordPress version. Updating WordPress itself does not change the PHP underneath it, so the hosting side needs its own check.
Do we need to take our website offline?
Not necessarily. The government sites were taken offline as a precaution, but for most businesses the better path is to get the PHP update applied and PHP restarted quickly. If your host cannot confirm a fix and your site holds sensitive data, ask them about temporary protections.
Who is responsible for updating PHP on our site?
On shared hosting, the hosting company usually controls PHP. On a virtual or dedicated server, it is normally you or your web developer. If you are not sure who that is, start with whoever invoices you for hosting.
Does a web application firewall protect us?
Some providers, including Cloudflare, have added firewall rules for known attack paths. These help as an extra layer, but the PHP project says updating is the only complete fix.
Should we change our passwords and API keys?
Ask your host whether their logs show any attempts against your site, and follow their advice. Changing passwords and API keys after the update is a reasonable precaution if there is any doubt, because the flaws can expose secrets that the server holds.
Answer 10 quick questions in about 3 minutes, then get a free IT audit from our team.
Start the risk assessmentRelated service: Cyber Security Assessment
Last updated
