PHP 7.4, 8.0 and 8.1 are end of life: what PHP2Shell means for your site and how an upgrade works

When PHP published its emergency releases on 21 October 2026, it did what it always does: it fixed the branches that are still supported. PHP 8.2, 8.3, 8.4 and 8.5 received a release. PHP 8.1 and everything older did not, and will not. For the many sites still running those versions, PHP2Shell turned a long-standing "we should upgrade at some point" into a decision that cannot wait. If you are not sure which version your site runs, check it first; it takes a minute.

What "end of life" means

Each PHP branch gets about two years of active support and two further years of security fixes. After that it is end of life: no fixes of any kind, however serious the problem.

For PHP2Shell the PHP team went one step further than usual and published minimal source patches for 7.4, 8.0 and 8.1. Those are for people who compile PHP themselves. They are not releases, not packages, and most hosting accounts cannot use them. Some Linux distributions and hosting providers build their own backported packages; if yours does, confirm it with them. If not, there is no fix for your branch, and the only real option is to move to a supported one.

Which version to move to

Not 8.2. It is patched, but its security support ends on 31 December 2026, which would put you back in the same position within weeks. The practical targets are:

• PHP 8.3 when you want the smallest step that still buys time, with security fixes until the end of 2027. Most actively maintained WordPress plugins and PHP packages support it.
• PHP 8.4 when your plugins, theme and packages already declare support for it. It is the better long-term choice.

Check support before deciding. In WordPress, the plugin and theme pages on wordpress.org list "Requires PHP" and the version they were tested with. For Composer-based applications, composer why-not php 8.4 lists every package that would block the move.

What usually breaks

A jump from 7.4 to 8.3 or 8.4 skips years of changes. Most sites come through with a handful of fixes, but these are the usual suspects:

• Stricter types. Internal functions now throw errors instead of warnings for wrong argument types, and passing null where a string is expected is deprecated since 8.1. Old code that relied on silent conversion starts failing.
• Removed functions. create_function(), each() and money_format() are gone since 8.0; the mysql_* functions since 7.0. Legacy themes and custom plugins still use them.
• Changed comparisons. Since 8.0, 0 == "text" is false. Code that compared numbers and strings loosely can take a different branch.
• Deprecations that become noise. Dynamic properties on classes and ${var} string interpolation are deprecated since 8.2. They still work, but they fill the error log and will break in a future release.
• Abandoned plugins and themes. Anything not updated for PHP 8 is a risk. This is often the real job: finding a replacement.
• Framework version caps. Older Laravel releases only support the PHP versions that existed at the time. A PHP upgrade can mean a framework upgrade first, which is a bigger project.

How a planned upgrade runs

This is the order we use, for a single WordPress site or an agency's portfolio of client sites:

1. Inventory. Which sites, which hosting, which PHP version and SAPI, which plugins, themes and packages. For a WordPress site, the Site Health info tab gets you most of the way.
2. Compatibility check. Automated scans first: the PHP Compatibility Checker plugin or a PHPCompatibility run for WordPress code, composer why-not plus PHPStan or Rector for applications. Then a read of the custom code the scanners cannot judge.
3. Staging copy. A copy of the site on the target PHP version, where errors cost nothing. Most hosting panels can do this; otherwise we set one up.
4. Fix and retest. Work through the error log and the key journeys: home, inner pages, search, login, forms, checkout, admin screens, scheduled tasks.
5. Switch production. In an agreed maintenance window, with a backup taken first and a rollback path to the old version if something unexpected appears.
6. Watch. Logs and key pages for a few days after the switch, because some paths only run occasionally.

A patch update within the same branch, say 8.3.30 to 8.3.36, needs far less than this: install, restart the PHP workers, check the key pages. The checklist above is for the cross-branch move that end-of-life sites now face.

In the meantime

If the upgrade needs a few days of planning, PHP's own advisory lists interim measures: set session.upload_progress.enabled=0 and restart the workers, keep memory_limit unrestricted, put sensible request-size limits at the web server, and use a web application firewall. They reduce exposure to the known attack paths. They do not make an end-of-life PHP safe, and nothing will until the site runs a supported version.

If you would like help with the inventory or the upgrade itself, send us your website address, hosting provider and current PHP version. We confirm where you stand and what the move would involve.