PHP End of Life: Which Versions Are Still Supported (October 2026)

PHP 8.2, 8.3, 8.4 and 8.5 are the supported PHP versions on 23 October 2026: 8.4 and 8.5 get bug and security fixes, while 8.2 and 8.3 get security fixes only. These dates come from php.net's supported versions page, its end-of-life list and its release history.

Active support means bugs and security issues both get fixed in regular releases. Security-only means PHP releases a fix when a serious hole turns up, and nothing else. End of life means no releases at all.

For what PHP2Shell is and what to do in the first 24 hours, read my guide to the PHP2Shell vulnerability. This post is about the calendar.

Each PHP version is supported for four years: two years of active support with bug and security fixes, then two years of security fixes only, ending on 31 December. In php.net's words, "Once the four years of support are completed, the branch reaches its end of life and is no longer supported." A new version arrives about once a year, usually in late November.

The 31 December rule is recent. In April 2024 PHP's developers voted, in the "Release cycle update" RFC, to add a year of security support and move end dates to the end of the calendar year. It applied from 8.2 onwards and gave 8.1 an extra year. That's why 8.0 ended on its November anniversary in 2023 while 8.1 ran to 31 December 2025.

For a business website, that works out to one PHP move every two or three years. Move to 8.4 now and you're covered to the end of 2028. If nobody has touched the PHP setting since the site launched, it's almost certainly on an end-of-life version.

The latest PHP version is 8.5.12, released on 21 October 2026, and PHP 8.6 is in release-candidate testing with its full release planned for 19 November 2026. PHP 8.5 first came out on 20 November 2025, and 8.5.12 is the build with the PHP2Shell fixes. The same day brought 8.4.27, 8.3.36 and 8.2.35 for the other supported versions.

The PHP 8.6 release schedule lists 19 November as the planned release date, after a run of release candidates through October and early November. php.net hasn't published 8.6's support dates yet. If it ships on time, the four-year policy points to active support to the end of 2028 and security fixes to the end of 2030. PHP marks every release candidate as not for production use.

Should you jump to the newest PHP version? Not on release day, for a business site. I wait a few point releases and for the software on top to say it's tested. WordPress 7.0 and 7.1 already support 8.5; WooCommerce's server recommendations say it's tested up to 8.4. On wordpress.org's count, about 4% of WordPress sites run 8.5 so far.

PHP end of life means the PHP project releases no more fixes for that version, so when a new security hole is found, sites running it stay exposed unless someone else patches it. Nothing happens on the day. The site keeps working, and your host may still list the version in its dropdown. The risk just waits for the next flaw, and this month the next flaw arrived.

Here's how PHP2Shell played out, from PHP's advisory of 21 October:

• 8.2 to 8.5: fixed releases the same day.
• 7.4, 8.0 and 8.1: no release. Because the flaws are so severe, PHP's security team published "minimal source-backports" for people who compile PHP themselves or have no long-term support vendor. A business on shared hosting can't do anything with those.
• 7.3 and older: nothing from PHP at all, although Tenable's FAQ reports the earliest affected code path found goes back to PHP 5.4.0.

On 21 October the US Cybersecurity and Infrastructure Security Agency (CISA) went further. Its alert says that if you can't patch, or you run 8.1 or older, take PHP systems offline until they're patched. That's US guidance. Singapore's Cyber Security Agency issued its own alert on 21 October, and its advice is to patch immediately.

This is a big group. wordpress.org's statistics on 23 October put about 16% of WordPress sites on PHP 7.4, 10% on 8.1, 4% on 8.0 and 6% on something older. Roughly 36% in all. If you don't know where your site sits, my guide to checking your website's PHP version takes two minutes.

PHP 8.2 reaches end of life on 31 December 2026, after which the PHP project releases no more security fixes for it, so any flaw found from January 2027 stays open on 8.2 sites. There may be another 8.2 release before then if something serious turns up; php.net says security releases come "on an as-needed basis". About 24% of WordPress sites run 8.2, the second-largest group after 8.3.

If you're on 8.2, you got the PHP2Shell fix this time, once your host installs 8.2.35. Use the 69 days to move to 8.4 calmly, rather than in January in a hurry because the next flaw landed. For WordPress sites, the careful process is in my guide to updating your PHP version in WordPress without breaking it.

Some hosts do patch old PHP versions, through vendors that backport security fixes to versions PHP has abandoned, but whether yours does depends on the software it runs, so you have to ask. This is what each vendor had said or shipped for PHP2Shell by 23 October, from its own pages:

Three things to know before you lean on a backport:

