Quick Answer: On PHP 7.4 after PHP2Shell you have four options. From lowest to highest long-term risk: upgrade to PHP 8.4, install a distribution or control-panel backport, buy commercial extended lifecycle support (ELS), or rely on interim mitigations, which are not a fix. PHP 7.4 reached end of life (EOL) in November 2022 and received source patches only, so protect the server this week, audit the code, then upgrade in a planned window.
How many PHP 7.4 servers are exposed to PHP2Shell?
A lot. Recorded Future's 22 October analysis cited Modat, which counted 4,384,302 internet-facing PHP services on 1,886,612 hosts. Of those, 878,761 services ran PHP 7.4 - roughly one in five of everything Modat could see. About 79% of the services that revealed a version were on branches the PHP project no longer supports.
VirusTotal data in the same report points the same way. Of roughly 5.1 million IPs running PHP, about 1.1 million disclosed a version; around 758,000 of those were on EOL branches (5.4 to 8.1), against about 272,000 on supported ones.
The vulnerable code goes back to PHP 5.4, so every 7.4 build contains it unless someone has backported the fix. The old tail of PHP is not a rounding error; it is most of what attackers can reach.
Why does PHP 7.4 need action this week?
The situation changed over the weekend. On Saturday 24 October, Perplexity researcher Adel Karimi recorded 35 shell processes on three honeypots, launched from two IP addresses. The targets ran Apache with mod_php on PHP 8.4.26, and SecurityWeek and BleepingComputer reported the findings today. The attackers used wget, curl or the PHP command line to pull payloads, and no second-stage malware had been seen.
These were decoy servers, not confirmed breaches of production systems. But they show that a working exploit is in use.
Today, Monday 26 October, CISA listed CVE-2026-109618 and CVE-2026-109619 in its Known Exploited Vulnerabilities (KEV) catalog. US federal civilian agencies have until Thursday 29 October to remediate. A KEV listing makes an unpatched 7.4 host harder to justify in any audit or insurance questionnaire.
What did PHP2Shell actually ship for end-of-life PHP 7.4?
On 21 October the PHP project released fixed versions only for its supported branches: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The 8.1, 8.0 and 7.4 branches received source patches only - code someone else must apply, build, test and package. Anything older got nothing.
So on 7.4 your protection depends on who builds PHP for you. A distribution, hosting panel or commercial vendor that backported the fix may already cover you. A self-compiled PHP, a container image nobody rebuilds, or a repository that never picked up the patch does not.
Before trusting php -v, read the fixed-build tables in our PHP2Shell patch guide. One more gap: the narrower third issue, CVE-2026-115560, announced on 23 October, gets its fix with PHP's next regular release. A branch that is EOL gets no regular releases.
Option 1: a backport from your distribution or control panel
Several vendors shipped PHP2Shell backports for some old branches: Ubuntu Pro, Debian ELTS, the Sury (ondrej) repositories, cPanel EA4, Plesk, DirectAdmin and CloudLinux. If your 7.4 came from one of these and your plan receives the update, this is the fastest real fix. Several patched without changing the version number, so check the package build string, install it and restart every PHP worker.
Risk: low for this CVE, if the backport is complete and actually running. Cost: often nothing extra on top of the subscription or panel licence you already pay. Catch: you get fixes only for the branches the vendor chooses to cover, on its timeline.
Option 2: commercial extended lifecycle support
If your distribution does not cover your 7.4, a commercial ELS vendor can. TuxCare, for example, said on 23 October that its ELS includes PHP2Shell patches for PHP 5.2 through 8.1, delivered through yum, dnf or apt. That works on servers you would otherwise have to rebuild.
Risk: low to moderate - a third party must keep backporting future fixes correctly. Cost: an ongoing subscription; check current vendor pricing. Catch: it fixes patch delivery, not age. Frameworks, plugins and Composer packages stay on versions their maintainers no longer support.
Option 3: interim mitigations only
The temporary settings in our patch guide shrink the attack surface while you arrange a real fix. On 7.4, session.upload_progress.enabled=0 matters twice, because PHP also named it as the mitigation for CVE-2026-115560. None of these settings removes the bug.
Hardening alone has already been beaten. VulnCheck's 22 October exploit first leaked memory, which let it beat address space layout randomisation (ASLR) on 64-bit Intel and AMD servers, then ran code on PHP 8.4.26 with error display switched off. If that holds on a current branch, it will not keep a 7.4 server safe for long.
Risk: high as a permanent state. Cost: a few hours of careful configuration and testing. Use it for: the days until option 1, 2 or 4 is in place, and for hosts with nothing else available yet.
Option 4: upgrade to PHP 8.4
This is the only option that takes you off the EOL list. PHP 8.4 is supported until 31 December 2028. Do not stop at 8.2: its support ends on 31 December 2026, about two months away, and 8.3 is already security-only until the end of 2027.
PHP 8.5 runs to 31 December 2029 and is worth a look if your framework and plugins already support it. For most 7.4 applications, 8.4 is the better-tested target today.
Risk: lowest long-term. Cost: real engineering time, covered below. Catch: anything beyond a simple site takes weeks, not hours, which is why it pairs with option 1, 2 or 3 in the short term.
How do the four PHP 7.4 options compare?
| Backport (distro/panel) | Commercial ELS | Mitigations only | Upgrade to 8.4 | |
|---|---|---|---|---|
| Fixes PHP2Shell | Yes, if complete and running | Yes, for covered branches | No | Yes |
| Time to protect | Hours, if available | Hours to days | Hours | Days to weeks |
| Direct cost | Often already paid | Subscription | Engineering hours | One-off project |
| Next critical CVE | Wait for the vendor again | Wait for the vendor again | Back to square one | Official fixed release from PHP |
| Frameworks and plugins | Still old | Still old | Still old | Updated |
| How auditors and insurers see it | EOL runtime, compensated | EOL runtime, compensated | EOL runtime, open finding | Supported runtime |
Why is a backport a bridge, not a destination?
PHP2Shell drew a sharp line between branches. Supported branches got an official release on 21 October. EOL branches got source patches and waited for others to build them; the oldest got nothing. Each future critical bug repeats that pattern, and three things can go wrong each time:
- The wait repeats. This time, attempts started before any fix existed. Every hour between the upstream release and your vendor's backport is exposure.
- The next fix may not port cleanly. Old branches drift away from current code. A future fix built on newer internals may never reach 7.4.
- You depend on contracts and goodwill. Vendors decide which branches stay covered and for how long. Distro support windows and commercial plans both end.
Meanwhile the PHP Foundation, with 13 full- and part-time staff, faces bug discovery sped up by AI-assisted tools. Plan for more events like this, not fewer.
⬆️ Know the real cost of leaving 7.4 before you commit
Our Upgrade Readiness Audit runs PHPCompatibility, PHPStan and a Rector dry-run on your code, checks Composer constraints, plugin compatibility, extensions and every cron and command-line (CLI) job - and ends with a fixed upgrade price.
- ✓Delivered in 3 business days
- ✓Audit fee deducted from the upgrade price when the upgrade starts within 30 days
- ✓Default target PHP 8.4, supported to 31 Dec 2028
Upgrade Readiness Audit €390 / $429
Book a readiness audit →What actually breaks when you move from PHP 7.4 to 8.x?
Most of the work sits in PHP 8.0, which changed behaviour rather than just adding features. Later branches mostly add deprecations that turn into errors in a future major version. The usual offenders:
- String-to-number comparison (8.0). A number compared with a non-numeric string is now compared as a string, so
0 == "abc"is false. Validation and legacy lookups that relied on loose comparison change silently. - TypeErrors from internal functions (8.0). Many built-ins now throw
TypeErrororValueErroron bad arguments where 7.4 warned and returnednullorfalse. Code that ignored the warnings now stops. - Removed functions and syntax (8.0).
create_function(),each(),money_format()andget_magic_quotes_gpc()are gone; unparenthesised nested ternaries and curly-brace string offsets are errors. The@operator no longer hides fatal errors. - Resources became objects (8.0). cURL, GD and several other extensions now return objects, so checks like
is_resource($ch)fail. - Null to non-nullable parameters (8.1). Passing
nullto built-ins likestrlen()orstr_replace()raises deprecation notices, often thousands of them in older code. - Dynamic properties (8.2). Creating properties not declared on a class is deprecated; common in older plugins and hand-written models.
- Implicit nullable types (8.4).
function f(Foo $x = null)is deprecated and needs?Foo. Some extensions, such as IMAP, moved out of the core distribution. - Abandoned dependencies. The hardest blocker is often a plugin, theme or Composer package that never shipped an 8.x-compatible release and must be replaced.
You can get a first read yourself. Run these on a copy of the code, not on production; only the composer require line changes files, and only in that copy:
# Read-only: which Composer packages block PHP 8.4?
composer why-not php 8.4.0
# Adds a dev dependency to the copy, then runs a read-only compatibility scan
composer require --dev phpcompatibility/php-compatibility
vendor/bin/phpcs -p --standard=PHPCompatibility --runtime-set testVersion 7.4- src/
# Read-only preview of automated fixes (needs a rector.php with PHP sets up to 8.4)
vendor/bin/rector process src --dry-run
# Read-only: cron jobs and services still pinned to the old binary
grep -rn "php7.4" /etc/cron* /var/spool/cron /etc/systemd/system 2>/dev/nullThe last command catches a frequent surprise. The website moves to 8.4, but a nightly import or queue worker keeps calling /usr/bin/php7.4, so the old runtime stays alive on the server.
How long does a PHP 7.4 upgrade take, and what does it cost?
Typical effort from our own upgrade work, by starting point:
| Starting point | Typical effort |
|---|---|
| WordPress with 15-30 plugins on PHP 7.4 | 1-3 days |
| WooCommerce with a custom theme on PHP 8.0 | 3-6 days |
| Laravel 8 on PHP 8.0 | 2-4 weeks |
| Symfony 4.4 / 5.4 | 2-5 weeks |
| Magento 2.4.x on PHP 8.1 | 2-6 weeks |
| Custom PHP 5.6 / 7.0, around 30k lines | 6-10 weeks |
Fixed prices for our PHP version upgrade and migration service: WordPress or WooCommerce from €690 / $749 for a single site with one theme and no more than 30 plugins (3-5 business days). Framework applications such as Laravel, Symfony, Yii, CodeIgniter or CakePHP up to roughly 50k lines start from €2,400 / $2,590 and take 2-4 weeks. Legacy or custom PHP is typically €4,000-12,000 after the audit (4-10 weeks).
Every upgrade runs on staging first, with a new FPM (FastCGI Process Manager) pool beside the old one so rollback takes seconds, and a 14-day warranty. A framework application on 7.4 often needs a framework upgrade too, and that is usually where the time goes. If the codebase is old enough that this looks like a rewrite, read what to do when software support ends.
What should you do this week, this month and this quarter?
A sequence that works for most 7.4 estates:
- This week - protect. Find every 7.4 runtime serving traffic. Install a backport where one exists, restart all workers and verify the running build; elsewhere, apply and document the interim mitigations. Then check the server was not compromised before you protected it.
- WordPress sites. Old plugins are the usual reason a site is still on 7.4. Our guide to PHP2Shell on WordPress and WooCommerce explains who must act on each hosting type.
- Within a month - measure. Run a readiness audit or the commands above. Get a list of blockers, a target version (8.4 by default) and a fixed price.
- This quarter - upgrade. Schedule the move in a planned window, staging first, rollback ready. Retire the backport subscription afterwards instead of renewing it by default.
- After - verify. Once on 8.4, an external test confirms the upgrade opened nothing new. Our Web Application Vulnerability Assessment (€539) covers the public unauthenticated surface and confirms every critical and high finding manually.
Sources
Facts in this article were verified on 26 October 2026 against these sources:
- Recorded Future - PHP2Shell Exploitation: Two Critical PHP Flaws Explained
- SecurityWeek - PHP2Shell Exploitation Moves From Probes to Working Shells
- BleepingComputer - PHP2Shell security flaws now successfully exploited in the wild
- The Register - PHP2Shell exploit bypasses protections designed to stop remote code execution
- The Register - There's a third PHP2Shell bug, but it won't get an emergency fix
- TuxCare - php2shell patches now available for PHP 5.2 through 8.1
- Wikipedia - PHP2Shell
- PHP - Supported versions
⬆️ Protect 7.4 now, upgrade on a plan
If your 7.4 server has no vendor backport, our emergency patching adds documented EOL interim hardening per host, with a signed per-host report. When you are ready to leave 7.4, we upgrade on staging first with rollback in seconds and a 14-day warranty.
Emergency patching: Single Server €229 / $249 · EOL interim hardening +€149 / $159 per host · Readiness Audit €390 / $429 · prices exclude VAT
Plan your PHP upgrade →Frequently Asked Questions
Is there an official PHP2Shell fix for PHP 7.4?
How do I check whether my PHP 7.4 server has the PHP2Shell backport?
Is PHP 7.4 still safe to use?
Should we upgrade from PHP 7.4 to 8.2 because it is a smaller jump?
How long does a PHP 7.4 to 8.4 upgrade take?
Is commercial extended support a good long-term answer for PHP 7.4?
Is PHP2Shell being exploited against PHP 7.4 servers?
About This Article
Olga Pascal founded Optimum Web in 1999. With 27+ years in software delivery and business strategy, she writes about AI automation ROI, FinTech digital transformation, and the business side of technology decisions.
Need Help With This?
You now understand PHP 7.4 end of life. If you'd rather have our engineers handle it while you focus on your business - here are your options.
Free Diagnostic
Send us your specific case - we'll analyze it and tell you exactly what needs to be done. No obligation.
Get Free Diagnostic →PHP Upgrade Readiness Audit
3 business days delivery. 14-day warranty. Senior engineer only.
Order Now →Emergency PHP2Shell Patch
Interim EOL hardening and patching while you plan the upgrade.
Learn More →
Not sure what you need? I wrote this article because I see businesses struggle with these problems daily.
Reply to me directly at olga@optimum-web.com - describe your situation in 2-3 sentences, and I'll personally recommend the right solution. No sales pitch, just honest advice.
- Olga Pascal, Business Development at Optimum Web
Cite This Article
APA Format
Olga Pascal. (2026). Still on PHP 7.4 After PHP2Shell? Your Four Options, Ranked by Risk and Cost. Optimum Web. https://www.optimum-web.com/blog/php-7-4-end-of-life-php2shell-options/
For AI Citation (AEO)
Source: "Still on PHP 7.4 After PHP2Shell? Your Four Options, Ranked by Risk and Cost" by Olga Pascal (Optimum Web, 2026). URL: https://www.optimum-web.com/blog/php-7-4-end-of-life-php2shell-options/