End-of-Life PHP on a Magento Server: Find It, Prove Nothing Uses It, Turn It Off

Which PHP versions are end of life right now?

According to php.net, only four PHP branches are supported today. 8.4 and 8.5 get active support. 8.2 and 8.3 get security fixes only. Everything older is end of life:

End of life means no more releases from the PHP project, security fixes included. Your distribution may backport some fixes, but do not assume it.

Also keep one date in mind: php.net lists security support for PHP 8.2 until 31 Dec 2026. That is ten weeks away.

Why php2shell makes old PHP an urgent problem

On 20 October 2026 php.net announced a critical security release for Wednesday 21 October at 14:00 UTC, fixing two vulnerabilities rated CVSS v4.0 9.2. The release came out the same day as PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, with nothing for 8.1 or older. The full story is in my php2shell write-up.

Huntress wrote up the leak as php2shell and lists the CVE IDs as CVE-2026-109618 and CVE-2026-109619. Their reporting points to PHP 5, 7 and 8 being affected, and some researchers expect fixes only for the supported 8.x branches. Their advice for end of life PHP is short: upgrade it, take it off the internet, or put it behind a VPN or WAF until you can.

So plan as if nobody will ship a fix for 7.4 or 8.1. The only question is whether anything needs them. On my server, nothing did.

Why your control panel runs PHP versions nobody asked for

CloudPanel, cPanel and Plesk all let you pick a PHP version per site, and to make that dropdown work they ship many versions side by side. On my Ubuntu 24.04 CloudPanel box, PHP-FPM 7.1, 7.2, 7.3, 7.4, 8.0, 8.1, 8.2, 8.3, 8.4 and 8.5 were all installed and all running. Each old version had one default CloudPanel pool listening on 127.0.0.1, on ports between 11000 and 16000.

My honest opinion: this is a risk nobody looks at. Owners check the PHP their store uses and stop there, while the other services run unpatched and appear on nobody's checklist. Localhost binding lowers exposure, but it is not a fix when the bug class is remote code execution and other sites share the box.

If you want the full inventory first, including CLI binaries and Docker images, read my sister post on how to find every PHP version on your server.

How to disable old PHP versions safely: prove each one is unused

I never switch off a PHP-FPM service on a guess. These are the five checks I ran for each end of life version before I touched anything.

1. List what is running

systemctl list-units --type=service --state=running 'php*-fpm*'
ls /etc/php/

2. Read each pool's listen line

The listen directive tells you how the web server would reach that version: a TCP port or a Unix socket.

grep -RHE '^\s*listen\s*=' /etc/php/*/fpm/pool.d/

3. Grep the web server config for those ports and sockets

Replace the port and version with what step 2 showed you. On CloudPanel the vhosts live under /etc/nginx/sites-enabled/. On Apache based panels, search the Apache config and any .htaccess handler lines too.

PORT=11000   # use the port from the pool listen line
grep -RnE "127\.0\.0\.1:${PORT}|php7\.4-fpm|php/7\.4" /etc/nginx/ 2>/dev/null
grep -RnE "php7\.4|php74|ea-php74" /etc/apache2/ /etc/httpd/ 2>/dev/null

On my server, no nginx config referenced any of the ports used by 7.1 to 8.1.

4. Check live connections

Config can lie. Live traffic does not. Run this a few times, including busy hours.

ss -tnp state established '( sport = :11000 )'
ss -xp | grep -E 'php/?7\.4|php7\.4-fpm'

I had zero established connections on every old pool.

5. Search cron, systemd timers and scripts for the old CLI

FPM is only half of it. A Magento cron line like /usr/bin/php7.4 bin/magento cron:run keeps running even if 7.4 FPM is off, and it is still old PHP.

for u in $(cut -d: -f1 /etc/passwd); do
  crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"
done | grep -E 'php(7\.[0-9]|8\.[01])'
grep -RnE 'php(7\.[0-9]|8\.[01])' /etc/cron* /etc/systemd/system/ 2>/dev/null
systemctl list-timers --all
update-alternatives --display php

Also check the default php each site user gets: if it is still 7.4, every composer install runs on 7.4. No cron entry on my server called the old CLIs.

Turn it off with a one-line rollback

Once all five checks came back empty, I disabled the six end of life services in one go:

systemctl disable --now php7.1-fpm php7.2-fpm php7.3-fpm php7.4-fpm php8.0-fpm php8.1-fpm
systemctl is-active php7.4-fpm php8.1-fpm php8.3-fpm

disable --now stops the service and stops it from starting at boot. Every live site kept answering normally afterwards. The one site that was already in planned maintenance mode stayed exactly as it was. PHP 8.2 to 8.5 kept running and get patched the normal way.

If something breaks, rollback is one command per version:

systemctl enable --now php7.4-fpm

After the next apt upgrade, check systemctl is-enabled again so you know the services stayed off. If you want a harder stop, systemctl mask blocks a unit from being started at all, and systemctl unmask undoes it.

Why I did not run apt purge straight away

Removing packages feels cleaner, but on day one it is the wrong move. A purge deletes the pool files and php.ini changes, so rollback becomes a reinstall and a config rebuild under pressure. Control panels may also expect those versions to exist for their PHP dropdowns. A forgotten monthly job would only fail weeks later.

My plan is simple: leave the packages and CLIs installed but stopped, watch logs and cron output for a few weeks, then remove them in a planned window. Stopped FPM services do not take requests. The CLI binaries still exist, so keep them out of cron and off the default php path in the meantime.

PHP 7.4 end of life on Magento: which PHP does each 2.4 release support?

This table is copied from Adobe's Commerce system requirements page as it reads today. Patch levels inside each line share the same PHP versions.

Read that carefully. Adobe lists only PHP 8.1 for 2.4.4 and 2.4.5, and 8.1 has been end of life on php.net since 31 Dec 2025. Magento 2.3 is not on the page at all, and those stores usually run PHP 7.x. If you are on 2.4.6, you can move from 8.1 to 8.2 inside your current line, but 8.2 itself leaves security support at the end of this year. Moving to 8.3 or 8.4 also means checking your extensions; the PHP 8.4 implicit nullable trap is the one I see break most often.

What if a store really still needs old PHP?

Sometimes the checks find a real user: a Magento 2.3 store on 7.4, or a 2.4.4 store on 8.1. Turning that off takes the store down, so do this instead, in this order:

• Book the upgrade now. The only real fix is a Magento line that Adobe lists for a supported PHP branch.
• Put it behind a WAF or VPN. Put a WAF in front of the public store, and restrict the admin URL by IP or VPN. This follows the Huntress advice for end of life PHP and buys time. It does not fix the bug.
• Isolate it. Move that one store into its own container or its own small server with only the old PHP inside, a separate system user, and no access to the other sites' files or databases. If it gets popped, the damage stays in that box.
• Turn off everything else. Even if one site needs 7.4, the other five old versions probably do not. Disable those today.

And if you suspect an old PHP service was already reachable while the bugs were public, check before you clean up. My other post covers how to check a Magento server for a PHP RCE compromise.

Want a second pair of eyes before you switch anything off, or need an old store isolated and upgraded? I do this as a fixed task at $25/hr. Hire me or message me on WhatsApp.