PHP end of life (EOL) is the date after which the PHP project stops releasing fixes, including security fixes, for a release branch. As of October 22, 2026, php.net lists only PHP 8.2, 8.3, 8.4 and 8.5 as supported; PHP 8.1 and older are end of life. The PHP project's fixed releases for the October 21 PHP2Shell flaws exist only for those four branches (see our PHP2Shell fix guide). This guide gives the dated version table, upgrade paths and framework support, and says when to move off PHP. MIS Services offers a free assessment: contact us.
Which PHP Versions Are Supported Right Now?
PHP end of life means the PHP project has stopped releasing fixes for a release branch, including security fixes. On php.net's own page, users of an end-of-life release are told to upgrade as soon as possible because they may be exposed to unpatched vulnerabilities. We opened php.net's supported-versions page on October 22, 2026; it showed βToday: 22 Oct 2026β and four supported branches, 8.2 to 8.5. For the retired rows we used php.net's unsupported-branches page and the PHP ChangeLog.
| Branch | Initial release | Active support until | Security support until | Status on Oct 22, 2026 | Newest release listed by php.net |
|---|---|---|---|---|---|
| 8.5 | Nov 20, 2025 | Dec 31, 2027 | Dec 31, 2029 | Supported, active support | 8.5.12 |
| 8.4 | Nov 21, 2024 | Dec 31, 2026 | Dec 31, 2028 | Supported, active support until year end | 8.4.27 |
| 8.3 | Nov 23, 2023 | Dec 31, 2025 (ended) | Dec 31, 2027 | Supported, security fixes only | 8.3.36 |
| 8.2 | Dec 8, 2022 | Dec 31, 2024 (ended) | Dec 31, 2026 | Supported, security fixes only; ends in about 10 weeks | 8.2.35 |
| 8.1 | Nov 25, 2021 | Nov 25, 2023 (derived, ended) | Dec 31, 2025 (ended) | End of life | 8.1.34 |
| 8.0 | Nov 26, 2020 | Nov 26, 2022 (derived, ended) | Nov 26, 2023 (ended) | End of life | 8.0.30 |
| 7.4 | Nov 28, 2019 | Nov 28, 2021 (derived, ended) | Nov 28, 2022 (ended) | End of life | 7.4.33 |
PHP end-of-life dates at a glance
- PHP 7.4: ended November 28, 2022
- PHP 8.0: ended November 26, 2023
- PHP 8.1: ended December 31, 2025
- PHP 8.2: ends December 31, 2026
- PHP 8.3: ends December 31, 2027
- PHP 8.4: ends December 31, 2028
- PHP 8.5: ends December 31, 2029
A supported branch is not automatically a patched one. The PHP announcement dated October 21, 2026 says PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, and CERT-EU lists every earlier point release on those four branches as affected. What matters is the newest number inside your branch. (php.net's ChangeLog files those four releases under October 22, 2026, the originally planned date; the PHP Foundation says the release was moved forward to October 21 after the CVE numbers leaked, which is the date the announcement and the advisories use.)
How many sites does this touch? W3Techs reported on October 22, 2026 that PHP is used by 69.3 percent of the websites whose server-side language it knows. Among those, it showed PHP 8 on 65.3 percent, PHP 7 on 26.9 percent, PHP 5 on 7.7 percent and PHP 4 on 0.1 percent. These are survey estimates by major version only, and βPHP 8β includes the end-of-life 8.0 and 8.1 branches. Adding PHP 7, 5 and 4 gives at least 34.7 percent of PHP sites on a branch that has been unsupported since November 2022 or earlier.
What Does PHP End of Life Actually Mean?
The policy on php.net is short. Each branch is fully supported for two years from its first stable release, with bugs and security issues fixed in regular point releases. It then gets two more years of security-only support for critical issues, with releases made as needed. After four years, it is end of life. That four-year model comes from a PHP RFC accepted in 2024, which added a year of security support and moved end dates to December 31. Branches before 8.1 got three years in total under php.net's website code, which is why PHP 7.4 and 8.0 ended in November of their third year while PHP 8.1 ran to December 31, 2025.
What changes when a branch reaches end of life
- Upstream fixes stop. Your site does not switch off on the end-of-life date, and your code keeps running. What stops is the flow of fixes from the PHP project.
- Newly found bugs stay open upstream. PHP2Shell shows how that looks in practice: the php-src security advisory lists patched versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12 and nothing older.
- Backports are the exception, not the policy. The PHP announcement says the PHP security team provided minimal source backports for 7.4, 8.0 and 8.1 for people who build from source or have no LTS vendor. Sophos adds that no binary releases will be provided and that systems on these versions should be upgraded to a supported branch, while CERT-EU says to contact your vendor, because some distributions and LTS vendors provide backported fixes, or to upgrade to a supported version.
- The ecosystem narrows. WordPress.org recommends PHP 8.3 or greater and calls 7.4+ a fallback for legacy environments; the Drupal documentation says no supported Drupal version supports any PHP 7 release; Laravel 13 requires PHP 8.3.
What the agencies said on October 21, 2026
CISA's alert says organizations that cannot update immediately, or that continue to use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched or updated. NSA's advisory lists replacing end-of-life PHP services that will not be compatible with patching among the steps to assess, and says that if an immediate update is not feasible, systems should be taken offline until fully mitigated. The UK's NCSC encourages organisations on older versions to update to a fully supported version. βPatched or updatedβ matters: some vendors do patch older builds, as the tracker data below shows.
This is a planning deadline, not a reason to panic-migrate. It is a reason to learn your exact version this week. For the immediate steps (patching, interim mitigations, log review), use our PHP2Shell fix guide. If you suspect a server is already compromised, that is incident response, which MIS does not offer; contact your host or a security firm.
Six Things to Know About PHP End of Life
Each point is backed by a source in the sections below and in the source list at the end.
8.1 and older are unsupported
php.net lists 8.1 as end of life since December 31, 2025, 8.0 since November 26, 2023 and 7.4 since November 28, 2022.
Supported is not patched
Only 8.2.35, 8.3.36, 8.4.27 and 8.5.12 and later are fixed releases. CERT-EU lists earlier point releases on those branches as affected.
8.2 ends December 31, 2026
Security support for 8.2 ends in about ten weeks, so aim past 8.2 when leaving 8.1 or older.
Version numbers can mislead
Linux vendors fix bugs inside older-looking version numbers. Check the advisory or changelog, not just the string.
Your stack sets the target
WordPress.org recommends 8.3 or greater, Laravel 13 requires 8.3 and Symfony 8.1 requires 8.4. Your CMS and plugins decide.
Upgrade first, migrate if needed
Most PHP apps can be upgraded in place. Apps tied to unsupported frameworks or abandoned plugins may need a bigger move.
How Do You Check Which PHP Version You Really Run?
Do this first, because the answer decides which row of the table you are in. Sophos advises identifying PHP from the processes actually running (php, php-fpm, php-cgi and versioned names such as php8.3) rather than from asset records, and checking version numbers from the binary itself because install paths can be misleading. It also says to include PHP bundled inside appliances and hosted services.
- WordPress: open Tools, Site Health, Info, Server. WordPress.org's Site Health documentation describes that section, and WordPress core's debug-data code defines a βPHP versionβ field in it. The Status tab can flag outdated PHP as a critical issue.
- cPanel: MultiPHP Manager lists each domain's current PHP version and lets you change it, but only to versions your server administrator has installed.
- Plesk: the documentation says the selected PHP version appears next to the PHP icon on the domain card; open Websites and Domains, then PHP, to change it.
- In code: phpversion() returns the version of the running PHP parser.
- Command line: php -v prints the command-line binary's version. Your web server may run a different build, so confirm through your host's panel or a live web request, as Sophos advises for settings.
- Composer projects: composer check-platform-reqs checks the real platform against your installed packages' requirements (unlike install, it ignores config.platform), and composer audit lists known security advisories for installed packages (Composer documentation).
Can a version number alone tell you whether you are patched?
Not always. The Debian security FAQ says Debian keeps the version a release shipped and backports fixes into it, so a patched package can still look old; it tells you to read the package changelog or compare your exact version with the one in the advisory. Red Hat's backporting page makes the same point and warns that scanners judging only by version number can mislead. The distribution trackers for CVE-2026-109618 show it concretely:
| Distribution release | PHP package | Fixed package version listed | What it shows |
|---|---|---|---|
| Ubuntu 24.04 LTS | php8.3 | 8.3.6-0ubuntu0.24.04.13 | Listed as fixed, although the number starts with 8.3.6, far below upstream 8.3.36 |
| Ubuntu 22.04 LTS | php8.1 | 8.1.2-1ubuntu2.28 | PHP 8.1 is end of life upstream, yet this release lists a fix |
| Ubuntu 20.04 LTS | php7.4 | 7.4.3-4ubuntu2.29+esm5 | Fix listed under Ubuntu Pro |
| Ubuntu 26.04 LTS | php8.5 | 8.5.4-0ubuntu1.5 | Listed as fixed |
| Debian 12 (bookworm) | php8.2 | 8.2.35-1~deb12u1 | Security archive build matching upstream 8.2.35 |
| Debian 13 (trixie) | php8.4 | 8.4.27-1~deb13u1 | Security archive build matching upstream 8.4.27 |
Two lessons follow. An end-of-life upstream branch can still be patched by a vendor, but only while that vendor supports your release and only if you install the vendor's package. And you should ask your host or vendor which advisory covers your build; the PHP announcement and CERT-EU both tell users of end-of-life versions to contact their vendor for exactly this reason.
Sansec adds that a fixed package keeps its PHP version number (its example is 8.1.34) and gets a new package release, and it shows how to confirm the fix: on Debian and Ubuntu, search /usr/share/doc/php8.1-common/changelog.Debian.gz for CVE-2026-109618 (use your own PHP version in the package name); on RHEL, AlmaLinux and Rocky Linux, run rpm -q --changelog php-common and search the output for the CVE. If your build's changelog does not mention the CVE, ask your vendor.
How Do You Upgrade From PHP 7.4, 8.0 or 8.1?
php.net publishes one official migration guide per step, each with a backward-incompatible-changes page and a deprecated-features page: 7.4 to 8.0, 8.0 to 8.1, 8.1 to 8.2, 8.2 to 8.3, 8.3 to 8.4 and 8.4 to 8.5. A jump from 7.4 to 8.4 therefore means reading five of them. The table lists examples from those pages; it is not a complete checklist.
| Step | Examples the official guide flags | What it means for your code |
|---|---|---|
| 7.4 to 8.0 | Non-strict comparison of numbers with non-numeric strings changed, so 0 == βfooβ is now false. match and mixed became reserved words. create_function(), each() and the (real) and (unset) casts were removed. The @ operator no longer silences fatal errors. Many warnings became Error exceptions, and the default error_reporting level became E_ALL. | Code that relied on loose comparison, removed functions or suppressed errors needs changes; logs quiet on 7.4 can get noisy. |
| 8.0 to 8.1 | Passing null to non-nullable parameters of built-in functions is deprecated. Implicit float-to-int conversions that lose precision are deprecated. FILTER_SANITIZE_STRING is deprecated, as are strftime() and gmstrftime(). | Mostly deprecations: code still runs but logs fill with notices. |
| 8.1 to 8.2 | Creating dynamic properties is deprecated unless the class opts in with the AllowDynamicProperties attribute. The dollar-brace style of string interpolation is deprecated. utf8_encode() and utf8_decode() are deprecated. strtolower() and related functions are no longer locale-sensitive. | Classes that add properties on the fly emit notices; declare them. |
| 8.2 to 8.3 | Programs very close to overflowing the call stack may now throw an Error. Assigning a negative index to an empty array changes the next index. The Date extension throws its own exceptions in place of some warnings. | A smaller step, with edge cases to test. |
| 8.3 to 8.4 | Implicitly nullable parameter types are deprecated (write ?T instead of T with a null default). The E_STRICT level was removed. exit() now behaves like a function and throws TypeError for invalid types. Several resource types became objects. | Update type declarations and any is_resource() checks. |
| 8.4 to 8.5 | The non-canonical casts (boolean), (integer), (double) and (binary) are deprecated, as are the backtick operator and terminating a case statement with a semicolon. The disable_classes INI setting was removed, and casting floats that cannot be represented as int now warns. | Mostly deprecations plus one removed setting. |
Tools that find breaking changes before production does
- **PHPStan** analyzes code without running it. Its phpVersion setting makes it analyze the code as if written for a different PHP version, and since PHPStan 2.0 it accepts a minimum and maximum. It runs as vendor/bin/phpstan analyse after composer require --dev phpstan/phpstan.
- **PHPCompatibility** is a set of PHP_CodeSniffer rules for cross-version checks. Its README shows phpcs -p . --standard=PHPCompatibility with a testVersion such as 8.3- (8.3 and above), and says coverage is not complete and the project needs funding.
- **Rector** rewrites code automatically. Its documentation shows vendor/bin/rector process --dry-run to preview changes before applying them, and advises legacy projects to raise the rule level one step at a time. Review its output like any pull request.
- Composer shows which dependencies block a newer PHP: its prohibits command (alias why-not) lists the packages that block a given version, and the documentation's own example asks it about php itself, such as composer prohibits php 8.4. composer outdated lists available updates (documentation).
- Your own tests and logs. PHP 8.0 made E_ALL the default error_reporting level, so read staging logs before you touch production.
A Four-Step PHP Upgrade Plan, Patch to Cut-Over
Inventory and verify
List every PHP application, host and container. Record the version from the running process or vendor panel, plus the vendor's patch status, including PHP bundled in appliances.
Patch or contain now
Move to a fixed release or your vendor's equivalent. The interim mitigations in the advisories are stopgaps, not substitutes, and CISA and NSA say to take systems offline if you cannot update.
Make the code ready
On a branch, run static analysis and compatibility checks, update Composer constraints and plugins, read the migration guide for each step, and clear deprecation notices on staging.
Cut over and watch
Test on staging with production-like data, switch the version, and watch logs and error rates. Keep a rollback plan, but treat any return to an end-of-life version as temporary.
Not sure where your stack sits? The free assessment starts with your versions and ranks your PHP applications by risk. See our PHP2Shell fix guide for this week's steps.
Which PHP Versions Do WordPress, Laravel, Symfony and Drupal Support?
Your framework or CMS usually decides which PHP versions you can move to. The table uses each project's own published documentation, read on October 22, 2026. These pages change with every release, so recheck before you plan. For WordPress in particular, see what WordPress owners should do now.
| Project and release | PHP versions per its own documentation | Notes from the same source |
|---|---|---|
| WordPress 7.1 and 7.0 | 7.4 through 8.5 marked compatible | WordPress 7.0 dropped PHP 7.2 and 7.3. WordPress.org recommends PHP 8.3 or greater. |
| WordPress 6.9 | 7.2 through 8.5 marked compatible | PHP 8.5 was added as beta support in 6.9; the project has since retired the beta label. |
| WordPress 6.8 and 6.7 | 7.2 through 8.4; PHP 8.5 is marked N | PHP 8.5 is not listed as compatible with these older releases. |
| Laravel 13 (released March 17, 2026) | 8.3 to 8.5 | Security fixes until March 17, 2028. The release notes say Laravel 13 requires PHP 8.3 at minimum. |
| Laravel 12 | 8.2 to 8.5 | Bug fixes until August 13, 2026; security fixes until February 24, 2027. |
| Laravel 11 and Laravel 10 | 11: 8.2 to 8.4. 10: 8.1 to 8.3 | Security fixes ended March 12, 2026 (11) and February 4, 2025 (10). |
| Symfony 8.1 | Requires PHP 8.4.0 or higher | Current stable release on symfony.com. |
| Symfony 7.4 (long-term support) | Requires PHP 8.2.0 or higher | symfony.com lists supported versions 6.4, 7.4 and 8.1. |
| Symfony 6.4 | Requires PHP 8.1.0 or higher | The minimum allows PHP 8.1, which is end of life. |
| Drupal 11.3 and 11.4 | 8.3, 8.4 and 8.5 | Drupal 12.0 lists PHP 8.5 only. |
| Drupal 10.4 to 10.6 | 8.1 to 8.4; PHP 8.5 is not supported | The page refers to Drupal 10's end-of-life date in December 2026. |
Read the table as a floor and a ceiling. A Laravel 10 or 11 application, or a Symfony 6.4 site, can sit on PHP versions that are themselves end of life or close to it, and Laravel 10 and 11 no longer get security fixes. So moving the framework to a supported release is often part of the PHP upgrade. The tables describe core software only; plugins, themes and packages can set a lower ceiling.
What About Hosting Panels, Distribution Packages and Extended Support?
Control panels can still offer versions the PHP project has retired. cPanel's documentation, last modified July 8, 2026, says EasyApache 4 supports PHP 7.4 and PHP 8.1 through 8.5, and that its default profile includes 8.1 and 8.2. Being selectable in a menu does not make a version supported by the PHP project. Plesk's documentation warns that PHP versions are not 100 percent compatible and that a site written for PHP 8.x may not work on a different version, and it says to contact your hosting provider if the version you want is missing. Some platforms schedule retirement for you: WP Cloud advises hosts to move customers off retiring versions by December 15 each year.
Extended support: a bridge, not a destination
Some vendors sell security patches for versions the PHP project has retired. Zend's PHP LTS page says it covers PHP 7.2, 7.3, 7.4 and 8.1. cPanel's documentation describes TuxCare's Extended Lifecycle Support for PHP as a cPanel extension that supplies patched packages for outdated versions, and says TuxCare delivers patches for critical and high-severity issues (CVSS 7 and above) within 14 days of public disclosure, which is the vendor's claim and one we have not tested. Ubuntu Pro, shown in the tracker table earlier, is a distribution-level example. These are commercial products; this guide has not compared them. The cPanel page itself frames the extension as a way to stay online until you can upgrade. Ask any vendor whether it has shipped a fix for the October 21 flaws on your exact version.
| Server | Source of fixed packages (per Sansec) | Fixed PHP versions listed |
|---|---|---|
| Debian, Ubuntu | deb.sury.org and ppa:ondrej/php (OndΕej SurΓ½), free | 5.6, 7.4, 8.0, 8.1 |
| Ubuntu 22.04 | Ubuntu, free | 8.1 |
| Ubuntu 14.04 to 20.04 | Ubuntu Pro (Legacy add-on for 14.04 and 16.04) | 7.4 on 20.04, 7.2 on 18.04, 7.0 on 16.04, 5.5 on 14.04 |
| Debian 9 to 11 | Freexian ELTS, paid | 7.4 on 11, 7.3 on 10, 7.0 on 9 |
| RHEL, AlmaLinux, Rocky Linux, Fedora | Remi's repository, free | 7.4, 8.0, 8.1 (7.2 and 7.3 to follow) |
| AlmaLinux 8 to 10 | AlmaLinux, free | Every PHP stream AlmaLinux ships |
| RHEL 8 and 9 | Red Hat, subscription | Some streams, others in progress |
| cPanel on CloudLinux | CloudLinux | ea-php52 to ea-php85 |
| Any server | TuxCare ELS for PHP, paid | 5.x to 8.1, rolling out per branch |
| Any server | ZendPHP LTS, paid | 7.2, 7.3, 7.4, 8.1 |
| Build from source | php-src branches from the PHP security team | 7.4, 8.0, 8.1 |
The same Sansec section says to update through the panel on Plesk, DirectAdmin or cPanel without CloudLinux and check its changelog for the CVE, and that the official Docker php image gets no fix for 8.1 or older, so rebuilding it does not help on those versions. CERT-EU said Remi's volunteer-run repository would have no update on release day; Sansec's table above now lists Remi's repository among sources of fixed packages for 7.4, 8.0 and 8.1. The picture changes fast, which is why this page is date-stamped.
When your host controls the PHP version, ask in writing which PHP build runs your site, which advisory covers it, and when support for it ends.
How Hard Is a PHP Upgrade? What Drives the Effort
We found no reliable source for an average duration or cost of a PHP upgrade, so this page gives none. The official guides and tool documentation do show the factors that decide effort; treat the table as a way to size your own project, not a forecast.
| Driver | Tends to be easier | Tends to be harder | Where this comes from |
|---|---|---|---|
| Size of the version gap | One step, such as 8.2 to 8.3 | Several steps, such as 7.4 to 8.4, with the 8.0 changes to comparison, removed functions and errors | php.net migration guides |
| How typed and modern the code is | Typed, object-oriented code | Untyped procedural code mixed with templates | Rector and PHPStan documentation say they work best with typed, object-oriented code |
| Dependencies | All Composer packages already allow the target PHP | Abandoned or pinned packages, plugins and themes that cap the PHP version | Composer prohibits command; WordPress compatibility notes |
| Automated tests | Tests cover the main flows | Behavior is verified by hand | Our judgment |
If your application sits in the harder column on most rows, look at migration options alongside the upgrade, such as the paths on our PHP to Node.js, Java and React migration page, but fix the patch gap first. A migration is a months-long project; a PHP upgrade can start this week.
Should You Upgrade PHP or Move Off It?
Upgrade first in most cases. A move to Node.js or Java is justified when the application cannot realistically reach a supported PHP, or when your team wants that stack for its own reasons. It is not a way to escape security patching: the Node.js project's vulnerability blog lists security releases on March 24, June 18, July 29 and October 21, 2026, and every runtime ships fixes. What a migration changes is your maintenance burden and risk profile. For the trade-offs, see PHP vs Node.js: which backend.
| Your situation | What the sources say | Sensible next step |
|---|---|---|
| On 8.2, 8.3, 8.4 or 8.5 below the fixed release | PHP project: update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 | Patch, restart workers and verify with a live request. Start with the PHP2Shell fix guide. |
| On a fixed PHP 8.2 | php.net: security support ends December 31, 2026 | Schedule the move to 8.3 or newer before year end. |
| On 8.1 or older with vendor packages (Ubuntu, Debian, Red Hat) or a managed host | Trackers list vendor fixes for some older builds; Sansec lists community and paid sources; vendors say version strings can mislead | Get the advisory in writing, confirm when vendor support ends, and plan the upgrade. |
| On 8.1 or older, built from source or with no vendor | PHP team: minimal source-only backports for 7.4, 8.0 and 8.1. Sophos says upgrade to a supported branch; CERT-EU says contact your vendor or upgrade | Upgrade to 8.3 or newer and treat any backport as a stopgap. |
| Cannot upgrade yet but must stay online | CISA and NSA: take systems offline if they cannot be updated; vendors sell extended support | Restrict access, consider extended support as a dated bridge, set an upgrade deadline. |
| App tied to an unsupported framework release or abandoned plugins | Framework tables show releases that have ended support | Assess upgrading the framework and PHP together, or an incremental migration. |
| Team prefers a JavaScript or Java stack | A new stack still needs patching | Treat it as a planned project after patching; see the migration page. |
When not to migrate
If the application is healthy, its framework supports a current PHP and its tests pass on a newer version, an in-place upgrade is the faster, lower-risk path. It also leaves your URLs unchanged, which matters for search traffic; a re-platform can change URLs and rendering, so any move needs redirects, canonicals and sitemaps planned. MIS Services has been an SEO agency since 2014, with 375 clients to date (about us), and builds web apps on Next.js, React and Node (see application development). Our free assessment recommends whichever of patch-and-upgrade, incremental migration or rebuild fits.
Where the Facts on This Page Come From
We opened each page below on October 22, 2026 (the PHP2Shell advisories were re-checked at 11:15 UTC). The story is still moving, so check the primary sources for the latest.
- PHP: Supported Versions php.net/supported-versions.php β branch table and support policy
- PHP: Unsupported Branches php.net/eol.php β end-of-life dates for 8.1, 8.0, 7.4
- PHP 8 ChangeLog php.net/ChangeLog-8.php β release dates, newest point releases
- PHP 7 ChangeLog php.net/ChangeLog-7.php β PHP 7.4.0 release date
- PHP security advisory announcement, October 21, 2026 php.net/archive/2026.php#2026-10-21-5 β fixed releases, source backports
- php-src GitHub advisory GHSA-w8hw-w9fx-j79w github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w β affected and patched versions
- php.net website source: branches.inc github.com/php/web-php/blob/master/include/branches.inc β rules behind the derived dates
- PHP RFC: Release cycle update wiki.php.net/rfc/release_cycle_update β four-year support, December 31 end dates
- CISA alert, October 21, 2026 cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-re β unsupported versions, offline if no update
- NSA press release, October 21, 2026 nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Articl β replace end-of-life PHP
- NCSC (UK): Critical security issue affecting PHP ncsc.gov.uk/news/critical-security-issue-affecting-php β older versions: update
- The PHP Foundation: Today's PHP security release thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how- β release moved to October 21
- CERT-EU Security Advisory 2026-018 cert.europa.eu/publications/security-advisories/2026-018/ β affected branches, vendor advice
- Sophos advisory SA-20261021-php2shell sophos.com/en-us/security-advisories/sophos-sa-20261021-php2shell β inventory advice, 8.1 and older
- Sansec: PHP2Shell sansec.io/research/php2shell β older-version package table
- Ubuntu security: CVE-2026-109618 ubuntu.com/security/CVE-2026-109618 β fixed package versions
- Debian security tracker: CVE-2026-109618 security-tracker.debian.org/tracker/CVE-2026-109618 β fixed package versions
- Debian security FAQ debian.org/security/faq β backports and version numbers
- Red Hat: Security Backporting Practice access.redhat.com/security/updates/backporting β backported fixes
- W3Techs: PHP usage statistics w3techs.com/technologies/details/pl-php β usage and version split
- WordPress.org: Requirements wordpress.org/about/requirements/ β recommended PHP versions
- Make WordPress Core: PHP Compatibility and WordPress Versions make.wordpress.org/core/handbook/references/php-compatibility-and-word β per-release compatibility
- WordPress.org: Site Health screen wordpress.org/documentation/article/site-health-screen/ β Info and Server section
- Laravel 13.x release notes laravel.com/docs/13.x/releases β support policy, PHP minimum
- Symfony releases symfony.com/releases β supported versions, minimum PHP
- Drupal.org: PHP requirements drupal.org/docs/getting-started/system-requirements/php-requirements β PHP versions per Drupal release
- cPanel: MultiPHP Manager for cPanel docs.cpanel.net/cpanel/software/multiphp-manager-for-cpanel/ β per-domain PHP version
- cPanel: TuxCare Extended Lifecycle Support for PHP docs.cpanel.net/knowledge-base/third-party/tuxcare-extended-lifecycle- β extended support description
- Plesk: PHP Settings docs.plesk.com/en-US/obsidian/administrator-guide/website-management/w β changing the PHP version
- WP Cloud: PHP Life Cycle and Supported Versions wp.cloud/php-life-cycle-supported-versions β PHP 8.1 removal date
- Zend: PHP Long-Term Support zend.com/services/php-long-term-support β extended-support versions
- PHP manual: migration guides php.net/manual/en/appendices.php β per-step guides
- PHP manual: phpversion() php.net/manual/en/function.phpversion.php β reading the running version
- PHPStan config reference: phpVersion phpstan.org/config-reference#phpversion β analyzing as a different PHP version
- PHPCompatibility README github.com/PHPCompatibility/PHPCompatibility β testVersion usage, limits
- Rector documentation getrector.com/documentation β dry-run, levels, PHP sets
- Composer command-line documentation getcomposer.org/doc/03-cli.md β platform checks, prohibits, audit
- Node.js: vulnerability blog nodejs.org/en/blog/vulnerability β 2026 security release dates
Frequently Asked Questions
Not Sure Which PHP Version You Can Reach?
Book the free 30-minute PHP architecture and migration assessment. It starts with your versions and application inventory; a written risk ranking and a recommendation (patch and upgrade, incremental migration, or rebuild) follow. See our PHP migration page for the larger options.
12 W Sunrise HWY, Lindenhurst, NY 11757 Β· MonβFri 9 AM β 6 PM ET
Talk to Us About Your PHP Upgrade
Tell us which PHP version and framework you run and where it is hosted. Our hours are Monday to Friday, 9 AM to 6 PM ET.