Critical PHP vulnerabilities in October 2026: what should you do with an old application?

On 21 October 2026, the PHP project published fixes for two critical vulnerabilities that may allow unauthenticated remote code execution. The patched releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The official recommendation is clear: PHP users should update immediately.

If your company relies on an older PHP application, this does not automatically mean that it must be rebuilt at once. The runtime must be patched first. Compatibility testing can then show whether the application will continue to work unchanged, needs dependency updates, requires staged modernisation or justifies a controlled rebuild.

Rewriting application code does not patch a vulnerability in the PHP interpreter. At the same time, updating PHP alone does not guarantee that an older application will be compatible with the new environment. These are separate problems and separate decisions.

Sources last checked: 23 October 2026. Before making a change, check the current PHP project advisory and information from the provider of your operating system, hosting service or container image.

What exactly did the PHP project announce?

The advisory from 21 October covers CVE-2026-109618 and CVE-2026-109619. According to the PHP project, installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The highest risk was reported for mod_php, where an unauthenticated request was shown to trigger the attack before application code runs.

Fixes are included in:

• PHP 8.5.12;
• PHP 8.4.27;
• PHP 8.3.36;
• PHP 8.2.35.

These are not four interchangeable target versions. Update within the branch used by your environment or follow the upgrade path supported by the operating system, hosting service or container-image provider. If a provider supplies its own package with backported fixes, verify that status in the provider's security notice rather than relying only on the version string.

PHP 8.1 and older branches no longer receive updates from the PHP project. PHP 8.2 is currently in security-only support, which ends on 31 December 2026. Moving to a newer branch may therefore be a separate compatibility project even after the urgent fix has been applied.

Additional information published on 23 October 2026

On 23 October, the PHP project described an unlikely remote-code-execution vector involving session.upload_progress. It suggested setting session.upload_progress.enabled=0 until the next regular bugfix release. The issue requires an unusual combination of configuration and application behaviour. Applications that never change the session serialisation handler at runtime can keep the feature enabled according to that notice.

Treat this as a temporary, configuration-dependent recommendation. It does not replace updating PHP, and changing the setting without checking the application may affect features that use upload progress. Confirm whether the setting is relevant and test the effect of any change.

First step: check the environment that serves the website

A version shown by php -v in a shell may describe the command-line interface, not the PHP runtime handling web requests. One server may use a different version or configuration for the website, scheduled tasks and queues.

Before choosing the scope of work, establish:

1. which PHP version serves the public application;
2. which SAPI or server integration is used, such as FPM, mod_php or CGI;
3. where the configuration comes from and who is responsible for changing it;
4. whether the operating-system package or container image includes a backported fix;
5. which PHP version is used by scheduled tasks, queues, imports and maintenance scripts;
6. whether a restorable backup and a return path are available;
7. which business processes must be checked immediately after the change.

If the application may already have been compromised, updating it is not the same as investigating an incident. Preserve the relevant evidence and agree the next steps with the person responsible for the infrastructure or incident response. This article does not replace that work.

An urgent update and application modernisation are different jobs

The urgent goal is to run a PHP release containing the security fix or a package that the responsible provider has confirmed as patched. Application modernisation begins when code, framework, libraries or deployment arrangements block that update or make its outcome unpredictable.

A safe sequence normally looks like this:

1. identify the runtime that actually serves web requests;
2. apply or plan the provider's security fix without waiting for a wider rebuild;
3. prepare a backup and verify that it can be restored;
4. run the application in a test environment on the patched PHP version;
5. check critical journeys, integrations, queues, scheduled tasks and file operations;
6. record incompatibilities and distinguish urgent faults from later improvements;
7. choose the smallest justified next stage and define its acceptance criteria;
8. deploy in a controlled way, restart the required processes and verify the effective version and main journeys.

Do not expose a vulnerable public instance merely to test whether the old application still works. If compatibility work takes longer, the risk must be limited separately at the infrastructure and operational level.

Four possible directions after securing the runtime

The PHP version alone is not enough to choose one of these directions. The same old version may lead to a straightforward update in one application and a larger compatibility project in another.

