PHP 7.3, 7.2 and PHP 5 After PHP2Shell: Upgrade or Take It Offline

As of 23 October 2026, PHP 7.3, 7.2, 7.1, 7.0 and every PHP 5 release have no fix for PHP2Shell (CVE-2026-109618 and CVE-2026-109619) from the PHP project. Not a release and not a source backport. The PHP security team's backports stop at PHP 7.4. Researchers report the flaws go back to PHP 5.4, released in 2012, so these old versions are affected.

The direct answer: upgrade to a supported PHP, or take the site off the public internet until you can. A few paid extended-support vendors and hosting platforms still ship patched builds for some of these versions, and they can bridge a short gap. But a server this old has missed years of other security fixes too, and the software running on it is usually just as old.

This page lists what is still patched, explains why it is only a bridge, and shows how to isolate a site safely while you rebuild or upgrade it.

Where These Versions Stand

All of these branches stopped receiving PHP security fixes years ago. The dates come from PHP's end-of-life page:

PHP's own advisories list only the supported branches (8.2 to 8.5). The US National Vulnerability Database now marks PHP 5.4.0 and later as affected for CVE-2026-109619, and Wiz, Calif and watchTowr all say older branches are affected. watchTowr's summary for "PHP 7.3 and older, including PHP 5" reads: "No fix available. Upgrade to a supported branch." Treat any of these versions as vulnerable unless a vendor has given you a patched build.

Who Still Patches PHP 7.3 and Older

PHP published fixes to Linux distributions and support vendors before the public release. Some of them patched very old PHP for their paying customers. As of 23 October 2026:

Some managed hosts also say they patched or mitigated very old PHP on their platforms. If you are on managed or shared hosting, ask your host directly whether your site runs a patched build or only sits behind mitigations, and how you can confirm it. Our guide on how to check your PHP version covers build dates and changelogs.

Why a Patched PHP 5 or 7.2 Is Only a Bridge

A vendor patch closes PHP2Shell. It does not make an old stack current. Three problems remain:

• Years of other missed fixes. These branches got no upstream fixes after their end-of-life dates, some as far back as 2015. What a vendor has backported beyond PHP2Shell varies, and only the vendor can tell you.
• The software on top is just as old. A site on PHP 5.6 or 7.2 is almost always on an old CMS, old plugins and an old database driver. Those get no fixes either.
• Each patch is a favor, not a promise. AlmaLinux says outright that "future fixes for retired streams are not guaranteed." The next PHP flaw may not get the same treatment.

Use a patched build to stay online for a defined period while you upgrade or rebuild. Pick an end date.

Don't fill the gap with unofficial patch scripts. No official PHP source backport exists for these versions, so any script claiming to be one did not come from the PHP project. Security firms have warned that some PHP2Shell repositories on GitHub are fake.

Joomla 3, Drupal 7 and Old WordPress

The PHP2Shell flaws are in PHP, not in these platforms. But sites on very old PHP are usually on very old CMS versions too:

• Joomla 3: official support from the Joomla volunteer community ended on 17 August 2023. Joomla 4 needs PHP 7.2.5 or later, Joomla 5 needs 8.1 and Joomla 6 needs 8.3.
• Drupal 7: Drupal says "Drupal 7 security support has ended as of 5 January 2025." Its certified extended-support vendors are HeroDevs and Tag1 Consulting. Drupal 10 needs PHP 8.1 or newer and Drupal 11 needs 8.3, so moving off Drupal 7 also means moving off old PHP.
• WordPress: WordPress 7.0 "dropped support for PHP 7.2 and 7.3," so 6.9 is the newest WordPress that runs on them. WordPress 6.6 dropped PHP 7.0 and 7.1, and PHP 5.6 has been unsupported since WordPress 6.3. WordPress dropped security support for its 4.1 to 4.6 branches in July 2025. See our PHP2Shell guide for WordPress.

On a Joomla 3 or Drupal 7 site, switching PHP alone does not get you to a supported setup, because the CMS itself no longer gets fixes from its project. Plan the CMS migration and the PHP upgrade together. That is usually where the decision between upgrading and rebuilding gets made.

What Changed Between PHP 5 and PHP 7.4

Getting to a supported PHP from here means crossing every migration guide from your version to 8.3. The early ones contain some of the hardest breaks:

The removal of the old mysql extension in PHP 7.0 is the classic blocker. Any PHP 5 code that still calls mysql_ functions will not run on PHP 7 or 8 until its database code is rewritten.

How to Take a Site Offline or Isolate It Safely

The agencies are consistent. CISA says organizations that "continue to use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched or updated." The UK NCSC says to "consider taking the system offline" if mitigations cannot be applied in time. The EU agencies advise "isolating exposed applications from public networks until fixes can be applied."

1. Preserve evidence first. Beazley advises: "Preserve web, PHP, application, and host logs before restarting or rebuilding a suspect system." Take a full backup of files and database too; our guide to website backup and recovery explains what a usable backup looks like.
2. Take public traffic off PHP. Serve a static maintenance page from the web server or CDN, or restrict access by network. Beazley warns against "disabling the PHP handler, which can expose application source code and credentials."
3. Keep internal tools behind a VPN. For PHP applications that staff need but the public doesn't, Beazley recommends restricting them "to trusted networks or a VPN."
4. Check for signs of compromise. Exploitation attempts were reported from 17 October 2026, so look back at least that far. Our guide was my site hacked by PHP2Shell? lists what to look for.
5. Bring it back only on a supported or patched PHP. Restore on a fresh server with a supported PHP, or on a vendor-patched build with a fixed end date for the upgrade.

If the site's job is mostly informational, a static snapshot can keep the content online while the PHP application stays offline. Our website incident response plan covers the communication side.

Upgrade or Rebuild?

For a site on PHP 7.3 or older, the honest comparison is between a multi-step upgrade (CMS migration plus PHP 8 compatibility work on every plugin and piece of custom code) and a new build on a current platform. Upgrading usually makes sense when the CMS has a supported migration path and most extensions have current versions. A rebuild is often cheaper when the CMS is end of life, key plugins are abandoned or custom code uses removed functions throughout. Our guide to upgrading an old PHP site safely covers how to make that call, and our headless CMS development team builds replacements that keep PHP off the public front end.

Conclusion

As of 23 October 2026, PHP 7.3, 7.2, 7.1, 7.0 and PHP 5 have no fix or backport from the PHP project. Paid vendors and a few platforms can patch some of these versions, but that only buys time on a stack that is years out of date. If you cannot get a patched build today, take the site offline or isolate it, the way CISA, the NCSC and EU agencies advise, then upgrade or rebuild. If you need help with either, our emergency PHP patching team can work through it with you. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions