PHP end of life and unsupported ecommerce platforms

The short answer

PHP is the programming language behind a large share of the web, including most ecommerce platforms built in the 2000s and 2010s. Each version of PHP gets security fixes for a fixed period. After that, it reaches end of life and the PHP project stops fixing it.

On 21 October 2026, the PHP project released fixes for two critical security flaws. Official fixed releases were published only for PHP 8.2 and later. The PHP project said versions 8.1 and older no longer receive updates. So any website still running an older version of PHP has no official fix for these flaws.

Whether that affects your store depends on which PHP version your platform runs, and only your provider or developer can tell you that for certain. I can’t tell from the outside, and nobody honest can. What this guide gives you is the dated facts, the official advice, the questions to ask, and the options if the answers aren’t the ones you want.

What PHP is, and why it matters to a store

PHP runs on the web server. Every time a customer opens a product page, adds something to the basket or checks out, PHP code on the server builds the page and talks to the database. If the store’s platform is written in PHP, the version of PHP on the server is part of the store’s foundations, even though nobody sees it.

Three kinds of ecommerce store run on PHP:

• Self-hosted open-source platforms, where you or your developer choose the server and the PHP version.
• Proprietary platforms run by an agency or provider, where they host the store and control the server software.
• Custom-built stores, where whoever built and hosts the site controls it.

Hosted software-as-a-service platforms such as Shopify are different: the merchant doesn’t run a web server or choose a PHP version at all. The platform provider runs and patches everything, for every store.

PHP end of life, explained

The PHP project supports each version in two stages: a period of active support with bug and security fixes, then a period of security fixes only. After that, the version is end of life and receives no further official releases.

Each new version also brings changes that older code may not handle, which is why moving an old platform to a new PHP version isn’t always a simple switch. The older the platform, the more likely it is that parts of it, or its extensions, need rewriting first.

Two things follow from that table. First, PHP 8.2 itself reaches end of life on 31 December 2026, about ten weeks after the October fixes. Second, end of life isn’t a warning about the future: it’s a date after which, if a new flaw is found, no official fix will be released for that version.

Some Linux distributions and commercial vendors offer extended support for older PHP versions. Whether your server has that, and who pays for it, is another question for your provider.

What happened in October 2026

This is the public record, with the sources listed at the foot of the page.

1. 20 October 2026The PHP project posts an advance notice of two critical security flaws, with fixes to follow. Details leak ahead of the planned disclosure.
2. 21 October 2026PHP releases fixes for CVE-2026-109618 and CVE-2026-109619, nicknamed “PHP2Shell”. PHP rates each 9.2 out of 10 (CVSS v4.0). Both allow an attacker to run code on a web server without logging in.
3. Which versionsFixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP says 8.1 and older no longer receive updates. It published minimal source-code backports for 7.4, 8.0 and 8.1 for people who build PHP themselves; these are not official releases. Security researchers report no fix at all for PHP 5, and trace the affected code back to PHP 5.4.
4. 21 to 23 October 2026The UK’s National Cyber Security Centre, the US CISA and the FBI publish guidance. Security firms report early attack attempts; reports differ on whether successful attacks were confirmed.

One more detail matters for anyone running PHP themselves: the Canadian Centre for Cyber Security noted on 23 October that a further, separate PHP flaw was not fixed by the 21 October releases, with an interim configuration change advised until a fix ships. The picture was still moving at the time of writing.

What the official advice says

• UK National Cyber Security Centre, 21 October 2026: “Organisations using any version of PHP are affected.” Organisations on older versions should update to a fully supported version, and if mitigations can’t be applied, consider taking the system offline until it can be fully mitigated.
• FBI, 22 October 2026: if an immediate update isn’t feasible, “it is recommended that organizations take the system offline until it can be fully mitigated.” Its public service announcement of 23 October said security updates should be applied immediately.
• US CISA, 21 October 2026: an alert titled “Critical Vulnerabilities in PHP Require Immediate Patching”.
• The PHP project: only the official patches fix the flaws. Interim measures exist for servers that can’t be patched straight away, but PHP says they don’t fully protect against exploitation.

For an online retailer, “take the system offline” means stopping sales. That’s why the useful question isn’t whether to panic. It’s whether your platform is on a supported version of PHP, and if not, how quickly that can change.

If you have been advised to take your store offline and can’t afford weeks without sales, there is a middle route. Your catalogue can be put on a basic Shopify store as a stopgap, so you can keep trading on Shopify’s infrastructure, while the full migration with design, redirects, customers and order history is completed behind it. It isn’t the finished store, and it isn’t right for everyone, but it means the choice isn’t simply “stay exposed” or “stop selling”. Talk to your provider first: they may have a fix or a timetable that makes it unnecessary.

Finding out where your store stands

You usually can’t check your PHP version yourself on a hosted or proprietary platform, and you shouldn’t need to. Put three questions to your provider or developer, in writing:

1. Which version of PHP does my store run on today?A specific version number, not “a supported one”.
2. Has the 21 October 2026 PHP security release been applied?And if not, when will it be, and what’s protecting the store until then?
3. What’s the plan for 31 December 2026?When PHP 8.2 support ends, which version will the store move to, and when?

Clear, specific answers are good news, whatever they are. Vague answers, or no answer, tell you something too. Keep the replies: if you ever need to make a decision about your platform quickly, you’ll want them in writing.

What end of life means in practice

For a retailer, an end-of-life PHP version isn’t only a security question. It tends to show up in other ways first:

