# Your PHP Branch Is End-of-Life: What Now

By PHP Patch Assurance · Last updated: 2026-10-25

A PHP branch is end-of-life when its maintainers stop shipping security fixes for it. Branches below 8.2 are end-of-life, which means no php2shell fix exists for them at any price: the flaw cannot be patched in place. The only durable answer is moving to a supported branch; anything else buys time, not safety.

## What end-of-life means

End-of-life is not a warning label; it is the end of fixes. Once a branch passes its support window, newly found flaws in it get no upstream release, no matter how severe. A site on an end-of-life branch accumulates unfixable exposure with every new disclosure.

## Why php2shell is different for EOL branches

For supported branches the fix is a version number: 8.2.35, 8.3.36, 8.4.27, 8.5.12. For branches below 8.2 there is no fixed release, so there is nothing to upgrade to within the branch. The table on the [php2shell page](/threats/php2shell) shows the gap plainly: below 8.2, fixed release — none.

## Option 1: upgrade the branch

Move to a supported branch — 8.2 or newer — with the same gates as any patch: snapshot first, test on staging, verify after. Branch upgrades can break code that relies on removed functions, so this is a tested migration, not a version bump. For Docker hosts the upgrade follows the same pin, build, verify and swap path as a patch.

## Option 2: mitigate temporarily

A configuration stopgap around session.upload_progress exists for end-of-life branches, and it reduces exposure — but it is mitigation, not a patch, and it does not make an end-of-life branch patched. Treat any mitigation as weeks of bought time while the upgrade is planned, never as the answer.

## Option 3: take the site offline

When neither an upgrade nor a mitigation is possible quickly, taking an internet-facing site offline until it can be upgraded is the advice CISA gave for PHP 8.1 and earlier during php2shell, and the step Japan's prime minister took with her own site. Offline is not failure; an unpatched internet-facing EOL site is the failure.

## What not to do

Do not let anyone label an end-of-life branch patched — there is no fix to apply, so the label would be false. And do not run an internet-facing end-of-life site indefinitely while planning an upgrade that never starts.

## Frequently asked questions

### Can I pay someone to patch end-of-life PHP?

No. There is no upstream fix to apply, so there is nothing to install. Anyone claiming to patch an end-of-life branch in place is mislabeling a mitigation or an upgrade.

### How long can a mitigation hold?

Unknown, and that is the point. Treat a mitigation as weeks of bought time while the branch upgrade is planned and tested — not as a strategy.

### What breaks on a branch upgrade?

Most often code that relies on removed or changed functions, and extensions that have no build for the new branch. Stage it, run the application's own tests, and check the error log before going live.