A new warning after the emergency release

The PHP project issued a follow-up advisory on 23 October, two days after releasing fixes for the critical vulnerabilities known as PHP2Shell. The new notice concerns CVE-2026-115560, an unlikely remote-code-execution path involving session upload progress. PHP expects to address it in the next regular bugfix release.

The project suggests disabling session.upload_progress.enabled until then. It says applications that never change the session serialization handler at runtime can keep the feature enabled. This is a specific follow-up condition, not a statement that every updated PHP application remains exploitable.

For people who do not administer websites, the distinction matters: this is a server-software issue. Installing a browser update does not replace the work of the organization operating a PHP service.

What the first patches address

PHP’s 21 October security release fixed CVE-2026-109618 and CVE-2026-109619 in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The project urged users to update immediately.

One of the original advisories describes request-related state surviving after its backing memory has been freed. A later operation can then use information that is no longer valid. In plain English, the problem concerns how the server keeps and cleans up its internal working memory—not a visitor choosing a weak password.

Remote code execution means an attacker may be able to make the server run instructions. It is a potential consequence of exploiting a flaw, not proof that every affected server has already been compromised. SIGNAL has not tested an exploit or established that any particular website was breached.

The follow-up has a narrower trigger

Red Hat’s bulletin, updated on 23 October, describes the unusual combination behind the third issue: an application starts with php_binary or php_serialize as its session handler, changes it to php while running, and then starts a session, with upload progress still enabled.

These names identify ways PHP stores session information. A session lets a website remember information across requests, such as which account is signed in. The important point is the change between formats during execution, rather than the mere existence of a login page.

Red Hat says disabling upload progress fully protects against this third issue. It also distinguishes that protection from mitigations for the original vulnerabilities: reducing exposure to one route is not the same as fixing every affected code path. Follow the instructions for the actual product and package in use rather than treating one setting as a universal cure.

A corrected image is not a corrected running service

Docker said on 22 October that its Official Images and Hardened Images had been updated. Its notice gives the same four corrected PHP branch versions and tells users of affected images and packages to update. It identifies PHP as the vulnerable component, rather than describing a compromise of Docker’s own systems.

This illustrates an operational gap that can exist in software maintenance. A publisher can make a corrected base image available while an application built from an earlier image continues to run. Availability of the fix and deployment of the fix are separate facts.

For an operator, a meaningful completion record therefore needs to identify the package or image used by the active service. A download confirmation alone cannot establish that the process accepting web requests is using the corrected software.

What readers should ask next

A website owner using managed hosting can ask the provider to confirm which advisory applies, whether the corrected package is deployed and whether the follow-up setting has been assessed. A version number without the vendor’s advisory may be incomplete evidence when a distribution supplies backported security fixes.

This report is an explanation of the published advisories, not a universal configuration recipe. SIGNAL has not audited readers’ deployments. Removing memory limits or changing server settings without understanding their effects can create other problems; use the relevant vendor guidance.

The next useful evidence is confirmation from the operator of the service, followed by the promised regular release addressing the third issue. Keep the two questions distinct: have the emergency fixes reached the running service, and does its configuration match the narrower follow-up warning?

Original sources

Sources checked 24 October 2026. Send a correction.