PHP’s critical security release is due today. Prepare the deployment now

PHP administrators have a patching deadline to prepare for today. The project has announced a security release for October 21 at 14:00 UTC, or 16:00 CEST, addressing two vulnerabilities rated critical. Its advance notice does not yet identify the affected and fixed versions, so installing an older maintenance release should not be mistaken for completing this response.

The PHP security team's October 20 announcement gives both flaws a CVSS v4.0 score of 9.2. The team may bring publication forward if vulnerability details emerge or it sees evidence of exploitation. That makes the advertised time a planning point rather than permission to ignore earlier updates.

What is confirmed, and what remains provisional

CERT-EU's advisory names CVE-2026-109618 and CVE-2026-109619 and describes the potential for unauthenticated remote code execution. In plain language, the concern is that an attacker might make a vulnerable server execute code without first signing in. The precise conditions matter enormously: a severity score alone cannot tell an operator which applications are exposed.

CERT-EU also says versions from PHP 5 onward could be affected, citing information outside the PHP team's notice. That is a provisional scope, not the official affected-version matrix. The project says that matrix and the fixed versions will accompany the release. Until then, there is no sound basis for publishing a universal “install version X” instruction.

Find the runtime that actually serves the application

The useful work before release is operational. Identify which services use PHP, who supplies their runtime and who can deploy an update. A website on managed hosting has a different owner for that step from an application team maintaining its own container images. Asking the hosting provider about its patch plan is more useful than downloading a binary that the hosted site will never execute.

An inventory should describe the running service, not just a developer's machine. A command-line PHP installation and a web-server runtime can be separate installations; an updated image also does nothing for a service still running its previous deployment. Record the package source, deployment target and verification step together so the incident does not end at “the download succeeded.”

This distinction also matters when diagnosing the application stack. Our coverage of Drupal's Field UI security update concerns application-level configuration. Today's notice concerns the language runtime underneath PHP applications. Completing one maintenance task does not establish that every other layer is current.

Support status changes the upgrade conversation

PHP's support calendar currently lists 8.2 and 8.3 in security-only support, while 8.4 and 8.5 remain actively supported. PHP 8.2's security support ends on December 31, 2026. These lifecycle dates are useful for planning, but they do not establish which branches today's vulnerabilities affect.

For an unsupported installation, the problem may extend beyond applying a point release: the application could need compatibility work to move to a maintained branch. Establish that constraint early. PHP's 8.6 release candidates are explicitly intended for testing, so a higher version number is not a reason to substitute one for a production security fix.

CERT-EU recommends preparing to patch promptly and considering isolation of internet-facing applications when immediate remediation is not feasible. That is a risk-management decision for the service owner, with availability consequences, rather than a universal instruction to take every PHP site offline.

The most valuable preparation today is a named owner and a verified deployment path. When the corrected packages arrive, those two details determine whether an urgent advisory becomes a repaired service or another unread maintenance ticket.