When can a runtime update be enough?

The simplest option is possible when the application uses maintained framework and library versions, deployment is repeatable, and the main processes can be tested before the change. The scope may then be limited to preparing a backup, testing the patched runtime, updating the environment and checking the application after deployment.

Background jobs must still be included. Scheduled tasks, queues, imports and scripts may use a different configuration from the web application.

When must the framework or libraries be updated?

An older application may contain syntax removed from newer PHP releases, an unsupported framework or packages abandoned by their maintainers. Custom modules and extensions may also be impossible to replace directly.

The first task is to find the smallest safe compatibility scope. Sometimes a few dependencies and a limited part of the code are enough. In other cases, successive framework versions require a staged migration. A single error message is not enough for a reliable answer.

When should modernisation be staged?

Staged modernisation is reasonable when the application still supports important processes, holds useful data and contains parts that can continue to operate. Instead of recreating everything at once, critical behaviour can first be protected with tests, deployment can be stabilised and the most problematic parts can be replaced in sequence.

Each stage should have its own outcome, acceptance criteria and return path. This keeps later decisions tied to a working system rather than assumptions.

The broader decision criteria are explained in Modernising an existing system or building from scratch.

When can a rebuild be justified?

A rebuild is worth considering when key dependencies are unsupported, the application cannot be reproduced in a controlled environment, small changes cause unpredictable faults, or the architecture makes it impossible to separate the processes the company still needs.

This still does not require one large cutover. A single process can be recreated first, its data can be compared, and the scope can be expanded only after the result is known. Starting from scratch without discovering the business rules often carries old problems into new code or removes behaviour that no one remembered to specify.

Two examples, two different paths

In the OBIBOOK project, we first repaired a failed CSV import and mobile behaviour. Only after understanding the process did we rebuild the book catalogue. Repair and rebuild were separate stages.

For Sprawdzeni.pl, the previous application was difficult to use and regularly produced errors. Its condition supported rebuilding the system while retaining and extending the visual concept created by its owner.

Neither project began because of the vulnerabilities described in this article. They only show that assessment of an existing system may lead to repair, staged work or a rebuild. There is no single answer for every old application.

What should you prepare for an initial assessment?

You do not need to know every technical detail. The following information is useful:

• the address and a short description of the application's role in the company;
• the warning from the hosting provider or administrator, without access credentials;
• the PHP version and runtime type, if known;
• the framework or CMS name and version, if known;
• where the source code comes from and whether it matches production;
• information about backups, a test environment and the deployment process;
• the processes that must be tested after an update;
• integrations and background tasks;
• the expected outcome of the first stage.

Do not send passwords, API keys, database copies or customer data through the contact form. We agree a safe method of transferring materials after the scope is established.

You can first use the application handover checklist. It helps organise the available information but does not replace a technical assessment.

What cannot be promised before the application is examined?

Before assessing a specific system, nobody can responsibly guarantee that:

• updating PHP will require no code changes;
• every dependency has a secure and compatible replacement;
• the backup can restore the system within the required time;
• every part of the application should be retained;
• a rebuild will cost less than modernisation;
• the PHP patch alone resolves every application-security issue.

For a wider review of application risks, see our web application security audit. If the system needs ongoing care after it has been stabilised, application or online store maintenance can be agreed separately.

Let us assess what your application needs

Tell us what the company uses the system for, which warning prompted the change and what must not be lost during the update. If you know the PHP version, framework, runtime type and the state of access to the source code and hosting, include them. Missing details do not prevent an initial conversation.

Do not send secrets or customer data. At this stage, we need a description of the situation and the first expected outcome.

Let us assess what your application needs, or first organise the materials with the checklist.

Sources

Sources checked on 23 October 2026:

• PHP: Security advisory - Critical remote code execution vulnerabilities, update now
• PHP: Informational advisory - Session upload progress
• PHP: Supported Versions
• PHP security advisory: CVE-2026-109618, RCE via OOM corruption
• PHP security advisory: CVE-2026-109619, RCE via stale global state
• PHP Manual: php_sapi_name
• PHP Manual: phpversion