What Happens If You Don't Update PHP? (October 2026)

If you don't update PHP, nothing visible happens at first: the site keeps working, but every security hole found in your version stays open, and the list grows each year. Old PHP doesn't wear out. The risk is the public list of known flaws that apply to it.

Once a fix is released, the flaw is public too. And nobody has to pick your site on purpose: bots scan the whole internet around the clock for old, unpatched software. A bakery's website gets the same knock on the door as a bank's.

It moves fast. Amazon logged a PHP2Shell attack attempt on its decoy servers on 17 October, four days before the fix, per Tenable's PHP2Shell FAQ. New to all this? My explainer on what PHP is covers the basics.

The most likely outcome of ignoring PHP is nothing for months, followed by either a break-in or a forced change by your host; data leaks and fines are rarer but cost the most. The likelihoods below are my judgement from fixing small business sites, not a statistic.

The expensive rows mostly start with one break-in.

An old PHP version that's out of support isn't safe on a public website, because new flaws in it never get fixed; an older release of a supported version is safe once your host installs the latest patch. Those are different situations, and the version number tells you which one you're in.

Will your site get hacked because of it? Not certainly, and rarely because of PHP alone. Old PHP travels with old plugins, because the whole site was left alone. Patchstack counted 11,334 new WordPress vulnerabilities in 2025, 91% of them in plugins.

PHP2Shell is different: the hole is in PHP itself, underneath every plugin, so a security plugin can't be relied on to stop it. How widely it's being used is disputed. Amazon says broadly; Sansec said on 22 October that mass exploitation looks less likely than it first feared. Either way, the bug is public and the fix exists, which is usually when attacks get better.

What a typical hack of a small business site looks like, and what to do in the first 24 hours, is in my guide to what to do when your WordPress site is hacked.

Your host can suspend an account that's been hacked and is spreading malware or spam, and many hosts eventually retire old PHP versions, which moves your site whether it's ready or not. Ignoring the update doesn't keep you on old PHP forever. It means the change happens on someone else's schedule.

On PHP2Shell itself: I searched on 24 October for hosts forcing PHP upgrades because of the flaw and found none. The hosts that posted notices patched the versions they offer. SiteGround, for example, says it patched every server on 21 October and customers needn't do anything.

Retiring old versions is slower, and already happening:

• SiteGround moved sites on its Managed PHP service to PHP 8.2 in 2024, with a week's notice. 92.92% passed its compatibility check and were upgraded; the other 7% stayed on PHP 7.4 to fix their code.
• Kinsta used to upgrade sites automatically once a PHP version reached end of life, before it started offering its own extended support for 7.4 and 8.0.
• Hostinger hides PHP 8.1 and lower from its version menu and starts new sites on 8.3.

Suspension is the sharper risk. Once a hacked site sends spam or serves malware, a shared host will often switch it off "to stop it from spreading", as Sucuri puts it. It stays down until it's cleaned.

Google doesn't check or penalise your PHP version, but if old PHP leads to a hack, Google can put a warning on your search listing and Chrome can show a red warning page before visitors reach your site. If your enquiries come from Google, that hurts.

Removing the warning takes time even after the clean-up. Google's Security Issues help page says "a review can take from a few days to a few weeks to complete", and you can only ask once the site is genuinely clean.

And the "Not secure" label in Chrome's address bar isn't about PHP. It means no working SSL certificate, and a PHP update won't clear it.

It can, if your site holds personal data and gets breached: the PDPC's decisions treat a known security patch that wasn't applied as a failure to protect personal data, and it has fined Singapore businesses for exactly that. I'm not a lawyer, and this isn't legal advice, but the published cases are clear enough.

The closest one is Goldheart Jewelry. A security patch for its online store's software came out in February 2022 and was applied 11 months later. In between, an attacker took the customer database, and the data of 41,379 people was published online. The PDPC fined the company S$58,000. Under section 48J of the PDPA, the cap is 10% of Singapore turnover for organisations above S$10 million, or S$1 million otherwise.

