Running an Old PHP App After PHP2Shell: Upgrade, Isolate or Rebuild?

What PHP2Shell is, in brief

PHP2Shell is the nickname for two flaws in the PHP interpreter, the software that runs PHP code on a web server. Details leaked on 20 October 2026, ahead of the planned disclosure. The PHP security team rates both Critical, with a CVSS v4.0 score of 9.2.

• CVE-2026-109618: running out of memory can interrupt PHP while it is only partly through setting up a request, so the clean-up later treats invalid data as valid.
• CVE-2026-109619: data from one request can survive after its memory is freed, and a later request handled by the same PHP worker may use it.

Wiz Research, reported by Patchstack, showed that an unauthenticated web request can lead to code running on the server, and that worker memory holding passwords, tokens and API keys could be read even without that. It applies to every way of running PHP, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The NCSC alert says that organisations using any version of PHP are affected.

Why PHP 8.1 and older have no official fix

Each PHP branch gets a fixed support period and then reaches end of life. The PHP team released fixes on 21 October 2026 for the four supported branches: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1, 8.0, PHP 7 and PHP 5 are end of life, so there is no official release for them.

That is not the end of the story for older versions. According to Patchstack, the PHP team published minimal backports for PHP 7.4, 8.0 and 8.1 for people who build PHP from source, and some Linux distributions and long-term support vendors ship their own backported fixes. A careful host can use those where they exist, and add further protection around the rest. What you cannot do is fix it from inside your own code: Cloudflare is clear that updating website code or plugins alone does not fix these vulnerabilities.

Choice 1: keep it running on protected hosting

Plenty of businesses rely on an application that works well and was never meant to be rewritten every few years. Many hosts simply refuse old PHP versions. Our sister company dijihost keeps offering PHP 5.6, 7.x, 8.0 and 8.1, and protects them in layers:

• Cloudflare's firewall in front. Cloudflare deployed emergency rules for PHP2Shell at 03:02 UTC on 21 October 2026, on every plan with its firewall, including Free. They only protect traffic through Cloudflare's proxy, so we check each hosted site is proxied. Cloudflare itself calls the rules a stopgap, which is why they are one layer of several.
• A security extension for old PHP. Hosted Power's open-source php_uploadprogress_guard closes the multipart upload path of both flaws on unpatched PHP 5.6 to 8.5, and steps aside on patched releases.
• Hardened PHP settings along the lines of the PHP team's temporary mitigations, such as turning off session.upload_progress and tightening request size limits.
• Each site isolated from its neighbours, with monitoring for signs of attack, and a vendor-patched build of the older version wherever one is available.

To be straight about it: for end-of-life PHP these layers are mitigations, not an official fix. The extension's own documentation says a patched PHP release is the only complete mitigation, and the PHP team says, according to Patchstack, that its temporary settings do not make an installation safe on their own. Layered together, they let an older application keep running while you decide what comes next.

Choice 2: upgrade when it makes business sense

Moving to PHP 8.4 or 8.5 is still the best long-term position, and PHP2Shell is a good prompt to find out what it would take. An upgrade means:

1. Audit the code for compatibility with PHP 8.2 to 8.5 using PHPCompatibility and PHPStan, so you know the size of the job before committing.
2. Fix deprecated and removed functions, such as the old mysql_* functions, each(), create_function() and dynamic properties.
3. Upgrade the framework and libraries: an old Laravel, CodeIgniter or Zend version, OpenCart extensions, or libraries pasted into the project years ago.
4. Test the important paths, such as login, checkout, invoicing and integrations, on a staging copy running the new PHP version.
5. Switch over in stages, with a rollback plan, while the old version keeps running on protected hosting.

Because the live system is protected in the meantime, the upgrade can be timed around your quiet season and budget. See PHP upgrade and modernisation for how we work.

Choice 3: rebuild if it is at the end of its life

Sometimes an upgrade is not the best use of money. A rebuild is worth considering when the audit shows most of the code would change anyway, when the application depends on a platform with no PHP 8 version, such as some Magento 1 stores and very old custom CMS builds, or when the business has outgrown what the system does.

A rebuild does not have to be a big-bang rewrite. The old system keeps running safely while we move one area at a time to a new application on current Laravel and PHP 8.4 or 8.5, migrate the data carefully, and switch the old one off once the new one is proven. See legacy software modernisation and our legacy migration checklist.

How to judge the effort

A short code audit gives the real answer, but these signs tell you roughly where you stand:

Other things that add effort: the number of integrations, payment and accounting links, cron jobs that call a specific PHP binary, and PHP extensions that no longer exist. Whichever way you lean, check the system for signs of tampering: unusual multipart requests followed by memory errors, oversized PHPSESSID cookies or unexplained PHP worker restarts. If you see them, the NCSC advises checking for backdoors, and the passwords, keys and tokens the server holds should be changed.

To start, tell us the exact PHP version (your host should be able to confirm it, such as 8.4.27), the framework or platform, and roughly how big the system is. We will look at the code and give a fixed-price quote for an upgrade, a rebuild, or both so you can compare.

Related