PHP2Shell on PHP 7.4, 8.0, 8.1 and Older: Your Real Options

The PHP2Shell fixes released on 21 October 2026 (8.2.35, 8.3.36, 8.4.27 and 8.5.12) only cover supported branches. If a server runs PHP 8.1, 8.0, 7.4 or older, no new php.net release is coming. Those versions are still vulnerable. The background is in our PHP2Shell explainer. This post covers what to do when your PHP is past end of life.

Where each old branch stands

You have four realistic options, often used together: a patched package from your OS or a long-term-support vendor, a source build with PHP's backport, an upgrade, and isolation while you get there.

Option 1: a patched vendor package

This is the fastest fix if your platform has one, because it keeps your PHP version and only swaps in patched code. What we could confirm from vendor sources:

Commercial extended-support vendors such as TuxCare ELS and ZendPHP LTS also ship patched builds of old branches, and Freexian ELTS covers older Debian releases. Check the vendor's own advisory for the two CVE IDs before you rely on any of them.

Whichever source you use, verify the installed package rather than the version string. A patched 8.1 build still reports 8.1.x.

# Debian/Ubuntu: search the whole changelog (Sury's CVE line may not be in the top entry)
zgrep -E 'CVE-2026-10961(8|9)' /usr/share/doc/php8.1-common/changelog.Debian.gz

# RHEL family
rpm -q --changelog php-common | grep -E 'CVE-2026-10961(8|9)'

Option 2: build from source with PHP's backport

The PHP security team published minimal source backports for 7.4, 8.0 and 8.1 for people who build PHP themselves. There is no tarball, binary or version bump. This suits teams that already compile their own PHP, such as custom Docker base images. You own the build from then on, including every future security fix, and the official Docker Hub 8.1 and older tags have not been rebuilt, so images based on them need your own build or a vendor image.

Option 3: upgrade to a supported branch

A backport fixes this bug. It does not fix the next one. 8.2 itself reaches end of life on 31 December 2026, so for an upgrade made now, aim for 8.4 (security support to 31 Dec 2028) or 8.5 (to 31 Dec 2029). If you need a stopgap, 8.3 is supported until 31 Dec 2027.

A sensible order of work:

1. Patch first using Option 1 or 2 (or isolate using Option 4). An upgrade project should not leave you exposed in the meantime.
2. Inventory the app: framework and CMS versions, Composer dependencies, PHP extensions (php -m) and anything compiled or proprietary such as ionCube-encoded modules. Check each supports the target version.
3. Run static checks: PHPCompatibility for PHP_CodeSniffer to flag removed functions and syntax, and Rector to apply many of the mechanical changes automatically.
4. Update dependencies with composer update against the target platform. Old framework versions are often what blocks an upgrade, so upgrading the framework may be the real project.
5. Test on a staging copy with production-like data. Common breaks from 7.4: stricter comparisons between strings and numbers, warnings that became errors, removed functions such as each() and create_function(), and dynamic property deprecations from 8.2.
6. Switch over with a rollback ready. Running two PHP-FPM versions side by side (one pool per version) lets you move one site at a time.

For WordPress, Drupal, Magento and similar platforms, check the platform's own PHP compatibility matrix first; the core may be fine while an old plugin or theme is not.

Option 4: isolate what you cannot fix yet

Some systems, often PHP 5 or 7.3 applications that nobody can easily change, have no fix at all. For those, reduce who can reach them and what they can do:

• Take it off the public internet. Put it behind a VPN, an identity-aware proxy or at least an IP allowlist. PHP2Shell needs no login, so application passwords do not help, but network-level access control does.
• Apply the temporary settings from the explainer: session.upload_progress.enabled = 0, a small post_max_size, and memory_limit = -1 only with a hard memory cap outside PHP. These lower the risk without removing it.
• If the app never takes file uploads, block multipart/form-data at the proxy or WAF.
• Contain the damage: a dedicated host or container, a read-only filesystem where possible, no outbound internet access except what the app needs, and least-privilege database and cloud credentials.
• Watch it: alert on the web user spawning shells and on new files in the web root.
• Set a decommission or migration date and give it an owner. Isolation is a holding pattern, not a fix.

Choosing quickly

If you have to justify the work, use this incident. Cyber Essentials, for example, expects critical and high-risk patches within 14 days and unsupported software to be removed or isolated (see our Cyber Essentials guide).

Sources

• PHP security advisory, 21 October 2026 and supported versions
• watchTowr PHP2Shell FAQ
• Sansec research
• Ubuntu CVE-2026-109618 and Amazon Linux
• Ondřej Surý package repository

HashTech Systems handles PHP2Shell remediation for end-of-life PHP, including vendor backports, source builds, isolation and upgrade planning.