Executive summary
PHP's 23 October notice identifies an additional remote code execution vector involving session upload progress and an application that changes its session serialisation format during execution. The project describes a specific combination of configuration and application behaviour, rather than exposure in every installation using sessions. PHP recommends disabling upload progress while it prepares the next regular bugfix release, and says applications that never change the handler at runtime can retain the feature. We assess that checking both deployment configuration and application code is likely (B2) to produce a more useful exposure decision than checking the PHP version alone, because the vendor makes the runtime transition a necessary condition.
What PHP disclosed
The notice follows PHP's 21 October emergency releases for CVE-2026-109618 and CVE-2026-109619. Those releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35; the project says they fix the two earlier critical vulnerabilities. Its archive treats the subsequent session issue separately and says a full advisory for the session issue will accompany the next regular release. As of this article's date, the notice supplies neither that release's version number nor a complete technical advisory.
That distinction matters for change records. An administrator should retain evidence that the emergency update was installed, then open a separate check for the configuration described on 23 October. The later notice is not grounds to reverse the emergency update or to describe every patched PHP installation as still exposed to this additional vector.
PHP also says that organisations which already disabled session.upload_progress.enabled in response to the earlier stale-state advisory should keep it disabled; they need no additional change for the newly described path. This statement concerns that mitigation, not completion of all remediation for the two original vulnerabilities. PHP's notices remain the source for the distinction.
The configuration that needs attention
The 23 October notice specifies three conditions together:
| Check | Condition described by PHP | Evidence an operator should collect |
|---|---|---|
| Initial session format | session.serialize_handler is configured as php_binary or php_serialize |
Effective startup configuration for the web application |
| Runtime transition | Application code changes the handler to php using ini_set() before session_start() |
The reachable code path, including framework or plugin configuration |
| Upload progress | Session upload progress remains enabled | Effective value of session.upload_progress.enabled for that service |
The evidence column is our suggested audit procedure. All three vendor conditions belong in the exposure decision. Finding php_serialize in a configuration file alone does not establish the described vulnerability; finding session_start() in an application alone does not establish it either. Conversely, an organisation should not close the check merely because its own application code contains no obvious call if frameworks or plugins can alter the configuration.
The last point is a recommendation to investigate dependencies, not a claim that PHP has identified any particular framework or plugin as affected. The public notice does not supply a list of affected applications, and this article does not infer one.
Why upload progress has a different lifecycle
The PHP manual describes upload progress as a mechanism that records progress in the session while files are being uploaded. It also explains that this session information is written before application scripts execute. A change made later in a script therefore belongs to a different point in request handling from the progress processing itself.
This timing is relevant to configuration reviews, but it is not a complete explanation of the underlying mechanism. PHP has deferred the full advisory. It would be premature to infer an exploit sequence, affected memory layout or universal request pattern from the short notice.
The session configuration reference documents the upload-progress controls and serialisation handler separately. Operators should preserve that distinction in their inventory: a service may use sessions without requiring an upload-progress user interface. Disabling the progress feature is not the same administrative change as disabling sessions or all file uploads.
Apply and verify the mitigation
The vendor's immediate recommendation is to disable the progress feature. The following is a configuration setting, not application code:
session.upload_progress.enabled = 0
Apply it in the administrative configuration used by the affected web service. The configuration manual explains that server-module configuration is read when the web server starts, while command-line and Common Gateway Interface (CGI) invocations have different loading behaviour.
Our recommended validation procedure is:
- Identify the service and pool handling each application, then record the actual configuration source before editing it.
- Apply the setting through the maintained deployment configuration so the next rebuild or restart preserves it.
- Restart or replace the relevant workers through the normal service procedure, then confirm the effective setting in the web execution environment.
- Test ordinary session behaviour and any upload-progress interface with benign requests in a controlled environment.
- Keep the mitigation in the change record until the promised advisory and fixed release have been evaluated.
Do not publish a diagnostic configuration page to the internet as part of this audit. Use an access-controlled administrative check and remove temporary diagnostic code afterwards. The verification should demonstrate the setting in the serving process, rather than merely demonstrate that a command-line binary reads the intended file.
Detection and incident handling
The notice describes exposure conditions; it does not provide campaign attribution or a set of compromise indicators. Treat the configuration review as vulnerability management. An affected configuration is not proof that a service has been compromised, and a quiet error log is not proof that it has remained safe.
Our recommended response is to preserve configuration and application evidence alongside logs. Record the handler's initial value, the relevant runtime change and the enabled progress setting. These observations give an investigator a concrete account of the conditions present without attempting to reconstruct an exploit from a short disclosure.
As a precaution, preserve existing web, worker and application telemetry around suspicious requests, unexpected worker failures or unplanned configuration changes. If investigation finds an intrusion, respond to the observed activity and affected service privileges; do not label an incident as exploitation of this session issue solely because upload progress was enabled. No exploit attempt should be necessary to validate the administrative mitigation.
What to watch
The outstanding publication is PHP's promised full advisory and regular bugfix release. Review it for fixed versions, a refined affected-configuration statement and any changes to the temporary recommendation. Until then, retain the narrower conditions in risk reporting: the vendor has identified a runtime handler transition combined with enabled upload progress, not a blanket flaw in every session-enabled application.
Our assessment remains likely (B2) that a combined code and configuration audit will give the clearest immediate result. Its limitation is the short public disclosure: additional technical detail could change how teams identify the relevant application paths. Keep the evidence and mitigation decision reviewable when that detail arrives.
