End-of-Life PHP and PHP2Shell: What to Do When No Fix Is Coming

Four branches got a release; yours may not be one

The PHP project still supports four branches, 8.2 through 8.5, and each got a fixed release on October 21. Everything older is end of life, and the project's advisory says so without ceremony: "PHP 8.1 and older no longer receive updates from the PHP project." That would be a footnote if the bugs were new. They are not. Wiz Research, which found them, says nearly every version back to PHP 5.4 is affected by at least one, and that the flaws sat in the code for more than a decade.

The dates come from the project's supported versions page and its end-of-life list, and the release details from its 2026 news archive. If you do not know which row is yours, find your PHP version before reading further. The answer surprises people more often than it should.

Seventy-one percent, by one large count

Old PHP is not a corner case. In a blog post on October 20, 2026, Qualys reported finding about 167 million PHP package installations in anonymized data from 12,000 customers, 73 percent of them on internet-facing assets. Of the roughly 155 million with a known version, about 110 million, or 71 percent, ran end-of-life branches from 5.4 to 8.1, according to Qualys. About 44 million, 28 percent, were on a supported branch.

Qualys also counted about 199,000 installations patched in the first 12 hours after disclosure. Set that beside 167 million and you have a fair portrait of how PHP tends to live: installed once, configured once, and left to age on a server nobody logs into until something breaks. The supported, patched installation is the unusual one.

In Qualys's count, end-of-life PHP is not the exception. It is the majority.

How a site ends up running 7.4 in 2026

Nobody chooses an unsupported PHP version. They inherit one. The site was built when 7.4 was current, it worked, and the one attempt to change the version produced a white screen, so someone changed it back and taped a note to the monitor that has since outlasted two office managers. The usual culprits:

• The theme stopped in 2019. A premium theme whose vendor moved on still calls functions PHP 8.0 removed, such as `create_function()` and `each()`, and falls over the moment the version changes.
• One plugin holds the rest hostage. A booking, membership or payment plugin that was never updated works only on old PHP, and it is, naturally, the one that makes money.
• A custom app with no author. The developer who wrote the quoting tool or client portal left, the code has no tests, and nobody will sign up to change the ground beneath it.
• The account was never touched. On shared hosting, an account created years ago can stay pinned to the version that was standard then, because nobody opened the version selector since.
• The server itself is old. A VPS on an aging operating system release keeps the PHP that release shipped with.

Each of these has a cure, and none of the cures is complicated so much as postponed. The rest of this page is the menu, in the order we usually recommend it.

Option one: jump to 8.3 or 8.4 and fix what breaks

For most sites this is the right answer, and it is the only one that ends the problem instead of deferring it. Aim for 8.3 or 8.4. PHP 8.2 carries the fix as well, but the project says 8.2 gets no security fixes after December 31, 2026, about ten weeks away. A jump you will have to repeat in January is a jump half wasted.

What breaks is predictable. According to the PHP manual, PHP 8.0 removed `create_function()`, `each()` and `get_magic_quotes_gpc()`, stopped treating a method named after its class as a constructor, and turned a number of warnings into errors that stop the page. Themes and page builders from the 7.x years are the usual casualties. We keep notes on WPBakery under PHP 8, Genesis PHP errors and theme PHP errors in general.

1. 1

   Copy the site to staging

   Clone the files and database to a staging site on the same host, or a local copy. A PHP jump is never tested on the live site first.

2. 2

   Update everything while still on the old PHP

   Bring the CMS, the theme and every plugin to their latest versions. Many PHP 8 fixes are already sitting in updates nobody installed.

3. 3

   Switch staging to the new branch

   Set 8.3 or 8.4 for the staging site in the control panel or server config, and turn on error logging so failures are written down rather than guessed at.

4. 4

   Walk the money paths

   Load every template, submit every form, run a test checkout or booking, and log in as an editor. Then read the error log, not just the screen.

