PHP announces two critical security fixes, release at 14:00 UTC

The PHP security team posted an advance notice. A release that fixes two critical vulnerabilities, each rated CVSS v4.0 9.2, is scheduled for Wednesday 21 October 2026 at 14:00 UTC. CVE numbers, the affected versions and the fixed versions will be published with the release itself, not before.

The notice is short on purpose. The project reserves the right to ship earlier if either vulnerability becomes public or if evidence of active exploitation appears. The HN thread that surfaced the announcement reached 868 points, which is the clearest signal the operators of PHP software noticed and are preparing.

What a 9.2 CVSS v4.0 score means in practice

CVSS v4.0 is the latest revision of the Common Vulnerability Scoring System. A 9.2 sits inside the Critical band, which runs from 9.0 to 10.0. The score is a composite: it says the attacker needs little in the way of privilege or user interaction, the impact on the vulnerable system is high, and the exposure can reach beyond the vulnerable component. The project is not giving away which component, which attack vector, or which versions carry the fix, because disclosing any of those before the patch would help an attacker before it helps a defender.

Two critical vulnerabilities in one release is unusual. In the past three years of PHP security advisories, most releases carry one critical fix at most, if that. Two together is a reason to clear time to upgrade on the day of the release, not later in the week.

What a team can do before 14:00 UTC

The project asks every PHP user to prepare now. That means a few concrete things that are worth doing before the release lands, not after. Find every PHP service in production and write down which version it runs. Confirm that the chosen package channel for each one, whether that is the distribution's package manager, a container base image, Composer-managed binaries, or a managed hosting provider, has a path to the next minor or patch release. Check that the pipeline that builds and deploys each service can push a point release within hours of the fixed version becoming available. If a service runs an end-of-life PHP branch, decide now who approves running an unsupported binary with a known critical bug.

The release notes will say which versions receive a fix. Expect at least the two most recent stable branches to be covered, which is PHP's standing policy. Older branches have been out of support for months and will not get patches here, so a service pinned to one of them is the service that needs the most preparation.

Managed hosting providers will roll fixes out on their own schedule. That is useful for everyone running on them, but the schedule is not under the service owner's control, and the window between vulnerability publication and vendor rollout is exactly the window an opportunistic exploit lives in. Ask providers for a public statement of when they will complete the rollout, so the service owner knows which hours to monitor more closely.

Source

Upcoming critical PHP security release, php.net