Support Library

End-of-Life and Outdated Website Software

Software projects support each release line for a fixed time. After its end-of-life date, newly found security flaws in that line are never fixed, so a site that still runs it collects unpatchable vulnerabilities month by month. A supported line that has fallen behind its latest patch release is a smaller version of the same problem.

Author
CategoryWebsite Security
Length5 minute read
UpdatedNovember 1, 2026

The short answer

End of life: plan and test a move to a supported release line, for example PHP 7.4 to a current PHP 8 release. Updates within the old line cannot help. Outdated: install the latest patch release of the line you already run, which is usually a low-risk update.

What happens after end of life

How a release line past its end-of-life date stays vulnerable, and how a supported line gets fixed Top, end of life: the site runs PHP 7.4, whose security support ended in November 2022. A new flaw is found, and no fix will ever be released for 7.4, so the site stays exposed. Bottom, supported: the site runs a supported PHP 8 release. When a new flaw is found, a fixed release follows and the team installs it. Release line ended Site runs PHP/7.4.33 Support ended November 2022 New flaw found Affects 7.4 too No fix, ever Exposed until upgraded Flaws pile up over time Often blocks other updates too Supported release line Site runs A supported PHP 8 line Still supported Security fixes ship New flaw found Reported and fixed Patch installed Routine update Every new flaw gets a fix Upgrades stay small How a release line past its end-of-life date stays vulnerable, and how a supported line gets fixed Top, end of life: the site runs PHP 7.4, whose security support ended in November 2022. A new flaw is found, and no fix will ever be released for 7.4, so the site stays exposed. Bottom, supported: the site runs a supported PHP 8 release. When a new flaw is found, a fixed release follows and the team installs it. Release line ended Site runs PHP/7.4.33 Support ended November 2022 New flaw found Affects 7.4 too No fix, ever Exposed until upgraded Flaws pile up over time Often blocks other updates too Supported release line Site runs A supported PHP 8 line Still supported Security fixes ship New flaw found Reported and fixed Patch installed Routine update Every new flaw gets a fix Upgrades stay small
End of life is a date, not a version number. endoflife.date lists the dates for each product and release line.

How DNS Panopticon detects it

Security Posture takes each version your homepage reveals (from the Server and X-Powered-By headers and Website Recon’s technology detection) and looks up its release line on endoflife.date. Apache, nginx, Tomcat, OpenSSL, PHP, WordPress, Drupal, Joomla and jQuery are checked. IIS is not, because its support follows Windows Server, which the Endpoint Security card grades. The result appears on the Vulnerability Management card.

FindingSeverityWhen it appears
… X is no longer supportedHighThe release line is past its end-of-security-support date. The finding gives the date.
… isn’t the latest X releaseLowThe line is supported, but a newer patch release of it is out. Not raised for Linux distribution builds, which follow their own patch numbering.
… X is supportedPassThe line still gets security fixes and no CVEs were found for the version.

Some Linux distributions keep patching their own builds of an upstream line after upstream support ends, under extended or paid plans. If yours does, the finding still appears because the upstream line has ended; check your distribution’s lifecycle page.

How to check it yourself

Command or sourceWhat it tells you
curl -sI https://example.comThe product versions your site reveals.
php -vThe installed PHP version (similarly apachectl -v, nginx -v, openssl version).
curl -s https://endoflife.date/api/v1/products/php/Every PHP release line with its end-of-life date, as JSON. Replace php with the product name.

Vendors publish their own schedules too, for example PHP’s supported versions, OpenSSL’s release strategy and WordPress releases.

Why it matters

  • Unpatchable flaws. Researchers keep finding bugs in old code. After end of life they are published but never fixed, and old lines often share code with new ones, so a fix in the new line shows attackers where to look in the old one.
  • Everything around it ages too. An unsupported runtime blocks updates to plugins, libraries and frameworks that need a newer version, so more of the stack falls behind.
  • Compliance. Standards such as PCI DSS require security patches to be installed, which unsupported software cannot receive.
  • Outdated is cheap to fix. A patch release within a supported line changes little and carries the fixes the finding is about.

How to fix it

  1. Outdated, supported line: install the latest patch release through your package manager, hosting control panel or the application’s updater, then restart the service.
  2. End of life: pick the target. Choose a release line with the longest remaining support that your application supports, often the newest stable one.
  3. Check compatibility. Read the upgrade notes (for example PHP’s migration guides), update plugins, themes and libraries first, and test on a copy of the site.
  4. Switch and verify. Change the runtime or server version, watch error logs, then scan again with DNS Panopticon.
  5. If you cannot move yet, use your distribution’s or vendor’s extended support if it covers the package, put a web application firewall in front, and set a firm date for the upgrade.
  6. Track dates ahead. Note when your current lines end and plan upgrades months before, not after.
SoftwareWhere to change the version
PHP on shared hostingHosting control panel, often “PHP version” or “MultiPHP Manager”
PHP on your own serverInstall the new php-fpm package, point the web server at it, then remove the old one
WordPress, Drupal, JoomlaAdmin dashboard updater or CLI (wp core update, drush, joomla update)
Apache, nginx, OpenSSLOperating system packages; moving to a newer OS release is often the cleanest route
jQueryReplace the file or CDN link with a current release and test, with jQuery Migrate if needed

FAQ

My host says they still patch PHP 7.4. Is that enough?

Some hosts and distributions offer extended support for old lines. If yours genuinely ships security fixes, the risk is lower, but plugins and applications are dropping support for old runtimes, so plan the move anyway. The finding stays because the upstream line has ended.

What is the difference between end of life and end of active support?

Many projects stop adding features or general bug fixes first (end of active support) and keep shipping security fixes for a while longer. DNS Panopticon uses the end of security support, because that is when the risk starts.

Why is “outdated” only low severity?

The line is still supported, so a fix is a routine update away. It matters most when the newer patch fixes a CVE, which the Known Vulnerabilities finding reports separately.

Sources and further reading

Related support articles

Known Vulnerabilities (CVEs) in Website SoftwareEnd-of-Life Server Operating SystemsServer Version DisclosureWebsite Recon technical details