• Extensions and integrations stop updating. Payment, shipping, feed and marketing tools release new versions for current PHP, and eventually stop supporting old ones. A store on an old version slowly loses the ability to update the things it depends on.
• Hosting gets harder. Hosting companies move their servers to supported versions over time. Staying on an old version can mean paying for specialist hosting or extended support.
• Payment and compliance questions. Card payments are governed by the PCI DSS security standard, and payment providers expect systems that handle card data to be kept up to date. Ask your payment provider what their terms require of you.
• Insurance questions. If you hold cyber insurance, it’s worth asking your insurer whether running unsupported software affects your cover.
• Every change gets slower. Developers are understandably cautious about touching older systems, so small changes take longer and cost more.

None of these is a reason to panic. Together, they’re the reason the PHP version deserves a line on the agenda alongside sales and stock.

Common misunderstandings

Who patches what

On a self-hosted platform, you can at least decide to upgrade this afternoon, provided your platform version supports a newer PHP. On a provider-hosted platform, you depend on their timetable. On Shopify, there’s nothing for you to patch.

Questions about your contract

If you’re on a provider-hosted or proprietary platform, the contract shapes your options as much as the technology does. Before you decide anything, find out:

• When does the current term end, and how much notice is needed?
• Can you export your data? Products, customers and orders, in a usable format, during the notice period.
• Who owns the design and content? Some agreements license the theme rather than transfer it.
• Are there exit fees, or charges for data exports or domain transfers?
• Who controls the domain name? It should be registered to your business, not the provider.

None of these answers forces a decision. They tell you how much room you have, and when a move could happen without paying for two platforms at once.

A calm timeline

1. This weekSend your provider the three questions, in writing. Check who controls your domain.
2. Within a fortnightRead the answers. If they’re clear and dated, file them and diarise the next end-of-life date. If not, get an independent view of your options.
3. Before peak tradingDecide whether to stay, upgrade or move. A move can be built in the background during peak and launched in a quieter week.
4. By 31 December 2026Know which PHP version your store will run when PHP 8.2 support ends, or know your Shopify launch date.

If you run your own server

If your store is self-hosted and you have a developer or hosting company you can call, the steps are more within your control:

• Confirm the exact PHP version on every server the store uses, including staging and any separate admin or API servers.
• Check what your platform supports. A newer PHP version only helps if your ecommerce platform and its extensions run on it. Some older platform versions don’t, which turns a PHP update into a platform upgrade.
• Test before you switch. Upgrade a copy of the store first, place test orders and check every integration, then move the live store.
• Plan for the next date. If you land on PHP 8.2, its security support ends on 31 December 2026. Landing on 8.3 or later buys more time.
• Follow your developer’s and hosting company’s security guidance on interim measures, and the official advisories listed at the foot of this page.

If those steps reveal that the platform itself can’t move forward without a major rebuild, that’s the point at which comparing a rebuild with a move to a hosted platform makes sense.

What my free audit covers

My free store audit is not a security test, and I don’t probe anyone’s servers. It looks at what’s publicly visible about your store: which platform it appears to run on, how its pages and URLs are structured, how much of it Google has indexed, how fast it loads, and which integrations and tracking are in place. From that, I give you a plain-English summary, the questions worth putting to your provider, your realistic options, and a fixed price for a move to Shopify if you want one. If staying where you are is the right answer, I’ll say so.

Your options

What moving to Shopify involves

If you decide to move, the work is the same as any well-run migration: map every product, customer, order and URL; build the new store in the background while the old one keeps trading; redirect every old address so rankings carry over; and switch over on a date that suits you, including the end date of your current contract.

My Shopify migration package runs over four weeks from signed brief to a live store and starts from $19,997 USD, or £14,997 + VAT for UK clients, with flexible plans depending on the deposit paid. I’m UK-based and work remotely with retailers all over the world. Outside the UK, the package starts from $19,997 with no VAT, quoted in US dollars after the free store audit. I’ve engineered more than 350 Shopify stores and migrated over 500,000 products in 20 years. For the full service, see my Shopify migration service; for the price drivers, my Shopify migration cost guide; and for UK hosted platforms, my guide to moving a UK ecommerce platform to Shopify.

When you don’t need to move

• Your provider gives clear, dated answers, your store runs a supported PHP version, and there’s a plan for the next end-of-life date.
• You control your own server and your platform already supports PHP 8.3 or later.
• You’re already on a hosted platform like Shopify, where server software isn’t your concern.

In any of those cases, the sensible step is to keep the answers on file and revisit them at the next end-of-life date. Moving platform is a big decision, and it should be made for the right reasons, not in a rush.

PHP end of life and ecommerce: FAQ

Sources

PHP supported versions and end-of-life dates: PHP project, as published by isitpatched.com (synced 23 October 2026) and Brandefense (22 October 2026). PHP security releases and statements: BleepingComputer, 20 and 21 October 2026; watchTowr, “PHP CVE-2026-109618 FAQ”, updated 23 October 2026; SentinelOne, “Stopping PHP2Shell”, 21 October 2026; Sansec, “PHP2Shell”, 21 October 2026; Canadian Centre for Cyber Security alert AL26-026, 21 October 2026, updated 23 October 2026. Official guidance: UK National Cyber Security Centre, “Critical security issue affecting PHP”, 21 October 2026; FBI statement as reported by Newsweek, 22 October 2026; FBI IC3 public service announcement I-102326-PSA, 23 October 2026; CISA alert, 21 October 2026. Shopify PCI DSS Level 1: shopify.com/security/pci-compliant, accessed 24 October 2026. KA Consultancy prices and proof points as published on the Shopify migration services page.