On 21 October 2026, the PHP project released fixes for two critical vulnerabilities. Systems on current PHP versions can apply the fix directly.
Systems on older versions, which are common in business applications built five to ten years ago, need a different plan. This article sets out what was released, what to check, and how to choose between upgrading and rebuilding.
What Was Released on 21 October
The release fixes CVE-2026-109618 and CVE-2026-109619, both rated 9.2 (Critical) under CVSS v4.0. Under certain conditions, they allow code to be run on the server without authentication.
Fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
In Japan, IPA and the National Cyber Office advised organisations to take stock of where PHP is used and to apply the fix promptly. Several online services carried out emergency maintenance on 21 October.
Fix Status by PHP Branch
| Branch | Fix in the 21 October release | End of security support |
|---|---|---|
| 8.5 | Fixed in 8.5.12 | 31 Dec 2029 |
| 8.4 | Fixed in 8.4.27 | 31 Dec 2028 |
| 8.3 | Fixed in 8.3.36 | 31 Dec 2027 |
| 8.2 | Fixed in 8.2.35 | 31 Dec 2026 |
| 8.1 | Limited source backport only | Ended 31 Dec 2025 |
| 8.0 | Limited source backport only | Ended 26 Nov 2023 |
| 7.4 | Limited source backport only | Ended 28 Nov 2022 |
| 7.3 and earlier, 5.x | No fix published | Ended 2018–2021 |
Linux distributions may ship backported fixes under an older version number. Check the advisory of the distribution or hosting provider in use.
Four Points to Check
- PHP version: Fixes exist for 8.2 to 8.5. For 7.4 to 8.1, only limited source backports exist. For 7.3 and earlier, no fix has been published.
- How PHP runs: Apache mod_php, PHP-FPM and CGI have different attack conditions. Apache mod_php is listed as the highest priority.
- Whether the fix is in effect: The php -v command can report a different installation from the one serving web requests. Workers need a restart after patching.
- End-of-support date: PHP 8.2 support ends on 31 December 2026. A system moved to 8.2 now will need another upgrade soon.
Why Older PHP Systems Are Hard to Upgrade
- Framework or plugins do not support newer PHP: Older framework versions, EC packages and plugins stop working on newer PHP. Code that uses functions removed from PHP, such as the old mysql_* functions, has to be rewritten.
- The original developer is no longer available: Nobody on hand knows the code well enough to change it safely.
- No up-to-date specification: Without current documents, it is unclear what the system should do, so the scope of testing after an upgrade cannot be set.
Upgrade or Rebuild: How to Decide
Both paths remove the dependency on an unsupported PHP version. The right one depends on the state of the code and on plans for the business.
| An upgrade usually fits when | A rebuild usually fits when |
|---|---|
| The framework has a supported version for newer PHP | The framework or EC package has no upgrade path |
| The code is still maintained and reasonably understood | Specifications are missing or out of date |
| The system's functions match current business needs | Business processes have changed since the system was built |
| Tests or a test procedure exist | The same problem would return at the next end-of-support date |
How TPS Can Help
1. Status Check
Review of the PHP version, how PHP runs, the framework and plugins, and whether the 21 October fix is in effect. The output is a short report with the upgrade blockers and a recommended next step.
2. Version Upgrade
Move to a supported branch (8.3 or later, given the 8.2 end date), fix incompatible code and run regression tests.
3. Rebuild from Recovered Specifications
Where an upgrade is not realistic, current behaviour is recovered from the source code into a requirements knowledge base that links each requirement to the code. The business side reviews it, and the system is rebuilt from it.
For a platform in Japan, this method recovered 38 business flows from three production systems, with 657 working steps traced to the code (case study).
The status check covers versions, configuration and upgrade feasibility. It is not a penetration test; for that, a specialist security provider is recommended. Work can run alongside the current development vendor.
Not sure which path fits your system?
Share the PHP version and system type, if known. TPS replies by email to arrange a status check. An NDA can be signed before any code or configuration is shared.
TPS operates an information security management system aligned with ISO/IEC 27001:2022 (read more).
FAQs
1. Is applying the 21 October fix enough?
For systems on 8.2 to 8.5, applying the fix and confirming that it is the version serving web requests addresses these two vulnerabilities. Systems on 8.2 will still need an upgrade before 31 December 2026.
2. What about systems on PHP 7.4, 8.0 or 8.1?
Limited source backports were released for these branches, and some distributions or support vendors provide fixed builds. These branches no longer receive regular fixes, so a move to a supported version remains necessary.
3. Is server access needed for a status check?
Not necessarily. The check can start from information provided by the client, such as version output, configuration files or a copy of the source code. Where access is needed, the scope and method are agreed in advance.
4. Can TPS work alongside the current vendor?
Yes. TPS can take on part of the work, such as the upgrade or testing, while the current vendor stays responsible for operation.