5. 5

   Fix, replace or retire

   Repair the code that fails, swap abandoned plugins for maintained ones, and remove the ones nobody can explain.

6. 6

   Switch production in a quiet hour

   Take a fresh backup, change the live site's PHP version and repeat the walk. If something breaks, fix forward or restore the code from backup; do not drop back to the unpatched PHP.

If the site goes white partway through, that is our $249 site down repair, which starts with getting the site back online. Readers on shared hosting will find the version controls in our cPanel and Plesk guide; server owners, in the VPS and Docker guide.

Option two: a backported build, and its fine print

If an upgrade truly cannot happen this week, a backport can close PHP2Shell on the branch you already run. The PHP project's own advice is to contact your distribution or LTS vendor or move to a supported version. A fixed build can come from three places.

Know the trade. Qualys notes that backported fixes may keep an older upstream version number, which is why outside scanners can misread a patched server and why you check the tracker for the CVE, not the number. More important, a backport fixes the bugs someone chose to fix. The branch stays end of life, themes and plugins keep dropping support for it, and the next interpreter bug may not get the same courtesy. Use a backport to buy time for option one or three, not to avoid both.

Option three: stop serving PHP to strangers

PHP2Shell needs an anonymous request to reach PHP. Take PHP off the public internet and that request has nowhere to land. That is the case for the Next.js route, which comes in two sizes.

Keep WordPress, but hide it

DataCram builds a Next.js front end that pre-renders every page to HTML and serves it from Vercel's global edge network. WordPress moves behind it as a private, headless content source, with the admin behind a login allowlist or VPN and no public PHP endpoints. Editors keep their dashboard; Next.js reads the content through the WordPress REST or GraphQL API, and URLs and redirects carry over. The honest catch for readers of this page: that private WordPress still needs a patched PHP. Hiding an old version is a good second wall, not a substitute for the first. The trade-offs are laid out in headless WordPress vs Next.js.

Leave PHP behind altogether

The full move replaces WordPress with Athena CMS, the content system included with every custom site DataCram builds, with no PHP anywhere. The switch from WordPress keeps your URLs and redirects every old one. Next.js has had security advisories of its own, and any server code a site runs, such as forms and APIs, still needs upkeep, so this does not make a site invulnerable. It removes this class of bug, and pre-rendered pages leave an attacker very little to talk to.

Custom builds and rebuilds are a fixed price starting at $1,750; sites with a store, portal or web app start at $3,500, quoted after a free audit, with financing for WordPress projects. The order matters: patch or shield the old site today, then rebuild, so it is never exposed while the new one is made. If you are still weighing it, should you leave WordPress is the longer argument.

Choosing among the three this week

Most readers can sort themselves in a minute. Find your situation, do the first step today, and put the second on the calendar with a date, not a season.

• On 8.2: update to 8.2.35 now, then schedule the move to 8.3 or 8.4 before December 31.
• On 8.0 or 8.1 from a distribution package: look up both CVE IDs in your distribution's security tracker, install the fixed package, then plan the upgrade.
• On 7.4 or older with a theme that breaks on PHP 8: apply the PHP project's interim settings and a firewall rule now, then start the staging upgrade or a rebuild this week.
• On a custom app nobody will touch: get a fixed vendor build in place, put the app behind a firewall rule, and get a quote for either repairing the code or replacing the public side.
• On anything, if you think it was already hit: read the signs of compromise before changing anything, so the evidence survives.

If you would rather hand it over, the PHP2Shell emergency fix exists for this: we update PHP or move the site to a plan that offers a fixed release, apply the interim settings while an update must wait, test the site, check for compromise and clean up if needed. WordPress work uses our fixed Fix It Now prices; work starts within one business day of payment, and the refund is full if we can't fix it. A site that cannot run on PHP 8.2 or newer gets a quote after a free check, at (210) 346-0848. Afterward, hosting and maintenance plans keep the version current, so the next end-of-life date lands on someone else's calendar.