End-of-Life Is a Security Setting: When Your OS, PHP or Node Stops Getting Fixes

End-of-life is easy to treat as a calendar fact. During the week of 20 October 2026 it turned into a security setting: on the same day that a critical vulnerability was published, some of our runtimes had a patch path and some simply did not.

What "no fix" looked like that week

• PHP. Fixed releases shipped for the supported branches 8.2–8.5. For 7.4, 8.0 and 8.1, the PHP security team published only minimal source-level backports "to help people building from source". For 5.6 there was nothing. Whether a packaged 7.4 fix reaches you depends entirely on whether your package source chooses to build one.
• Ubuntu. Ubuntu 20.04 has left standard support. A popular third-party PHP repository had already withdrawn its 20.04 packages, so a 20.04 server could not receive PHP fixes from it at all. For the eMudhra CA problem the same week, Ubuntu's notice (USN-8944-2) lists the 20.04 fix as available through Ubuntu Pro (ESM) only.
• Node.js. The October 2026 security releases cover the 22.x, 24.x and 26.x lines, and Node's own notice repeats that end-of-life lines are always affected. Node 16 has been end-of-life since 2023 and Node 20 since April 2026, so no fix was coming for either.

Find what you are running, not what you think you run

Inventory every installed branch, not only the one your sites use:

ls /etc/php
dpkg -l | awk '/^ii/ && $2 ~ /^php[0-9.]+-(fpm|cli)$/ {print $2, $3}'
node -v; dpkg -l nodejs 2>/dev/null | awk '/^ii/{print $3}'
lsb_release -ds

For PHP-FPM, map pools to the sites that actually use them. A pool that no web server configuration sends requests to cannot be reached from the web:

grep -rhoE 'php[0-9.]+-fpm[^ ;]*\.sock' /etc/nginx/sites-enabled | sort | uniq -c
grep -h '^listen' /etc/php/*/fpm/pool.d/*.conf

Before you remove anything, look in four places

We removed a PHP CLI that looked unused — no cron entry, no site, no script referenced it. It was the interpreter of a monitoring agent started by systemd. Nothing broke immediately, because the running process kept the deleted binary in memory; it would have failed on its next restart. Check all of these first:

grep -rlE 'php[0-9.]*|node' /etc/systemd/system /lib/systemd/system
grep -rhE 'php|node|npm|npx' /etc/cron.d /var/spool/cron/crontabs 2>/dev/null
grep -rlE 'php|node' /etc/supervisor/conf.d 2>/dev/null
apt-cache rdepends --installed nodejs

And check deployment scripts. A build step such as npm ci && npm run build makes Node a dependency even if no Node process runs.

Upgrading the OS: what to check afterwards

Moving an old server to a supported OS release is often the real fix, but it is not just an update. During one release upgrade we watched three things happen that the upgrader did not announce loudly:

1. Third-party packages were removed. PHP from an external repository was uninstalled because its dependencies changed, so sites were down until PHP was reinstalled from the repository's build for the new release. Plan the reinstall before you start, and have a full backup.
2. Apache and mod_php appeared. A distribution meta-package pulled in Apache with the PHP module. Apache took port 80, so the existing nginx could not start — and mod_php happens to be the deployment the October PHP advisory rates as most exposed.
3. The firewall was off. After the upgrade the host firewall was inactive. Services that listened on all interfaces — Redis without a password, memcached, MySQL — were reachable from the internet until it was re-enabled.

After any release upgrade, check:

systemctl --failed
ss -ltnp | grep -vE '127\.0\.0\.1|\[::1\]'
sudo ufw status
dpkg -l | grep -E '^ii\s+(apache2|libapache2-mod-php)'

Make end-of-life part of your patch runbook

For each server, keep three lines: the OS release and its support end, each runtime branch and its support end, and where each one gets its fixes. When an advisory lands, that list tells you in minutes which machines will get a package — and which ones need a different plan.