PHP Adds Fresh Session Guidance After Critical Security Patches

PHP issues October 23 session upload guidance after emergency RCE patches. What changed, which releases contain fixes, and what website operators should check.

PHP issued fresh configuration guidance on October 23, two days after releasing emergency fixes for critical vulnerabilities that can permit unauthenticated remote code execution. The update gives website operators another item to verify after patching, while carefully limiting the circumstances in which the newly described issue can occur.

The PHP project’s advisory suggests disabling session upload progress with session.upload_progress.enabled=0 until its next regular bugfix release. It says applications that never switch their session serialization handler at runtime can leave the feature enabled. Operators who already applied the setting as part of Wednesday’s mitigation should keep it in place; the project says no further action is needed for that guidance.

The update follows Wednesday’s emergency releases

On October 21, PHP released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix CVE-2026-109618 and CVE-2026-109619. Its security team urges users to update immediately and directs Linux users to their distribution or long-term support vendor for patched packages.

Today’s notice describes a narrow configuration and application-code combination and identifies a separate issue, CVE-2026-115560, for a forthcoming advisory in the regular release cycle. That is distinct from the two critical flaws addressed on Wednesday.

A completed deployment needs evidence

For a business that depends on a PHP website, the immediate management question is whether the running service has received its vendor’s fixes. A package downloaded to a server is only one part of that process. Administrators should confirm the version actually serving requests, check all replicas and containers, and record which supplier is responsible for each installation.

Those are operational checks, rather than evidence of a compromise. This article does not establish that a particular site has been attacked, and a configuration change should not be treated as proof that earlier exposure caused no harm. Where an organization has signs of intrusion, patching and incident investigation are separate pieces of work.

The distinction between an emergency release and follow-up guidance matters. A short headline saying PHP has been patched can leave a team believing the entire task is over. The project’s October 23 notice shows why someone must keep following the advisory after the initial change window closes.

For hosting customers, the useful request is concrete: ask the provider which patched build is running and whether today’s session guidance applies to the application. That produces a more useful answer than a general assurance that security updates are automatic.