PHP End of Life After PHP2Shell: What 8.1, 8.0, 7.4 and Older Can Still Do

The PHP2Shell fix shipped on October 21, 2026 for four branches only: 8.2, 8.3, 8.4 and 8.5. If your servers run PHP 8.1, 8.0, 7.4 or anything older, there is no official release that closes CVE-2026-109618 and CVE-2026-109619. The research teams say the flaws reach back to PHP 5.4. The PHP advisory is direct: "PHP 8.1 and older no longer receive updates from the project."

That makes PHP2Shell the end-of-life incident many teams postponed. This guide explains where each branch stands, the three ways to get a fix onto an old branch, why those are bridges and not answers, and how to plan the upgrade. For the incident itself, see PHP2Shell: what happened and what to do now on explainx.ai. For commands on supported branches, the PHP2Shell patch guide.

TL;DR: where each PHP branch stands

Support dates are from php.net's supported versions page. The source backports are branches the PHP team published alongside the advisory: PHP-7.4-CVE-2026-109618-109619, PHP-8.0-CVE-2026-109618-109619 and PHP-8.1-CVE-2026-109618-109619 in the php-src repository.

Why end of life matters more this time

Running an old PHP branch has always carried risk. PHP2Shell changes the math in three ways.

1. The bug is in the interpreter. Application patches cannot help. A WordPress, Laravel or Drupal update on PHP 7.4 leaves the vulnerable code in place. Wiz says even a "Hello World" app on an affected runtime is exposed.
2. Exploitation is public and automated. The php2shell exploit script exists, Cloudflare saw attack traffic before the patch, and heise reports that remote code execution works within thousands to tens of thousands of requests, which is cheap for a scanner.
3. Old branches are the long tail. Tenable's detection set includes a dedicated "PHP Unsupported Version Detection" plugin for a reason. Old PHP lives in forgotten admin panels, vendor appliances, intranet tools and container images nobody rebuilt.

Three ways to get a fix onto an old branch

1. Your distribution or LTS vendor's package

This is the best bridge. The PHP advisory says Linux distributions and LTS vendors received patches in advance. Some examples from October 21:

• Ubuntu 22.04 ships PHP 8.1. USN-8948-1 lists the fixed package as 8.1.2-1ubuntu2.28. Ubuntu 18.04 and 20.04 need Ubuntu Pro ESM.
• packages.sury.org published fixed builds for every PHP version from 5.6 to 8.5 on Debian 11 to 13 and Ubuntu 22.04 to 26.04 (amd64), per Mattias Geniar's check.
• Debian 11 is covered only by paid ELTS, since Debian LTS ended on August 31, 2026.
• RHEL 8 defaults to PHP 7.2, which is retired and will not get a fix.

Check the package version, not php -v. Distribution builds keep the old upstream number.

dpkg -l 'php*' | awk '/^ii/{print $2, $3}'
zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php8.1-fpm/changelog.Debian.gz
rpm -q --changelog php-fpm | head -20

2. Build from the PHP team's source backport

The backport branches are minimal: they carry the PHP2Shell fix and nothing else. Building PHP from source is a real commitment. You own the build, the extension set and every future security fix. Use this only if you already build PHP yourself.

3. Commercial extended support

Several vendors sell extended support for end-of-life PHP. If you already pay for one, ask for their PHP2Shell build and its date. If you do not, buying extended support now is a way to buy time, not a way to stay on the old branch for years.

Why a backport is a bridge, not a destination

A patched 8.1 closes PHP2Shell. It does not close the next interpreter bug, and the next one is likely to arrive faster. Wiz said "other variants likely exist." AI-assisted auditing found these bugs in code that had sat for more than a decade, and the same tools are pointed at PHP now. Every future fix will land first on supported branches, and end-of-life branches will depend on whoever chooses to backport it.

There is also a hidden cost. Old PHP usually comes with old everything: old frameworks, old extensions, old OpenSSL. The stack accumulates known flaws beyond PHP2Shell.

