USEFUL · LIMESEEK
Critical PHP security update: what to do with PHP 7.4 and other unsupported versions
October 2026 PHP fixes require action. Learn which supported releases to install, what emergency PHP 7.4 backports mean and how to plan a safe upgrade.
Checked against PHP's announcements on 23 October 2026.
If your website runs PHP, ask the person responsible for hosting to verify its actual runtime and patch status. Updating the CMS or a plugin alone does not update the PHP interpreter serving your website.
Which supported releases contain the fixes?
PHP's 21 October announcement names 8.2.35, 8.3.36, 8.4.27 and 8.5.12 as fixed releases for CVE-2026-109618 and CVE-2026-109619. The issues can allow remote code execution without authentication. The warning covers web-serving runtimes, including PHP-FPM and Apache mod_php. Install these releases or later supported security updates, or obtain confirmation of an equivalent vendor backport. PHP announcement
The OOM corruption advisory and stale global state advisory explain the distinct memory-handling failures. Do not assume an application login, a different CMS or a successful homepage check establishes protection.
Does PHP 7.4 have a fixed release?
PHP 7.4 no longer receives normal upstream security releases. Its upstream support ended on 28 November 2022. PHP 8.0 and 8.1 are also unsupported in October 2026. Moving from 7.4 to another unsupported branch does not provide an ongoing security-update path. PHP's end-of-life table
There is an important exception for this incident: PHP's security team supplied minimal emergency source backports for 7.4, 8.0 and 8.1. Those patches do not restart normal support or mean that an existing 7.4 installation is already fixed. They require a provider or qualified maintainer to build, package, deploy and verify the relevant changes. The official announcement links the source backports. PHP update guidance
For a hosted website, request a vendor advisory or package reference confirming coverage of both CVEs. A version string beginning with 7.4 cannot by itself tell you whether a vendor applied a backport. If the provider cannot demonstrate a maintained, patched package, arrange migration to a supported PHP branch urgently.
Build an upgrade plan around the application
Our suggested checklist for the hosting owner and developer is:
- List the domains, PHP pools, containers, scheduled commands and queue workers involved. Record the runtime used by each; command-line PHP can differ from web PHP.
- Back up the website files, database and relevant configuration, and establish a recovery procedure.
- Test the application on a maintained PHP branch in a separate environment. Review its framework, CMS, plugins, extensions and custom integrations for compatibility.
- Test the customer journeys that matter: sign-in, forms, file uploads, checkout, email and background processing where applicable.
- Deploy the verified runtime/package and restart or replace the processes that use it. Confirm the running application and workers use the intended build.
- Record the package evidence, completion time and responsible person. Give any temporary exception an owner and a migration deadline.
For new migration work, consider the remaining support window as well as compatibility. PHP 8.2's security support ends on 31 December 2026; 8.4 and 8.5 offer longer upstream support windows. Choose a supported branch your application can run and maintain. PHP support schedule
What if you cannot upgrade immediately?
Ask your provider about a maintained vendor backport or a verified emergency build while compatibility work continues. If neither is available, agree how to restrict public exposure, including temporarily taking an affected application offline where necessary. A firewall rule or configuration workaround is not evidence that the runtime is patched.
The stale-state advisory recommends disabling session upload progress at startup and restarting workers to block confirmed session paths; it does not claim this blocks every variant. PHP also published a 23 October follow-up about an unusual session-serializer configuration and recommends keeping session.upload_progress.enabled=0 until the next regular bugfix release. Have the maintainer review that notice alongside the update. PHP follow-up
Where LimeSeek fits
After maintenance, an SEO crawl can help check public page availability, redirects and other visible technical changes. It does not inspect your server's installed packages, verify these patches or certify that a website is secure. Keep runtime verification with the hosting owner and use the crawl to review the public website after the work.