• The version number won't tell you. A backported build keeps its old number. Ubuntu 22.04's fixed PHP still reports 8.1.2, and CloudLinux says its patched packages keep lower numbers too, such as alt-php85 8.5.11-5. Ask the host for the package and the date, in writing.
• It only covers PHP. Your CMS and plugins keep moving. WooCommerce 11.6 will need PHP 8.1 or newer from February 2027, per its developer blog, so a patched 7.4 still leaves a store stuck on old WooCommerce.
• Somebody pays for it. On cPanel, the host buys TuxCare's extended support and moves your account from ea-php74 to alt-php74, per cPanel's documentation. If the licence lapses, the old PHP keeps running and the patches stop.

As for named hosts, SiteGround says it patched every server on 21 October and customers need do nothing, though its notice covers "all supported PHP versions" and doesn't mention 7.4, 8.0 or 8.1. What the other hosts Singapore businesses use have said, with the click-paths, is in my guide to changing the PHP version in cPanel and other hosts.

One more thing sources disagree on. Red Hat rates the flaw "Important", a CVSS 3.1 score of 8.1, and notes that standard RHEL setups run PHP-FPM rather than mod_php, the setup PHP rates as riskiest. CISA cites CVSS 4.0 scores of 9.2. Neither changes the advice: update.

Move to PHP 8.4 today if your software supports it, because 8.4.27 carries the PHP2Shell fixes and 8.4 gets security fixes until 31 December 2028; choose 8.3 if a plugin isn't ready for 8.4. How I'd weigh each version:

• 8.4: full support to the end of 2026, security fixes to the end of 2028. WordPress supports it and WooCommerce is tested on it. The sensible default.
• 8.3: WordPress's recommended minimum, with security fixes to the end of 2027. Fine if one plugin chokes on 8.4.
• 8.5: the latest, supported to 2029. Good for a new build or a simple site whose plugins list it. I'd hold off on a shop until WooCommerce does.
• 8.2: don't move to it. You'd be doing this again in 69 days.
• 8.6: not until it's released and your plugins have caught up.

Whichever you choose, the third number matters as much as the first two. On php.net's numbering, 8.4.26 is exposed to PHP2Shell and 8.4.27 isn't. If your host backports, go by its written answer instead.

If your site can't move past PHP 8.1 without major surgery, a backport only buys time, and a rebuild that doesn't run PHP at all is often the cheaper fix over a few years. The signs: a page builder or theme abandoned years ago, plugins that fail on PHP 8 with no updates coming, nobody who knows how the site was put together, and content that's mostly text and photos changed a few times a year.

A statically built site, which is how I build with Astro, turns your pages into plain files when you publish and serves them from a CDN. No PHP runs when someone loads a page, so a PHP flaw has nothing to reach, and there's no PHP version to keep current. terris.sg works that way. So does MET Interior's 176-page site, which I moved off WordPress and its page builder onto Astro, with 75 filterable project pages and the old URLs mapped across.

A static site still has a domain registrar, DNS, a hosting account, form handlers and third-party scripts to protect. And for memberships, heavy daily editing or a large WooCommerce store, a well-maintained WordPress on PHP 8.4 is probably the right call. Patching is the right answer more often than not.

Either way, start with my free PHP check. Send me your web address and I'll check which PHP version it runs, what it's built on and how old its theme and plugins are, and tell you what I find. If your host has already patched it for free, I'll say so, and you don't need me.

If it needs the update, you get a fixed price in writing before I start, covering the PHP update and anything it breaks, from SGD 850, and the content retainer at SGD 550 a month keeps it current after that (both on my website maintenance page). Next to the fix I'll quote a rebuild without PHP, so you can compare: Starter from SGD 2,535 for up to 10 pages, the One Week Website at SGD 3,545, or Growth from SGD 7,585 with a CMS you edit yourself. My guide to migrating WordPress to a static site covers the route and the timeline.

PHP 7.4 reached end of life on 28 November 2022, and its final release was 7.4.33 on 3 November 2022. It got no official PHP2Shell release in October 2026, only a source-code backport for people who build PHP themselves. Even so, about 16% of WordPress sites still ran 7.4 on 23 October 2026, and it's still the oldest version WordPress accepts.

PHP 8.1 reached end of life on 31 December 2025, and 8.1.34, released on 18 December 2025, was its last official release. PHP2Shell was fixed ten months later, so 8.1 got no release from PHP. Ubuntu 22.04 users got a fixed 8.1 package from Ubuntu, and hosts running CloudLinux's alt-php could install a fixed 8.1 build.

Running an end-of-life PHP version on a public website isn't safe, because the next serious flaw in PHP won't be fixed for it unless your host gets a backported fix from a vendor. PHP2Shell is the proof: every version from 8.1 down missed the official fix. If your host does backport, get that in writing, and use the time to move to 8.4.

WordPress still works on PHP 7.4: WordPress 7.0 made 7.4 its minimum when it dropped PHP 7.2 and 7.3, though WordPress recommends 8.3 or newer. WordPress's own code already flags anything below 8.0 as soon to be unsupported and shows a "PHP Update Required" box on the dashboard. WooCommerce goes further, needing PHP 8.1 from version 11.6 in February 2027.