PHP schedules emergency security updates for October 21
PHP’s security team has scheduled security updates for Wednesday, October 21, 2026, at 14:00 UTC (10:00 a.m. Eastern). The announcement says the updates address two vulnerabilities, each rated 9.2 under CVSS v4.0, and asks administrators to be ready to install the fixes as soon as they are available.
PHP has not yet published technical details, affected versions, or the specific releases that will contain the fixes. Administrators should therefore treat the official PHP announcement as the source for confirmed timing and severity, and should not infer their exposure from unverified version lists or vulnerability descriptions.
What PHP has confirmed—and what remains unconfirmed
PHP’s announcement establishes the planned release time, that two vulnerabilities are being addressed, and the PHP-assigned score of 9.2 for each under CVSS v4.0. The team says fuller information, including technical details, affected versions, and fixed releases, will be made available with the security updates.
A report by BleepingComputer adds claims attributed to researchers at watchTowr. The report says watchTowr associated the issues with CVE-2026-109618 and CVE-2026-109619, characterized them as remote code execution vulnerabilities, and believed they affected PHP versions 5, 6, 7, and 8. Those are researcher-reported details in the BleepingComputer account, not information PHP had confirmed in its announcement. The same report notes a discrepancy in severity: watchTowr described the flaws as CVSS 10.0, while PHP’s official notice assigns each a 9.2 score under CVSS v4.0.
BleepingComputer also reported that watchTowr said it had not observed exploitation in the wild and was withholding technical information until fixes were available. That is an attributed researcher statement, not a PHP confirmation about exploitation. The article additionally describes a now-deleted Hacker News post that made claims about the flaws; that post is not an authoritative source for PHP’s affected versions or release details.
PHP warned that it reserves the right to release earlier if details of either vulnerability become public or if there is evidence of active exploitation. Its planned date and time are therefore a target, not a guarantee that administrators should use to postpone monitoring.
Prepare your PHP environments before the fixes arrive
Preparation is useful even while technical specifics remain unavailable. First, identify where PHP runs across the organization: production websites, customer-facing applications, internal services, development and test systems, and any managed hosting or cloud environments. Keep an inventory of the PHP runtime and the party responsible for maintaining it. The source report notes PHP’s broad use in websites and applications, including content-management systems, e-commerce platforms, and custom services; administrators should check those environments rather than assume PHP is present only on explicitly labeled web servers.
Next, determine who can apply an update in each environment. Some teams may control their own packages and deployment process, while hosted services may require a provider or platform operator to deliver the update. Confirm the escalation path and who will verify that the change has reached each relevant system. This preparation does not depend on guessing which versions are vulnerable; it helps ensure the responsible operator can act promptly once PHP publishes the affected-version and fixed-release information.
Monitor PHP’s official release information and security announcements for the actual package names, affected branches, and fixes. Use the official details to determine applicability. The BleepingComputer report says PHP plans to publish technical details and fixed releases when the updates become available; until then, third-party claims should remain clearly distinguished from the official disclosure.
When the fixed release for an affected environment is available, apply it through the normal supported update process as promptly as practical, then verify that the deployed runtime is running the intended fixed version. Coordinate with the service owner or hosting provider where the PHP runtime is not directly administered by your team. Do not treat the reported CVE identifiers or broad version range as a substitute for the forthcoming official affected-version list.
A short window for an evidence-led response
The immediate task is readiness, not speculation. PHP has provided a release schedule and severity ratings but has not yet identified affected versions or described the vulnerabilities. BleepingComputer’s reporting provides context about watchTowr’s claims, but those claims differ from the official PHP scoring and remain attributed reporting until PHP publishes its own details.
Administrators can use the interval to locate PHP deployments, identify update owners, and watch PHP’s official release information. Once PHP makes the fixed releases and affected-version guidance available, use that information to prioritize applicable systems and install the fixes. The source for the announcement and attributed reporting is BleepingComputer’s coverage of the planned PHP security updates.
