PHP 8.2 has eight weeks of security updates left

On 21 October, the PHP project fixed two critical vulnerabilities that allow remote code execution without authentication. They became known as php2shell. The fixes shipped as PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anyone running PHP 8.1 or older got none of these releases.

PHP 8.2 now has exactly that situation in its calendar: after 31 December 2026, the PHP project no longer provides security fixes for it.

What older versions got in October

The PHP project's advisory is unambiguous: "PHP 8.1 and older no longer receive updates from the PHP project." Given the severity, there was one exception: minimal source backports for PHP 7.4, 8.0 and 8.1, intended for anyone building PHP from source or without a long-term support vendor.

That is not a finished package and no promise for the next vulnerability. Most operators of older versions had two options: wait for their distribution, if it still maintains that version, or upgrade under time pressure.

The next date is fixed

According to the list of supported versions on php.net, security support for PHP 8.2 ends on 31 December 2026. For PHP 8.3 it ends on 31 December 2027, for 8.4 at the end of 2028, for 8.5 at the end of 2029. From 1 January, PHP 8.2 will be where PHP 8.1 was in October when the next vulnerability comes.

End of support is a date, not an event. Plan for it and you upgrade with testing. Notice it at the next vulnerability and you do the same upgrade at night, without testing.

Where PHP runs

PHP is not only in the website. It runs the intranet, the ticket system, the wiki, Nextcloud, monitoring interfaces and business applications that a vendor ships together with their runtime. Four questions settle what needs to happen by the end of the year:

• First the list. Which systems run PHP, and which version? The outside view is not enough: many servers do not reveal their version, and rightly so.
• Then the origin. Does PHP come from the distribution's package, a third-party repository, a container image or the application vendor? Distributions maintain their packages on their own schedule, sometimes longer than the PHP project. Whether that applies to a given system is stated by the distributor, not on php.net.
• Then the vendor. For business applications, the manufacturer decides which PHP version is supported. The question needs asking now, not in January.
• And the schedule. An upgrade needs testing in an environment that resembles production. Eight weeks including holidays is not a lot.

How isidaten handles this

isidaten keeps a shared catalogue of vendor end-of-support dates for software and operating systems, based on endoflife.date. During scans, the Attack Surface Management module reads, among other things, the Server and X-Powered-By headers to see which PHP version a web server reports, and checks it against the catalogue. If support ends in less than 90 days, it shows "support ending soon"; without vendor support, the module creates a finding. If the header points to a Linux distribution package, isidaten does not assess it against the PHP project's schedule but marks it as a distribution package, since anything else would be a false alarm.

For servers whose headers reveal nothing, the shadow IT module checks the installed software from the device inventory against the same catalogue.

The test question

How many of your systems will run PHP 8.2 or older on 1 January 2027, and who has decided, for each one, what happens before then?

If you only look for the answer at the next vulnerability, there is no time left for a planned upgrade.

Sources

PHP project: security advisory of 21 October 2026, retrieved 1 November 2026.

PHP project: Supported Versions, retrieved 1 November 2026.

endoflife.date: PHP.