A brochure site isn't exempt. Its contact form collects names, numbers and emails, and many WordPress sites store every enquiry. My guide to PDPA duties after a website hack covers the 3-day notification rule and the decisions involving websites.

What happens if you don't update PHP depends on your version: on 8.3 or newer it's a patch your host should install, on 8.2 you have until 31 December 2026, and on 8.1 or older there's no fix from PHP at all. Find your row. Support dates are from PHP's supported versions page and the fixed releases from its security advisory.

On wordpress.org's own statistics, about 36% of WordPress sites that report their version sit in the bottom four rows. If you don't know your row, my guide on how to check your PHP version takes two minutes.

Updating PHP can break parts of a website, usually an old plugin, theme or page builder that uses code newer PHP removed, but on a properly done update the breakage turns up on a test copy first, and the switch can be undone in seconds. Plesk's own documentation is frank about it: "Different PHP versions are not 100% compatible."

It helps to know which kind of update you're facing:

• A patch on the same version, like 8.3.35 to 8.3.36, contains fixes only. It very rarely breaks anything, and on shared hosting your host does it for you.
• A jump between versions, like 7.4 to 8.3, is where sites break. PHP 8.0 removed old functions such as create_function() and each() outright, per PHP's 8.0 migration notes, so code that calls them stops dead.

When it breaks, it's usually a white page or WordPress's "There has been a critical error on this website", a contact form that quietly stops sending, or a checkout that errors halfway through. That's a reason to test first, not to stay put.

A broken PHP update is undone by switching the version back in your hosting panel, which takes effect within seconds, as long as someone took a backup first and your host allows going back. The safe order looks like this:

1. Back up files and database, with a copy off the server.
2. Make a staging copy, a private duplicate for testing.
3. Update WordPress, the theme and plugins on the old PHP.
4. Switch staging to the new PHP and test every form and the checkout.
5. Switch the live site at a quiet hour, and watch it for two days.

Two catches. Hostinger only lets you downgrade within the same login session, so on Hostinger, test before you log out. And this month, rolling all the way back to 8.1 lands you on a version with no PHP2Shell fix, so roll back one supported step and fix the plugin from there. My guide to updating PHP in WordPress without breaking it has the full test checklist.

Update now if you're on 8.2 or older, or if nobody can tell you your version; on 8.3 or newer, confirm your host has installed the 21 October fix and plan your next move calmly. Waiting only makes sense when your version is supported, patched, and someone owns the next update.

Singapore's Cyber Security Agency told organisations on 21 October to update PHP immediately, and here the official line matches the practical one. A planned update costs a few hours. An unplanned one costs a clean-up and lost enquiries on top.

If there's nobody to ask, start with my free PHP check. Send me your web address and I'll check which PHP version it runs, what it's built on and how old its theme and plugins are, then tell you what I find. If your host has already patched it, I'll say so, and you won't need me.

If it needs work, you get a fixed price in writing before I start, covering the backup, the PHP update and anything it breaks, from SGD 850, through my website maintenance service. After that, the content retainer at SGD 550 a month keeps it updated, backed up and secure, with 5 hours of changes. I've done this full-time since 2018, across 290+ projects.

You can put it off with less risk than a shop, but you can't ignore it: a brochure site on WordPress still has a public login page, plugins and usually a contact form full of personal data, and spammers want its domain. Google and email providers trust your domain, which is exactly what makes it useful to them.

Brochure sites are also where moving off PHP makes most sense. A statically built site has no PHP for a flaw to reach and no version to keep up with. I moved MET Interior's 176-page site from WordPress to Astro in August for reasons like these. A Starter rebuild is from SGD 2,535, and I'll quote it next to the fix so you can compare.

If your host confirms in writing that your exact version includes the 21 October 2026 fix, you're covered for PHP2Shell, but on 8.2 or older you still need to move to a newer version before support runs out. Ask for the number and the date, not a reassurance. A patched 8.1 is a stopgap. For the full story of the flaw and a message to send your host, see my guide to the PHP2Shell vulnerability.