PHP End of Life Dates for 7.4, 8.1 and 8.2, and What to Do

Key takeaways

• PHP 7.4, 8.0 and 8.1 are unsupported on 22 October 2026. php.net lists their end of life dates as 28 November 2022, 26 November 2023 and 31 December 2025.
• PHP 8.2 is still supported, but not for long. Its security support ends on 31 December 2026, about ten weeks from today.
• PHP 8.3, 8.4 and 8.5 are supported. 8.4 is still in active support to 31 December 2026 and 8.5 to 31 December 2027.
• End of life means no more fixes from the PHP project. The October 2026 critical flaws were fixed in 8.5.12 on 8.5, 8.4.27 on 8.4, 8.3.36 on 8.3 and 8.2.35 on 8.2, and nothing official for 8.1 and older.
• php.net made a small exception. It published minimal source backports for 7.4, 8.0 and 8.1, meant for people who build from source. They are not a plan for a normal site.
• The cure is the same for everyone. Move to a supported branch at your host, test first, and ask the host to confirm in writing.

What do the support dates mean?

php.net explains the system in two steps. Each branch is fully supported for two years from its first stable release, and during that time reported bugs and security issues are fixed in regular point releases. This is called active support. After that, each branch gets two more years of critical security fixes only, released as needed, and that is called security support.

When the security period ends, the branch is end of life, or EOL. The PHP project stops releasing fixes for it.

Every PHP branch from 7.4 to 8.5

The table below uses the dates as listed by php.net wherever it lists them. One note on sources: the php.net supported versions page, read on 22 October 2026, lists only 8.2 to 8.5. For 7.4, 8.0 and 8.1, php.net's end of life page gives the end date, and the release and active support dates come from endoflife.date, which we also read today. Both sources agree on the security end dates.

So by those dates, three branches are unsupported today: 7.4, 8.0 and 8.1. Kinsta's guide, updated on 8 June 2026 and citing endoflife.date, shows the same picture.

PHP 7.4 end of life

PHP 7.4 was released on 28 November 2019. Its security support ended on 28 November 2022, and the last release was 7.4.33. That is nearly four years ago.

PHP 7.4 matters for WordPress because WordPress.org says WordPress still works with PHP as far back as 7.4. That is a statement about compatibility, not safety. A site can run perfectly well on a branch that the PHP project no longer fixes.

PHP 8.1 end of life

PHP 8.1 reached the end of its security support on 31 December 2025, per php.net, and its last release was 8.1.34. If you searched for "PHP 8.1 end of life", this is the date: it passed about ten months ago.

PHP 8.0 is in the same position, with its end date on 26 November 2023.

PHP 8.2 end of life

PHP 8.2 is the one to plan for. It was released on 8 December 2022, active support ended on 31 December 2024, and security support runs to 31 December 2026. After that it is end of life too.

It received the October 2026 fix, in version 8.2.35, so an up to date 8.2 is covered today. The catch is the calendar. If you stay on 8.2, you will need to move again within about ten weeks, so it makes sense to jump to 8.3 or 8.4 while you are already making a change.

What end of life means for a WordPress or PHP site

Three practical things follow.

1. Security fixes stop. When a new flaw is found in an end of life branch, the PHP project does not publish a fix. php.net's own EOL page says unsupported branches may have unfixed security vulnerabilities.
2. The October 2026 flaws show the cost. php.net announced on 21 October 2026 that two critical flaws allow unauthenticated remote code execution. The fixed releases are for 8.2 to 8.5. For 8.1 and older, php.net says the project no longer provides updates, and that some Linux distributions and long term support vendors may offer backported fixes. If you are new to the term, see what remote code execution means.
3. Your site may keep working. An end of life PHP version does not break your pages. It simply stops getting protection, which is why the risk is easy to ignore until it is not.

Kinsta says nearly half of WordPress sites still run an end of life PHP version. That is Kinsta's own claim, so take it as a sign of how common the problem is, not as a measured figure.

For the full story of the flaws, read our main PHP vulnerability guide.

The minimal source backports for 7.4, 8.0 and 8.1

Because of how severe the flaws are, the PHP security team published minimal source backports for 7.4, 8.0 and 8.1 on GitHub, according to the php.net advisory. They are meant for people who build PHP from source, or who have no access to a long term support vendor.

For most site owners this is not the route. Building PHP from source is a job for a system administrator, and a backport fixes these two flaws only. It does not bring the branch back into support. If you rely on an old version through a vendor, ask them for their patch details.

What to do in your situation

If you cannot move yet, php.net lists temporary settings that only reduce exposure: memory_limit set to -1 so apps cannot override it, a low post_max_size, session.upload_progress.enabled set to 0, and fatal_error_backtraces set to 0 on PHP 8.5. They do not make an install safe. The NCSC adds that if you cannot update or apply them, consider taking the system offline, and check for signs of compromise.

How to move to a newer PHP version

WordPress.org currently recommends PHP 8.3 or higher. Kinsta calls 8.4 the safer default. The steps are the same either way:

1. Find your version. Our guide to checking and updating PHP on WordPress walks through it, and there is a general method for other setups in how to check your PHP version in WordPress, cPanel or the command line.
2. Back up the site, then update WordPress, themes and plugins.
3. Test on a staging copy if your host offers one.
4. Change the version in your host's panel, or ask them to.
5. Check the site, then ask the host in writing to confirm the fix. Our list of questions to ask your web host helps.

If your host is slow or only offers old versions, a move may be worth considering. Our post on managed WordPress hosting versus shared hosting shows who is responsible for patching in each case. Also see the WordPress minimum PHP version for what WordPress itself needs.

How we help

If your site sits on an old PHP version because a plugin or theme is holding it back, that is a normal project to fix, and our WordPress development page describes how we handle it. For regular care, there is Webflow maintenance, and for a clean exit from server software altogether, Webflow migration moves a WordPress site and keeps your URLs. Costs depend on scope, never an hourly rate, and our website maintenance cost guide shows typical budget lines. After final payment, the design, copy and code are yours, and you keep the logins for the domain, hosting and analytics.

Frequently asked questions

When did PHP 7.4 reach end of life?

php.net lists the end of life date for PHP 7.4 as 28 November 2022, and the last release was 7.4.33. It has had no official security fixes since.

When does PHP 8.1 reach end of life?

php.net lists 31 December 2025 as the end of life date for PHP 8.1, with 8.1.34 as the last release. That date has already passed, so 8.1 is unsupported today.

When does PHP 8.2 reach end of life?

Security support for PHP 8.2 ends on 31 December 2026, per php.net. It is still supported on 22 October 2026, and the fix for the October flaws is in 8.2.35. Plan a move to 8.3 or 8.4 before that date.

Is PHP 8.0 also end of life?

Yes. php.net lists 26 November 2023 as its end of life date, with 8.0.30 as the last release. It is unsupported today.

Is it safe to stay on PHP 8.1 if my host patches it?

It depends on the host. php.net says some distributions and long term support vendors may provide backported fixes. Ask your host in writing exactly what they patch and until when. A backport can keep the old version number, so the number alone will not tell you.

Will my WordPress site stop working on an old PHP version?

No. WordPress.org says it works with PHP as far back as 7.4. The risk is not that the site breaks. It is that the PHP underneath no longer receives fixes from the PHP project.

Which PHP version should I choose now?

WordPress.org recommends 8.3 or higher, and Kinsta recommends 8.4. Whichever you pick, test first and use the fixed patch level. This is general guidance, not a guarantee, and not legal advice.