Blog
End of life 2026: PHP, Node.js and Python at a glance
A runtime without security updates is an open bill: the next vulnerability will not be fixed for it. Here is the state as of October 2026 for PHP, Node.js and Python, and how to find out what really runs in your repos.
Updated · Stackwatch team
Why end of life matters
When a runtime reaches end of life (EOL), it no longer gets security updates. The software keeps running, but every new vulnerability stays open. With PHP2Shell, PHP 7.4 to 8.1 only got source backports, no official release.
PHP
| Version | Status (October 2026) | Security updates until |
|---|---|---|
| 8.5 | active | 31 Dec 2029 |
| 8.4 | active | 31 Dec 2028 |
| 8.3 | security fixes only | 31 Dec 2027 |
| 8.2 | security fixes only | 31 Dec 2026 |
| 8.1 and older | end of life | expired |
PHP 8.2 ends in just over two months. If you are on 8.2 now, plan the move to 8.4 or 8.5. PHP 8.6 is at the release candidate stage.
Node.js
| Version | Status (October 2026) | End of life |
|---|---|---|
| 26 | becomes LTS on 28 Oct 2026 | 30 Apr 2029 |
| 24 | maintenance LTS | 30 Apr 2028 |
| 22 | maintenance LTS | 30 Apr 2027 |
| 20 | end of life | 30 Apr 2026 |
| 18 and older | end of life | expired |
Node.js 20 has not received security updates since April. For production systems, the Node.js project recommends LTS versions.
Python
| Version | Status (October 2026) | End of life |
|---|---|---|
| 3.15 | bugfix | – |
| 3.14 | bugfix | – |
| 3.13 | security fixes only | Oct 2029 |
| 3.12 | security fixes only | Oct 2028 |
| 3.11 | security fixes only | Oct 2027 |
| 3.10 | end of life | 1 Oct 2026 |
| 3.9 and older | end of life | expired |
Python 3.10 has had no security updates since 1 October 2026.
How to find out what runs in your repos
Runtime versions are rarely in one place. Typical locations:
grep -rnE "FROM (php|node|python):" --include=Dockerfile* .
cat .php-version .nvmrc .node-version .python-version .tool-versions 2>/dev/null
grep -rnE "(php|node|python)-version" .github/workflows/Then there are composer.json (require.php), package.json (engines.node), pyproject.toml (requires-python) and infrastructure code. These often describe an allowed range, not the version that actually runs. The most reliable source is the base image or the deployment. Package scanners like Dependabot do not parse Dockerfiles, more in the comparison with Dependabot.
On the running system:
php -v
node -v
python3 --versionWith distributions, the distribution’s support applies
If PHP, Node.js or Python come from Debian, Ubuntu or RHEL repositories, their support period is what counts. Distributions often backport security fixes, even beyond the upstream project’s EOL. The version number alone then says little.
What to do now
- List all runtimes and versions in your repos.
- Flag everything reaching EOL by the end of 2026: PHP 8.2, Node.js 20, Python 3.10.
- Schedule upgrades before the next vulnerability arrives, not after. Stackwatch detects runtime versions automatically from your repos, see how it works.
Sources
Frequently asked questions
What does end of life mean for PHP, Node.js and Python?
The runtime no longer receives security updates. The software keeps running, but every new vulnerability stays open.
Which versions have already expired as of October 2026?
PHP 8.1 and older, Node.js 20 (since 30 April 2026) and older, and Python 3.10 (since 1 October 2026) and older. These versions no longer receive security updates.
How long does PHP 8.2 still receive security updates?
Until 31 December 2026. If you are on 8.2 now, plan the move to 8.4 or 8.5.
How do I find out which runtime version my repos use?
Typical places are Dockerfiles, .php-version, .nvmrc, .node-version, .python-version, .tool-versions, CI configs, composer.json, package.json and pyproject.toml. These often describe only an allowed range. The most reliable source is the base image or the deployment.
Does end of life also apply to PHP from Debian, Ubuntu or RHEL?
In that case the distribution support period counts. Distributions often backport security fixes, even beyond the upstream end of life, so the version number alone says little.
What should I do now?
List all runtimes and versions in your repos, mark everything reaching end of life by the end of 2026 (PHP 8.2, Node.js 20, Python 3.10) and plan the upgrades before the next vulnerability arrives, not after.