PHP2Shell patches need a runtime check—and a separate session review

Website operators responding to PHP2Shell need to verify the PHP runtime serving their requests, even if their content-management system is already current. PHP released fixes on October 21, 2026; a separate, narrowly conditioned session warning published on October 23 also deserves review before the work is closed.

The Verge's October 22 report prompted this follow-up. The technical guidance comes from the PHP project's advisories and the UK's National Cyber Security Centre, rather than TechKili exploit testing.

Find the runtime behind the application

The two vulnerabilities affect PHP's handling of request memory. CVE-2026-109618 involves incomplete internal state after an out-of-memory error; CVE-2026-109619 involves state that can outlive the memory belonging to a request. Both can enable unauthenticated remote code execution.

That places the maintenance task below the website's own application code. The first advisory documents a working attack against Apache mod_php before application code runs. It also identifies PHP-FPM as susceptible through source analysis, while stating that a complete FPM exploit had not been demonstrated for that flaw. Different evidence for an execution mode should not be read as an exemption from patching.

The PHP release notice identifies PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 as fixed releases. Distribution and long-term-support vendors may supply backported fixes. Check the vendor's package advisory as well as its version string; PHP 8.1 and older no longer receive regular project updates.

For a managed site, ask the host to identify the patched runtime actually handling web traffic. For an infrastructure team, a useful completion record connects each service to its serving package and confirms that its workers use the updated build. Checking only a command-line PHP installation can leave that question unanswered.

Read the October 23 session warning narrowly

PHP's October 23 informational advisory describes an additional, unlikely remote-code-execution path under CVE-2026-115560. It requires session upload progress to remain enabled and an unusual change from a configured php_binary or php_serialize session serializer to php at runtime before session_start().

PHP suggests session.upload_progress.enabled=0 until the next regular bugfix release. Applications that never change the serializer at runtime can keep the feature enabled, according to the notice. If the setting was already disabled following October 21 guidance, PHP says to retain it; no further action is needed for that measure.

This follow-up should be assessed alongside the runtime update. A generic claim that every patched site remains exploitable would go beyond the conditions PHP describes.

Close the exposure task separately from incident assessment

The NCSC's October 21 guidance prioritises discovering PHP installations, updating internet-facing systems and monitoring vendors whose products bundle PHP. Where updating or mitigation cannot be completed promptly, it advises considering taking affected systems offline and assessing evidence of compromise.

For operators, this means keeping two records: evidence that the vulnerable runtime has been addressed, and any investigation of what happened before that change. A successful update does not establish that a previously exposed service was never compromised. Equally, a vulnerability announcement does not prove that a particular site was attacked.

Sources

• PHP: October 21 releases and October 23 session advisory

• PHP: out-of-memory corruption advisory

• PHP: stale global-state advisory

• NCSC: operational response guidance

• The Verge: October 22 discovery report