PHP schedules critical security release for 14:00 UTC: what site owners can prepare now
PHP says two vulnerabilities score 9.2 under CVSS v4.0. The release is scheduled for 21 October; affected and fixed versions remain undisclosed in the advance notice.
In this article
Key points
- PHP schedules the security release for 21 October 2026 at 14:00 UTC, with an earlier release possible under stated conditions.
- The team rates two vulnerabilities CVSS v4.0 9.2; the advance notice does not identify affected or fixed versions.
- Check the actual PHP runtime and your provider’s update process; do not treat a supported branch as proof of immunity.
PHP’s security team has given site administrators advance notice of a security release scheduled for Wednesday, 21 October 2026 at 14:00 UTC. The team says it addresses two critical vulnerabilities, each rated 9.2 under CVSS v4.0. Its notice asks users to prepare to upgrade once the release becomes available. At the time report.red checked the announcement, it did not name the affected versions or the versions containing fixes. [1]
A scheduled release, with important details still pending
The distinction matters for anyone deciding whether a particular website is exposed. A severity score describes the announced vulnerabilities; it does not establish that every PHP installation has the same configuration, exposure or risk. The advance notice supplies no basis for naming a vulnerable application, assigning a CVE identifier, or declaring a specific version safe.
The team also reserves the right to release earlier if details become public or evidence of active exploitation appears. That is a contingency in the notice, not a report that exploitation has already occurred. Administrators should check the project’s actual release announcement rather than treating the planned hour as a guarantee. [1]
Prepare the update path before choosing a version
A useful preparation step is to identify which PHP runtime actually serves the website and who controls its updates. A hosting provider may manage it separately from the content management system, while a self-managed installation may use operating-system packages or a container image. This is a preparation checklist from report.red, not a claim that the PHP team has prescribed one deployment method.
Review the provider’s update instructions, confirm that a recoverable backup and a suitable test environment exist, and plan how to check the application after an update. Once the fixed versions and affected scope are published, use that information to choose the appropriate supported package. Installing an unrelated development build is not a substitute for reading the security release.
Support status and vulnerability status answer different questions
PHP’s published lifecycle provides two years of active support followed by two years for critical security issues, with security-only releases issued as needed. That policy explains where maintainers supply fixes; it does not prove whether a branch is affected by this particular announcement. The supported-versions page must be read alongside the forthcoming release details. [2]
This article is based on the PHP project’s own advance notice and support documentation, checked on 21 October. Both sources belong to the same project. report.red has not tested an exploit or audited readers’ servers, and the archival photograph is infrastructure context rather than evidence of an attack.
More technology reporting in English
Archive photograph, 2011: server racks at NERSC, photographed by Derrick Coetzee. Infrastructure context only; this image does not show a compromised server or identify systems affected by the PHP announcement. Adapted into an editorial cover with ImageGen. Derrick Coetzee from Berkeley, CA, USA · CC0. ImageGen / report.red.
