Information verified as of October 21, 2026, 14:30 Santiago, Chile time (UTC−3), equivalent to 17:30 UTC.
PHP released security updates today for four branches: 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Businesses running websites, commerce platforms or applications on PHP should identify their deployments and prioritize a coordinated update. Official PHP release announcements.
The response needs application owners, security teams, operations and hosting providers working from the same inventory. Updating a component without checking where it runs can leave services outstanding. Deploying without testing can disrupt business workflows. The practical goal is a completed, verified change, with clear ownership of anything that remains unresolved.
What PHP disclosed
The advisory for CVE-2026-109618 describes memory corruption associated with out-of-memory handling and possible unauthenticated remote code execution. It is rated critical, with a CVSS 4.0 score of 9.2. Exploitability depends on the deployment environment. Official PHP advisory.
CVE-2026-109619 concerns state retained between requests and can also enable remote code execution. It is rated critical, with a CVSS 4.0 score of 9.2. The advisory calls for the complete fix and consideration of both related issues. Second official advisory.
These disclosures do not establish that a particular organization has been compromised. Exposure assessment and incident investigation require evidence from that organization's own systems.
Fixed releases by branch
| PHP branch | Published fixed version |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
These are the corrected releases identified in the PHP security advisories. The table is not an instruction to move every application to a different branch without compatibility testing.
For distribution packages or managed services, request the provider's security bulletin and the exact corrected package identifier. A vendor may incorporate a fix through a backport while retaining a version label that differs from the upstream release. Document that evidence rather than assuming that either the label or a generic assurance settles the question.
PHP 8.1 and earlier branches are outside the project’s normal support. If your organization still uses them, request evidence of any provider-supplied fix and establish a migration plan to a supported branch. PHP’s published guidance.
Look beyond the WordPress dashboard
A plugin review alone cannot establish the status of the underlying PHP runtime. Build an inventory covering the main website, subdomains, internal applications, accessible test environments, managed hosting, servers and containers.
For each service, record the operational owner, active version, update mechanism and business process it supports. Include the images used to create future deployments. Correcting a running instance should not leave the next deployment capable of bringing an outdated image back into service.
Verify the runtime actually handling web requests. A version reported in a terminal does not, by itself, prove which process serves each website. Keep diagnostic evidence in authorized internal channels rather than exposing a public configuration page. For multi-instance services, make the check broad enough to cover the instances that receive traffic.
A checklist for your team and hosting provider
- Technology owner: consolidate the inventory and assign an accountable owner to every service. Prioritize exposed systems and business-critical workflows when organizing the work.
- Provider or administrator: identify the package covering both fixes, the environments included and the implementation window. Request a service-specific response instead of a blanket statement that the platform is updated.
- Application team: check compatibility and test relevant user journeys, including sign-in, navigation, checkout or transactions, integrations and scheduled jobs.
- Operations: confirm that backups and recovery procedures are usable. Establish who can pause or reverse a deployment if the application fails its checks.
- Security team: document outstanding exceptions, owners and next actions. Any temporary measure needs technical assessment and must not be treated as equivalent to the complete patch.
- Change owner: verify the active runtime after deployment, retain evidence and obtain functional acceptance from the business owner.
Define what completed means
A useful completion record includes the updated inventory, the corrected version or package for each service, test results and confirmation that traffic-serving instances have been refreshed. Review application errors and behavior after the change, not just the deployment job's success status.
If recovery requires returning to a vulnerable version, the exposure becomes outstanding again and needs an explicit decision. A backup supports recovery; it does not repair the vulnerability or demonstrate that compromise has not occurred.
Use this event to make ownership clearer. The business should know which provider handles PHP updates, who tests the application and where completion evidence is stored before the next urgent change arrives.
To discuss your environment and security priorities, explore NOVVOR's security services and ask about an appropriate scope for your organization.
