PHP 8.1, 8.0 or 7.4: your site has no fix. How to upgrade to a supported version

The PHP security release of 21 October 2026 has a consequence many site owners are discovering today: PHP 8.1 and every earlier version receive no fix. The two critical flaws (CVE-2026-109618 and CVE-2026-109619, explained in our dedicated article) have been in those versions for years, and they will stay there. If your site runs 7.4, 8.0 or 8.1, this article explains why waiting is not an option and how to migrate cleanly to 8.3 or 8.4.

PHP's support calendar

Each PHP branch receives bug fixes for two years, then security fixes for two more, before reaching end of life. In October 2026 the situation is:

• PHP 8.5, 8.4 and 8.3: supported, fixes available (8.5.12, 8.4.27, 8.3.36).
• PHP 8.2: security fixes until 31 December 2026 only (8.2.35 is available).
• PHP 8.1, 8.0, 7.4 and earlier: end of life, no official fix for the flaws of 21 October.

The PHP team did publish minimal backports of the fix for 7.4, 8.0 and 8.1, aimed at people who build PHP from source, and some Linux distributions or extended-support vendors ship the fix in their packages. For a conventionally hosted site, that changes nothing: the version you use comes from your host, and the only safe route is migration.

Why "it still works" is not an argument

A site on PHP 7.4 works perfectly today, just like yesterday. The risk is not that it stops, it is that it becomes an open door. The flaws of 21 October allow, in the demonstrated conditions, an unauthenticated request to run code on the server. And CISA, the US cybersecurity agency, recommends taking offline systems on PHP 8.1 or earlier that cannot be upgraded. That is not a routine recommendation: it reflects the severity of the flaws and the fact that attackers already have public material to reproduce them.

There are indirect consequences too. A compromised site can be used to send spam from your domain, host phishing pages, mine cryptocurrency or serve as a relay towards other targets. The fallout ranges from your domain being blacklisted to the loss of customer data, with the legal obligations that follow.

What changes between 8.1 and 8.4

A branch migration is not a minor update. Between PHP 7.4 and 8.4 the language removed functions, made some errors stricter (types, dynamic properties, null parameters) and deprecated usages common in old code. In practice, the things that break most often:

• Abandoned WordPress plugins and themes that use removed functions or deprecated constructs.
• Old custom code without tests: type errors that were silent in 7.4 become fatal in 8.x.
• PHP extensions (mcrypt, for example) that no longer exist and must be replaced.
• Outdated frameworks: Laravel 8 and earlier, Symfony 4, CodeIgniter 3, which do not officially support PHP 8.4.
• Composer libraries pinned for years.

The migration method in 6 steps

1. Inventory: current version, CMS or framework, list of plugins, extensions and libraries, with their last update date.
2. Compatibility analysis: tools such as PHPCompatibility (for PHP_CodeSniffer) or Rector spot incompatible code. On WordPress, the PHP Compatibility Checker plugin gives a first idea, to be confirmed by a real test.
3. Staging environment with the target version (8.3 or 8.4), a copy of production data and full error display enabled.
4. Fixes: update plugins and libraries, replace abandoned ones, fix custom code.
5. Acceptance testing: full walk-through of the site, forms, checkout, exports, scheduled tasks, email sending, third-party integrations.
6. Switch at a quiet time with a backup just before, then watch the logs for several days.

What to do while waiting for the migration

If the migration takes several days (substantial custom code, plugins to replace), do not leave the site exposed in the meantime. In order of effectiveness:

• Check with your host or distribution whether a backported package exists for your version. Some extended-support vendors (for 7.4, 8.0 and 8.1) have shipped one.
• Apply the temporary measures described by the PHP team: session.upload_progress.enabled = 0 in the server configuration with a worker restart, memory_limit enforced at the container level rather than in PHP, a low post_max_size. They reduce exposure without removing it.
• Put a web application firewall in front of the site and, if the application is internal, restrict access by IP address or VPN.
• As a last resort, take the site offline or replace it with a temporary static page, as CISA recommends for systems that cannot be fixed. A "back soon" page costs less than a compromise.

How long does a migration take?

For a well-maintained WordPress site, going from 8.1 to 8.4 is often done in half a day, testing included. For a site with abandoned plugins or an old theme, allow a few days to find and test alternatives. For a custom application without automated tests, the duration depends on the size of the codebase: the initial compatibility analysis gives a reliable estimate within a few hours. In every case it is an investment that comes around every two to three years; planning it means not suffering it on the day of an alert.

We migrate your site to a supported version

PHP version migration is part of our managed services: compatibility analysis, fixes, testing on a staging environment and a supported switch. If you have just found out that your site runs 7.4 or 8.1, contact us: the first step, the inventory, is quick and tells you what to expect.