If you cannot upgrade this week

Do these in order for every end-of-life PHP host:

1. Take it off the public internet if it does not need to be there. CERT-EU recommends isolating internet-facing applications when patching is not possible. A VPN or an identity-aware proxy in front of an admin tool removes the unauthenticated attack path.
2. Install a vendor backport or the source backport build.
3. Apply the interim mitigations from the PHP advisory: memory_limit=-1 set with php_admin_value plus a container or cgroup memory cap; low post_max_size; session.upload_progress.enabled=0 in php.ini or the pool config; block multipart/form-data where the app takes no uploads. Never use RLIMIT_AS or RLIMIT_DATA.
4. Put it behind a WAF and restrict the origin to the WAF's IP ranges. Cloudflare calls its PHP2Shell rules "a stopgap only."
5. Watch for the signs listed in the patch guide, and rotate secrets on the host if you see them.
6. Set an upgrade date and write it down.

Planning the upgrade: skip 8.2

If PHP2Shell is what finally moves you off 8.1 or 7.4, do not land on 8.2. Its security support ends on December 31, 2026, ten weeks from the patch date. Target 8.4 (security until end of 2028) or 8.5 (until end of 2029).

A practical path for most teams:

• Run the app's test suite and a static analyzer (PHPStan or Psalm) against the target version in CI.
• Upgrade the framework to a version that supports the target PHP first.
• Ship to staging on the new PHP with production-like traffic, then cut over.
• Remove old PHP packages from the host after cutover so nothing falls back to them.

AI coding agents can speed up the mechanical part of a PHP upgrade: fixing deprecations, updating type hints, adjusting removed function calls. They can also introduce risk if they run unchecked shell commands on servers during the migration. Keep agents in a branch with tests, review diffs, and log what they run. Beam records the commands and file access of coding agents such as Claude Code and Codex on your machine, which gives you an audit trail for that work.

How to find every old PHP you own

End-of-life PHP hides. Search wider than your main web servers:

# Linux hosts
which -a php php-fpm php-cgi 2>/dev/null; ls /usr/bin/php* /usr/sbin/php-fpm* /opt/*/bin/php* 2>/dev/null
# Containers built from old images
docker images --format '{{.Repository}}:{{.Tag}}' | grep -Ei 'php:(5|7|8\.0|8\.1)'
# Windows
where php.exe php-cgi.exe

Also check control panels (cPanel, Plesk), bundled PHP in vendor appliances, CI runner images and old staging servers. Huntress specifically calls out Windows software that bundles php.exe or php-cgi.exe.

What people ask

"Our host says we are on PHP 7.4 but patched. Is that true?"

It can be. Some hosts run commercial extended-support builds or the backport. Ask for the build date and whether it includes CVE-2026-109618 and CVE-2026-109619. Get the answer in writing.

"We are on 8.2. Are we fine?"

For PHP2Shell, yes, once you run 8.2.35 or a patched distro package. For next year, no: 8.2 gets no security fixes after December 31, 2026. Start the move to 8.4 or 8.5 now.

"Is PHP 8.1 in Ubuntu 22.04 supported?"

Ubuntu supports its own 8.1 package for the release's standard support window and patched it for PHP2Shell. That is Ubuntu's support, not the PHP project's. Upstream 8.1 is end of life.

Related reading

• How PHP2Shell works
• PHP2Shell patch guide: Ubuntu, Debian, RHEL, Docker
• PHP2Shell and AI agents: why the attack window just collapsed
• CVE-2026-109618 and CVE-2026-109619 in the AgentBeam CVE database
• PHP2Shell: what happened and what to do now on explainx.ai

Primary sources: PHP supported versions · PHP security advisory · PHP 8.1 backport branch · Mattias Geniar's patch notes · Tenable FAQ

Support dates and package availability are accurate as of October 21, 2026. Check php.net and your vendor before relying on them.