If your website runs on WordPress, WooCommerce, Magento, Laravel or a custom system, there is a good chance it runs on PHP. Most owners never see that detail. This week, it became relevant to everyone who does.
On 21 October 2026, the PHP project released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, nicknamed PHP2Shell. Many hosting companies have since emailed customers. This article explains what happened in plain language, what "end of life" means for PHP, and the questions worth asking.
I will keep this practical. There is no need to panic, but there is a need to check.
What happened this week
According to Help Net Security, both flaws can allow remote code execution on a web server without any login. In simple terms, an attacker could make your server run their commands. The reported causes involve how PHP handles an out-of-memory condition and how internal request state is reused between requests.
A few points from the reporting that matter to a business owner:
- The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
- A working exploit is reported to exist, and Amazon Threat Intelligence reported an exploitation attempt on 17 October, four days before public disclosure.
- The UK National Cyber Security Centre says organisations using any version of PHP are affected, and advises taking a system offline if it cannot be fixed or mitigated quickly.
This is not specific to WordPress or any one application. The weakness sits in PHP itself, underneath whatever software you run on top.
Why "end of life" matters
PHP releases follow a published schedule. Per the official supported versions page, each branch gets two years of active support, then two more years of fixes for critical security issues only. After that it reaches end of life and receives nothing.
As of today, the PHP project lists these branches:
| Branch | Active support until | Security support until |
|---|---|---|
| 8.2 | 31 Dec 2024 | 31 Dec 2026 |
| 8.3 | 31 Dec 2025 | 31 Dec 2027 |
| 8.4 | 31 Dec 2026 | 31 Dec 2028 |
| 8.5 | 31 Dec 2027 | 31 Dec 2029 |
Two things stand out. First, PHP 8.2 stops receiving security fixes in about two months. Second, PHP 8.1 and older are no longer listed at all, which means the project does not support them. GoDaddy's guidance says versions 8.1 and older no longer receive official fixes and recommends upgrading to 8.2 or later. Help Net Security notes that source-level backports were published for PHP 7.4, 8.0 and 8.1 for people without a vendor providing long-term support, but that is a stopgap, not a plan.
The business translation: running an end-of-life PHP version means the next serious vulnerability has no official fix waiting for you.
The real risks of staying on old PHP
For a small or mid-sized business, the consequences are rarely dramatic movie-style hacking. They are usually quieter and more expensive:
- Your site is used to send spam or host malicious pages, and your domain reputation suffers.
- Customer enquiries, orders or personal data are exposed.
- Search engines or browsers flag the site, and traffic drops.
- A forced emergency upgrade breaks old plugins or custom code, at the worst possible moment.
Upgrading PHP is cheap when it is done on a schedule and expensive when it is done in a crisis, because old code often relies on features that newer versions removed.
Questions to ask your host
You do not need to understand the internals. Send these questions to your hosting provider:
- Which PHP version is each of my sites running right now?
- Has the 21 October security release been applied to my account, and which exact version number am I on?
- Do I need to take any action, or is the patch applied automatically? (GoDaddy, for example, says customers on some plans need to do nothing, while VPS customers must update PHP themselves.)
- Were PHP processes restarted after the update? A patched package that is not running does not help.
- How long will this PHP version be supported by you, and will you notify me before it reaches end of life?
If you manage your own server or VPS, the responsibility is yours or your developer's. Hosting that is "unmanaged" really means unmanaged.
Questions to ask your developer
- Is the site tested against PHP 8.3 or 8.4? If not, what blocks it?
- Which plugins, themes or libraries are abandoned or incompatible with current PHP?
- Is there a staging copy where upgrades can be tested before touching the live site?
- Are backups tested, not just scheduled? Can you restore one this week?
- Who is responsible for applying PHP and software updates after launch, and how fast?
A short, honest answer to these tells you more than a long technical one.
A sensible plan, without drama
- This week: confirm with your host that the October fixes are applied. Ask for the version number in writing.
- This quarter: make a list of every site and application you own and the PHP version behind each, including old microsites and forgotten subdomains.
- Before year-end: move anything on PHP 8.1 or older, and plan anything on 8.2, to a supported version, preferably 8.4 or 8.5, which have the longest runway.
- Ongoing: agree who owns updates, and review the support calendar once or twice a year.
If you cannot answer "what version are we on?" in under a minute, that is the first thing to fix.
Where I can help
If you would like an outside view, the free Digital Business Audit looks at your current setup and flags risks like this in plain language. If an ageing website is the underlying problem, my website work starts with what the business actually needs, not with a sales pitch.
