On shared and managed hosting, your provider decides which PHP versions you can run and when they disappear. For an older PHP application, that means either a forced upgrade it may not survive or an unsupported version it can't leave. Here's what that means for your business.
Many business websites in India and the Middle East run on shared or managed hosting. It is affordable, someone else looks after the server, and for a brochure site or a small online shop it is often the right choice. But it comes with a trade-off most owners only discover in a crisis: you don't control the version of PHP your website depends on. Your hosting provider does.
That matters in two directions. Your host can remove the PHP version your application needs, on its own schedule, whether or not your website is ready. Or your host can let you stay on an outdated version indefinitely, and the security risk stays with you. An older PHP application that only works on an old version of PHP is caught by both.
With PHP 8.2 losing security support at the end of this year, many businesses are about to face this choice, whether they know it or not.
Who really controls the engine under your website
Think of PHP as the engine that runs your website's code. On shared hosting, many customers share one server, and the hosting company decides which engines are installed. The "PHP version" setting in your control panel simply lets you pick from the provider's list. Everything else belongs to them: which versions are available, when they are removed, when security updates are applied, and how the server is set up.
Each version of PHP is supported for a limited time. According to php.net, PHP 8.1 reached end of life on 31 December 2025, and PHP 8.2 receives security fixes only until 31 December 2026. After a version reaches end of life, the PHP project no longer fixes newly discovered flaws in it. WordPress.org already recommends PHP 8.3 or greater and warns that older versions "may expose your site to security vulnerabilities".
Hosting providers respond to these deadlines in different ways. Here is what three of them say in their own documentation, as of 23 October 2026:
- Hostinger says customers "can only select PHP versions 8.2 and higher up to PHP 8.5", that versions 8.1 and lower are unavailable, and that the chosen version applies to every website on the hosting plan. Sites already on an older version keep it, but can't move back once upgraded.
- WP Engine states that when a PHP version reaches end of life, it "will automatically upgrade all websites to a more current version", and that these upgrades "cannot be deferred".
- Pressable says its policy is not to support end-of-life PHP and to update all sites automatically. It removed PHP 7.4 in August 2024.
At the other end of the market, cPanel, a control panel used by many hosting providers, said in March 2026 that "millions of sites still run on older PHP versions" across the servers it can see. Its answer is a paid add-on that supplies security-patched builds of old PHP versions without upgrading the websites. Whether your site benefits from anything like this depends entirely on whether your provider has bought and installed it. You can't add it yourself.
What could go wrong for your business
For a website that keeps up with PHP, a host that upgrades automatically is helpful. The trouble is specific to older applications that break on newer versions, usually because of an old framework, an abandoned plugin or code written for how PHP used to behave. For those, every path carries risk:
- An upgrade on someone else's date. If the host upgrades and the application breaks, you may find out from your customers. Checkout, enquiry forms or the whole site could stop working, and the repair is done under pressure.
- Being stuck on an unsupported version. If the host lets you stay, the site keeps working on software that no longer receives security fixes. When the next serious flaw is found, there may be no fix for you. Sites on PHP 8.1 and older were in exactly that position when a flaw known as PHP2Shell was disclosed in October 2026.
- One site holding back the rest. Where the PHP setting applies to the whole plan, one old application can keep every other site on an outdated version, or one upgrade can break it.
- Moves become projects. Once an old version can no longer be selected, moving the site to a new plan, restoring it from a backup to a fresh account or creating a test copy can turn into an unplanned upgrade.
There is also a quieter cost. When something goes wrong, the people who can see the server logs, roll back a change or confirm a security update work for the hosting company, not for you.
Could your website be next?
The first risk here is not an attacker. It is a policy change. Hosting providers publish their plans, but notices go to whoever is listed as the technical contact, and that may be a developer or agency who left years ago. Many businesses learn about a forced upgrade only when their website stops working. Having had no problems so far doesn't mean the next change will go smoothly.
The second risk applies if your site stays on an unsupported version. Attackers commonly use automated tools to scan large numbers of websites for software with known flaws, and they don't need to know or care who owns a site. A small business website on outdated PHP can be found in the same sweep as a large one. Once a version stops receiving fixes, every newly published flaw in it stays open for as long as the site keeps running it.
None of this means every site on shared hosting is at risk, or that an attack is inevitable. It means that if your application can't keep pace with your provider's schedule, you are carrying a risk you may not have chosen.
Why legacy PHP applications deserve attention
Shared hosting assumes your application can follow the platform's upgrade schedule. Well-maintained PHP applications usually can. Ageing ones often can't, and the reasons tend to pile up over time: an old framework that no longer receives updates, plugins whose authors have moved on, code that relies on behaviour PHP has since changed, and little or no automated testing to show what an upgrade would break.
Each year of delay adds to that list. The longer an application stays on an old version, the larger the eventual jump and the more likely it is that the jump is forced at an inconvenient moment. That is why modernisation deserves to be treated as a planned business decision rather than an emergency response to a hosting notice.
What this means for your organisation
The questions worth asking are simple, even if the answers aren't:
- Which PHP version does each of your websites run on, and is it still supported?
- What is your hosting provider's policy on old versions, and who in your organisation receives its notices?
- Would your application survive an upgrade to a supported version today?
- If it is staying on an older version, is anyone supplying security fixes for it?
If you can't answer these confidently, your website deserves a closer look before your provider's timetable makes the decision for you. Knowing the real condition of your application is the starting point for choosing between an upgrade, a change of hosting or a broader modernisation.
Recommended next step
Don't wait for a hosting notice, or a broken checkout, to tell you where you stand. Take our free Legacy PHP assessment to find out which PHP versions your websites depend on, how exposed they are to your provider's upgrade schedule and what it would take to move them forward.
Then talk to our team about your options. For some applications, upgrading on PHP and staying with your current host is the right answer. For others, modernising on a stack such as Node.js, where the runtime version is part of the application's own setup and changes are tested before they go live, may better suit the application's needs and your business goals. Every platform has versions that reach end of life; the aim is to own that decision rather than inherit someone else's.
Free Legacy PHP Risk Assessment
Not sure what your hosting provider is running underneath your site, or what happens when it changes? We'll review your PHP version, hosting setup and dependencies, and tell you plainly where you're exposed and what your options are, whether that's an upgrade, a change of hosting or a migration.
