PHP security update: two flaws patched, a third needs a settings check

A website can have PHP’s emergency security patches installed and still need a settings check. In an October 23 notice, the PHP project described a separate, unlikely route for an attacker to run code on a server. It recommends temporarily disabling upload-progress tracking until the next regular bugfix release. PHP advisory

For people running shops, community websites or personal pages, the distinction matters: installing the earlier patches and checking the new issue answer different questions. PHP executes website code on the hosting server. Its earlier advisories describe successful demonstrations of attacks without a login, gaining the permissions of the process handling web requests. One confirmed Apache path operates before a website’s own code begins. PHP’s memory-handling advisory

The three vulnerability identifiers refer to different problems:

The releases fixing the earlier pair are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, dated October 21 on the official downloads page. Configuration workarounds cover particular paths; the earlier advisories identify complete patches as the comprehensive remedy. PHP’s session-state advisory

The new issue has narrower conditions. PHP says upload-progress tracking must remain enabled while application code changes its configured session-data format from php_binary or php_serialize to php before starting a session. Applications that never change that format while running can keep tracking enabled, the project says. October 23 notice

Disabling this tracking preserves the ability to accept uploaded files. Picture sending a photograph through a web form: receiving the picture and keeping a running count of the bytes received are separate jobs. PHP’s native progress feature records that count so an application can check the transfer’s status. The separate file_uploads setting controls whether PHP accepts file uploads. Upload-progress manual, file-upload settings

A site relying on PHP’s native tracking will lose those progress updates when it is disabled. Applications reporting progress through the browser are unaffected, according to Red Hat. Its guidance also explains why timing matters: the protective setting must apply before PHP starts processing the request. Administrators must restart every worker process after changes; container deployments require replacing the running container or pod. Red Hat bulletin

A patch also has a journey to make between its publisher and a working website. Docker said on October 22 that updated PHP Official Images were available on Docker Hub and mirrored to Amazon ECR, and that its Hardened Images had also been updated. These are software packages used to build and run applications. Docker’s update

Docker’s documentation describes images as fixed snapshots of software. The practical implication is that publishing a corrected image does not change an existing deployment: the operator still needs to incorporate the updated software and replace what is running. Docker’s build guidance

Namecheap’s deployment log makes that distinction visible. Its October 21–22 entries moved from temporary protections to installation in progress, with lists of servers still awaiting completion. A later update says every PHP version offered on its Shared Hosting servers received fixes for the earlier two vulnerabilities. Namecheap also says some initial patched packages retained their existing version numbers, so the displayed number alone could be misleading. That provider statement concerns the October 21 pair. Namecheap status log

For a website owner, these records suggest three concrete requests to a hosting provider:

• Identify the PHP package or build serving this website, and confirm that it contains fixes for CVE-2026-109618 and CVE-2026-109619.
• Confirm that deployment is complete for this site, including replacement of old processes or containers where required.
• Address CVE-2026-115560 separately: confirm that upload-progress tracking is disabled in the effective server configuration, or explain why the application falls outside PHP’s stated conditions.